SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Requirements - slide 1 Software...

SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Requirements - slide 1

Software engineering for real-time systems

Section 3

Requirements analysis and specification


Objectives

To: Distinguish between mythical and realistic software life cycle models.

Show where requirements analysis and software specification (the requirements stage) fits into the life cycle.

Highlight the importance of the requirements stage.

Introduce the topic of software prototyping.

Introduction

From system requirements to software specifications


The software life cycle

The software life cycle

-

From problem to solution


User problem

Problem analysis

Requirement specification

Architectural design

Physical design

Implementation

Test and debug

Maintain

Customers requirements

System requirements

Software requirements specification

Software structure

Hardware/Software structure

Software modules

Total software package

Statement of requirements

The mythical software life cycle


Analysis andspecification

Design ImplementationTest and

debug

Time

Effort

Project effort distribution - another myth


Need perceived

Informal specification

Informal discussions with suppliers

Formal tendering specification

Bid analysis

Reply by suppliers

Modification of tendering specification

Contract awarded - SOR

Formulating the user statement of requirements (SOR)


User problem

Problem analysis

Requirement specification

Architectural design

Physical design

Implementation

Test and debug

Maintain

Customers requirements

System requirements

Software requirements specification

Software structure

Hardware/Software structure

Software modules

Total software package

Statement of requirements

A more realistic software life-cycle model


PROJECTRequirements

and designImplementation Test, debug

and integrationSAGE 39 14 47NTDS 30 20 50GEMINI 36 17 47SATURN V 32 24 44OS/360 33 17 50TRW Survey 46 20 34

Distribution of software effort


Analysis andspecification

Design

Test integration anddebug

Effort

Time

Implementation

Project effort distribution - reality


D efence S taff;D efence procurem entagenc ies

A nalys is and des igne.g.A nalys is o f the a ir warfare threat.O vera ll des ign of appropria te a ir in terceptor fightersys tem .

O utput: O vera ll system S O R .

M ain contractor:the a irc raft m anufacturer.

A nalys is o f system requirem ents andits overa ll des ign.D esign o f the weapon av ionics (N A V /W A S ) sub-system .E laboration o f system spec ifications.

O utput: S ub-system spec ifications.

A nalys is o f the N A V /W A S sub-systemspecifications.D esign o f the sub-systemO utput: N A V /W A S system , hardware and software

spec ifications.

A v ion ics (N A V /W A S )

software developer

O utput: D es ign docum entation andsource code.

Floor

Floor

Floor

Ceiling

Ceiling

Ceiling

A vionics (N A V /W A S )subcontractor

A nalys is o f the problem -A ir defence requirem ents--------------------------------------

A nalys is o f system and software spec ifications.D esign o f the software.

The development process - a layered approach


D ESIG N SP ECIF IC ATIO N -C O M PLETEN ESS AN D

C O M PR EH EN SIO N

D ESIGNSO LU TIO N

CO N C EPTU ALSO FTW A RE

* Evaluation* Deve lopm ent

o f C onceptsD esign

Im plem enta tionR eview

Tim e

Start

C O D E

Incremental development of software


The importance of requirements capture

The importance of requirements capture

-

Mistakes and their consequences


Making mistakes


Requirem ents56%

Code7% Other10%

Design27%

Sources of software errors


Requirem ents 82%

Other 4%Code 1%

Design 13%

Cost of rectifying software errors


The impact of requirements errors

Requirem ents 82%

Other 4%Code 1%

Design 13%

Requirem ents56%

Code7% O ther10%

Design27%

Error source No. of errors

Correction cost

Overall impact

Percentage impact

Requirements 56 0.82 45.92 85

Design 27 0.13 0.13 6.5

Coding 7 0.1 0.7 1.2

Other 10 0.4 4.0 7.4

For every 100 errors


Systemrequirem ents

Analysesystem

requirem ents

Specifysoftware

requirem ents

Additionalfactors

(constraints)

Softwarespecification

Developing the software specification


Overall system description

What it'ssupposed to do

Function

How well itmust do it

Performance

How it fits in withits environment

Interfaces

Do's anddon’t's

Constraints

"Real world" interfaces "Software world" interfaces

Man-machine Plant Operatingsystems

Databases

Overall system description


Requirem ents specification

Functionalrequirem ents

Non-functionalrequirem ents

Developm entrequirem ents

W hat it does:Behaviour

W hat it has:A ttributes

How it shouldbe built

Software specification features


The originalrequirem ents

The deliveredproduct

Errors in translation

Form ulation ofrequirem ents

Com m unication ofrequirem ents

Change torequirem ents

Understandingof requirem ents

Determ ined byuser expertise

Determ ined by them ethods used

Determ ined bythe suppliers

expertise

Unpredictable

Where mistakes are made in defining requirements


Practical requirements capture methods

Defining system requirements

-Practical requirements capture methods:

1. Use cases. 2. Prototyping.


Use Case Fundamentals

Use case fundamentals

Use Cases are a technique for organizing and presenting requirements.

They can be used to:

Analyse clients requirements.

Minimize confusion and misunderstanding between clients and suppliers.

Validate system-level designs.

Develop specifications for the software system itself.

Define the outlines of system acceptance tests.


Library

Bookshop

Bank

• The starting point:

• System requirements are related to the whats, whens and hows of system usage.

• People are USERS of systems.

• Systems are also users of systems.

Setting the scene


John

Jim

Alex

Bookshop

Library

• Many people.

• Many systems.

• Exactly why are people using the system?

• What are we interested in?

Systems and their users


Order book

John

Jim

CustomerBookshop

Order book

(a) (b)

The system of concern is a bookshop.

There are two users (specifically two individuals).

The individuals are using the system to order a book (orbooks).

Any illustration of the use of a system is defined to be a ‘usecase’; hence this example is the use case ‘order book’.

‘Roles’ - both people are ‘customers’.

Basics of the use case diagram


Order Book

Diagram symbol(icon)

"The customer places a telephoneorder for a book. It will be

dispatched within 24 hours"

Text description

What goes on when a customer tries to order a book?

•The diagram symbol for a use case is an ellipse. •Inside this is written the name of the use case.

•But this doesn’t give any detail of the use case.

•Thus a description of the use case must be provided.

The components of a use case


Actors

Use Case 1

Use Case 2

Use Case 3

Use cases

Text for use case 1

Text for use case 2

Text for use case 3

Use case descriptions

Each system has its own use case model

•This model consists of actors, use cases and use case descriptions.

• Actors depict the ‘roles’ performed by users.

• The reasons why actors use the system are shown as a set of use cases.

• Use case descriptions add detail.

The components of the use case model


Navigator

Pilot

Nav/Was system Air data system

Get NavigationWaypoints

Set AirfieldAltitude

Navigator

Pilot

(a) (b)

Each system is drawn as a rectangular box.

The relevant use cases are shown as ellipses inside them.

Outside the system boundary are the actors.

These are connected to (‘associated with’) the use cases using by drawing lines between them.

Example use case diagrams


The navigator enters new valuesfor the airfield altitude.This is displayed on the pilot'shead-down display

START

1. Navigator enters airfield altitude data.

2. System checks data range validity.

3. New values displayed to the navigator. Conformation required

4. Navigator confirms values.

5. New values displayed on pilot's head-down display. FINISH

(a) Initial

(b) Expanded

Describing and structuring use cases

Use cases: text description


Types of scenarios

Normal (error-free) use of the system.

Uses where errors occur but which can be dealtwith as part of the interaction process (e.g.entering invalid data).

Uses where errors occur but which cannot bedealt with as part of the normal processing(exceptions).

Use case scenarios

‘A particular sequence of interactions’

Use case scenarios


• Both scenarios apply to the same use case.

• In practice a use case could have a number of scenarios.

• As the paperwork expands it becomes more difficult to apply use case techniques effectively.

Scenarios - text descriptions

(b) Scenario 2 - Data not in valid range

Start 1. Navigator enters ___

2. System checks data range validity. 2.1 System rejects data. 2.2 Requests re-entry of data. 2.3 Go to action 1.

3. New values _ _ _ 4. Navigator confirms_ _ _ 5. New values _ _ _

Finish

(a) Scenario 1 - Data within valid range

Start

1. Navigator enters airfield altitude data.

2. System checks data range validity.

3. New values displayed to the navigator. Conformation required

4. Navigator confirms values.

5. New values displayed on pilot's head-down display.

Finish


Combining scenarios

Start 1. Navigator _ _ _

2. System checks input data.

3. New _ _ _ 4. Navigator _ _ _ 5. New _ _ _ Finish

Start1. System checks data range validity. 2. IF in range THEN 2.1 System acknowledges entry. ELSE 2.2 System rejects data. Requests re-entry of data. Navigator enters data Go to action 1.Finish

Simplifying the paperwork - combine the individual scenarios

Presentation style 1

Presentation style 2

A ‘mini’ use case description

Start 1. Navigator _ _ _ 2. System checks data range validity. IF in range THEN 2.1 System acknowledges entry. ELSE 2.2 System rejects data. Requests re-entry of data. Navigator enters data. Go to action 2. 3. New _ _ _ 4. Navigator _ _ _ 5. New _ _ _

Finish


Navigator Air data system

Set Airfield Altitude

Validate Data Range

<< Include >>

Pilot

Use case diagram for previous slide - the include relationship

The separate text can be treated as a use case in its own right

The include relationship


Variations on a theme

1. A base use case may be complete but

2. There may be situations where extra operationsare required

3. In this situation the functionality of the base usecase is extended by a second one.

The extend relationship


Air Electronics Officer Generating system

Check Alarm Status

Set Alarm Limits

<< extend >>

• The base use case - ‘Check Alarm Status’ - is complete.

• It describes what happens when the AEO checks out the generating system alarms.

• Most of the time this is the only action required.

• However, sometimes it may be necessary to set the alarm limits.

• Thus extra functions must be performed.

• These are defined in the use case ‘Set Alarm Limits’.

The extend relationship (more)


The distinction between includes and extends.

Include use cases collect in one place behaviour which is : Either called on a number of times within one use case

and/or Is common to a number of base use cases (fig. (a)).

Extend use cases show variations on a theme (fig. (b)).

Set airfieldaltitude

Set autopilotmode

Validatedata range

<<Include>>

<<Include>>

Check alarmstatus

Maintaingeneratingsystems

Set alarmlimits

<<Extend>>

<<Extend>>

(b)(a)

Comparing the include and extend relationships


Up to this point we have used actors to representthe roles of people.

But frequently systems interact, not only withpeople, but with other systems.

Navigator

P ilot Nav/W assystem

Air datasystem

(a) System view

Nav/W assystem

Air datasystem

(b) Use case view

External systems as actors


Introduction to protoyping

Prototyping withinthe

software life cycle


Exploratory prototyping

Solution prototyping

Investigative prototyping

Verification prototyping

Evolutionary prototyping

Form al tendering specification

Reply by supplier

SOR

Requirem entsphases

Design phases

Build andm aintenance

phases

Prototyping within the software life cycle


Prototypingtool

User interfaceOutputsupportsystem

Designm anagem ent

Design toolsDesign

database

Modellingenvironm ent

Elements of a prototyping tool


Screen prototype proposed avionics cockpit instrument layout


Anim ationscreendisplaym odel

Model properties

Anim ation engine

User

Building the animation model


Screenm odel

buildingtool

Behavioural/tem poralm odel building tool

Screen m odel

Graphical(com ponent)

libraries

Behavioural/tem poral m odel

Lin

kM O DEL INPUTS Devices (com ponents) Device attributes Tim ing inform ation Stim uli (events) Com ponent

connections

M O DEL INPUTS Functions and

dynam ics

Animation prototyping typical development environment


Behavioural/tem poral m odel building tool

Conventionalprogram m ingtechniques(e.g. C, C++,Java, Ada95)

V isualprogram m ingtechniques(e.g. V isualBasic,Delphi)

S im ulationlanguages(e.g.S im script)

Modellingtools (e.g.SESW orkbench)

CASE tooldynam icm odels (e.g.ArtisanStudio statetransitiondiagram s)

Methods for developing the behavioural/temporal model


Review of section

You should now:

Be able to explain the realistic development of software in real-time systems.

Appreciate how important it is to properly and fully establish the true requirements of systems before plunging into design.

Understand the basics of use case analysis techniques.

Understand the basic role of prototyping in establishing system requirements.

Appreciate how rapid and animation prototyping can be used effectively as front-end techniques in defining system and software requirements.

END OF SECTION ‘Requirements analysis and specification’

Review of ‘Requirements analysis and specification’

SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Requirements - slide 1 Software...

Documents

Transcript of SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Requirements - slide 1 Software...