Chapter Learning Goals

(1)

Martin Jud

NDS-I SWE

I

1

Chapter Learning Goals

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

•

Distinguish

– C- (Customer) requirements from

– D- (Detailed) requirements

•

Be equipped with options for organizing D-requirements

– by class

- by use case

– by feature

- by event …...

•

Be able to complete requirements

– be detailed enough to enable all design

and complete implementation

– be able to express the non-functional requirements

D-Requirements

Martin Jud

NDS-I SWE

I

2

Requirement Types

Needs

Features

System-Requirements

Lastenheft

Software Specification

Pflichtenheft

Problem Space

Solution

Space

C-Requirements

D-Requirements

Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern

(2)

Martin Jud

NDS-I SWE

I

3

Das Pflichtenheft

Aus der Vorlesung Informationstechnik von Berend Denkena u. Kirsten Tracht am ifw der Uni Hannover

D-Requirements

Martin Jud

NDS-I SWE

I

4

C- vs. D-Requirements - Beispiel

Zeit/Datum Art Aktion

C-Requirement (Feature):

#1: Eine Lichtquelle kann zeitgesteuert ein-/ausgeschaltet werden.

D-Requirement (Software Specification):

Timer.

#T1: Ein Timer ist frei programmierbar. Für jedes Zeitereignis kann

eine Aktion definiert werden.

#T2: Einmale Zeitereignisse: Datum/Uhrzeit - Auflösung Minuten.

#T3: Zyklische Ereignisse: minütlich, stündlich, täglich, Wochentag.

#T4: Mögliche Aktionen: Lichtquelle ein/aus.

#T5: Protokoll, welches Timer bei Ereignis-Eintritt aussendet:

(3)

Martin Jud

NDS-I SWE

I

5

Types of Requirements

1. Functional requirements

the application's functionality

2. Non-functional requirements

2.1 Performance

– speed

– capacity (traffic rates)

– memory usage

• RAM

• disk

2.2 Reliability and availability

2.3 Error handling

2.4 Interface requirements

how the application interacts with

the user, and with other

applications

2.5 Constraints

– accuracy

– tool and language constraints

• e.g. “FORTRAN 88 must be

used”

– design constraints

– standards to be used

– hardware platforms to be used

3. Inverse requirements

what the application does not do

D-Requirements

Martin Jud

NDS-I SWE

I

6

3.1 External interfaces

3.2 Functions

3.3 Performance requirements

3.4 Logical database

requirements

3.5 Design constraints

3.5.1 Standards compliance

3.6 Software system attributes

3.6.1 Reliability

3.6.2 Availability

3.6.3 Security

3.6.4 Maintainability

3.6.5 Portability

3.7 Organizing the specific requ.

3.7.1 System mode -- or

3.7.2 User class -- or

3.7.3 Objects (see right) -- or

3.7.4 Feature -- or

3.7.5 Stimulus -- or

3.7.6 Response -- or

3.7.7 Functional hierarchy -- or

3.7.8 Additional comments -- or

3.1 External interface requirements

3.1.1 User interfaces

3.1.2 Hardware interfaces

3.1.3 Software interfaces

3.1.4 Communications interfaces

3.2 Classes/Objects

3.2.1 Class/Object 1

3.2.1.1 Attributes

(direct or inherited)

3.2.1.1.1 Attribute 1

. . .

3.2.1.2 Functions (services,

methods, direct or inherited)

3.2.1.2.1 Functional requirement

. . . .

3.3 Performance requirements

3.4 Design constraints

3.5 Software system attributes

3.6 Other requirements

IEEE 830-1994 Specific (“D-”) Requirements

3. Specific requirements

(non-OO)

(OO)

(4)

Martin Jud

NDS-I SWE

I

7

SRS Chap. 3 Organization

(OO Style)

3.1. External interface

requirements

3.1.1. User interfaces

3.1.2. Hardware interfaces

3.1.3. Software interfaces

3.1.4. Communications

interfaces

3.2. Classes/Objects

see section tbd

--3.3.

Performance requirements

3.4.

Design constraints

3.5.

Software system attributes

3.6.

Other requirements

D-Requirements: SRS

Martin Jud

NDS-I SWE

I

8

3.1. External interface requirements

3.1.1. User interfaces

3.1.2. Hardware interfaces

3.1.3. Software interfaces

3.1.4. Communications interfaces

3.2. Functions

3.3. Performance requirements

3.4. Design constraints

3.5. Software system attributes

3.6. Other requirements

SRS Chap. 3 Organization

(Functional Style)

(5)

Martin Jud

NDS-I SWE

I

9

Specific requirements (Section 3 of the SRS)

•

Describe all of the software requirements to a level of detail sufficient to

– enable designers to design a system to satisfy those requirements,

– and testers to test that the system satisfies those requirements.

•

Requirement should be externally perceivable and include

– a description of every input (stimulus) into the system,

– every output (response) from the system, and

– all functions performed by the system in response to an input

or in support of an output.

•

The following principles apply:

– Requirements should be cross-referenced to earlier documents.

– Requirements should be uniquely identifiable.

D-Requirements: SRS

Martin Jud

NDS-I SWE

I

10

A path through requirements

1. Gather stakeholder needs

2. From stakeholder needs create the Vision with features

3. Use the features to create the use case model

4. Detail the use cases into scenarios and the object model

Adapted from cs3733-e04 SWE slides by Gary F. Pollice, Worcester Polytechnic Institute, MA

(6)

Martin Jud

NDS-I SWE

I

11

Finden der Analyseklassen

Register for Course Customer Billing Request for Information Send Comment

jeder UseCase

wird durch Klassen

mit den Stereotypen

«entity» «boundary»

oder «control»

verfeinert.

aus Instanzen des

Geschäftsprozessmodells

werden Klassen im

Analysemodell.

aus Aktivitäten des

Geschäftsprozessmodells

werden UseCases des

Systemanforderungsmodells

Konto

Geld-annahme

User

Interface

Geld-ausgabe

Abhebung

Transfer

Einzahlung

Bank

Kunde

Konto

besitz

1..*

2

1

Sinngemäss aus Realisierung einer Unternehmensanwendung by Günter Ruck, MID GmbH

D-Requirements: Vorgehen

Martin Jud

NDS-I SWE

I

12

Analyseklassen Stereotypen

Analysis classes may be stereotyped as

one of the following:

• Boundary classes

• Control classes

• Entity classes

These stereotypes are specially useful in helping you to

identify classes in analysis and early design.

(7)

Martin Jud

NDS-I SWE

I

13

Find Classes for Requirements

1.

Develop a comprehensive, non-overlapping collection

of use cases.

2.

Draft candidate classes or objects and methods

(e.g. using the noun / verb technique)

3.

Create a sequence diagram for every use case.

- take care in identifying the classes and objects

4.

Gather the classes used in the sequence diagrams.

5.

Determine essential additional domain classes.

6.

Classify the detailed functional requirements by these classes.

6.1 list each attribute as a requirement

6.2 list each specific object of this class that must exist

6.3 list each function required of objects in this classification

6.4 list the events that all objects of the class must react to

D-Requirements: Vorgehen

Martin Jud

NDS-I SWE

I

14

Desired Properties of Requirements

• Traceability

Verfolgbarkeit

• Testability

Testbarkeit

• Unambiguity

Eindeutigkeit

• Priority

Priorität

• Completeness

Vollständigkeit

• Consistency

Konsistenz

Use these Properties for Inspection

(8)

Martin Jud

NDS-I SWE

I

15

Traceability

D-Requirements: Eigenschaften

Martin Jud

NDS-I SWE

I

16

Traceability Matrix

(9)

Martin Jud

NDS-I SWE

I

17

Tracing and Testing of Functional D-Requirements

Design Element

Functional Requirement 278

Unit Test 2694 +

!

validated by

Design Element ABCD

trace

"

Design Element

Code Element EFGH

implemented by

#

applies to ...

trace

Martin Jud

NDS-I SWE

I

18

Functional vs. Non-Functional Requirements

Design Element

#

Design Element

"

$

Functional Requirement

Unit Test +

Design Element

Requirements

phase

Test

phase

tested by

Inspect

Implementation

assignment

(10)

Martin Jud

NDS-I SWE

I

19

Link from Source to Requirement

/**

<a href="RequAnal\# EngagingForeignCharacter ">

Engagement Requirement 1

("Engaging a foreign character")

</a>

. . . . Implementation comments . . . .

*/

public

engageForeignCharacter( … )

{

. . .

}

The purpose of this method is stated in SRS.

The purpose is not repeated with the source code.

Martin Jud

NDS-I SWE

I

20

The system shall display the difference in salary between

the client and the world wide average for the same trade

- - can't be tested because the average mentioned

cannot be determined (event though it exists).

Better:

The system shall display the difference in salary between

the client and the estimated world-wide average for the

same trade as published by the United Nations on its

website

www.tbd

at the time of the display....

Testability

(11)

Martin Jud

NDS-I SWE

I

21

%

&

Whenever all foreign players are absent from the area

containing the player's main character, the player may

change the quality values of this character, keeping the

sum total of the quality values unchanged.

The PlayerQualityWindow, (see section tbd) is used for

this purpose. Changes take effect four seconds after the

“OK” button is pressed.

The player can decide the qualities of Encounter characters.

At any time? Probably not. Would have to test under all

circumstances, many not intended, incurring unnecessary

expense, and producing a wrong result.

Ambiguity

Martin Jud

NDS-I SWE

I

22

Constistency

No contradictions among requirements.

Requirement 14.

Only basic food staples shall be carried by game characters

.

. . . . .

Requirement 223.

Every game character shall carry water.

.

. . . . .

Requirement 497.

Flour, butter, milk and salt shall be considered the only

basic food staples.

(12)

Martin Jud

NDS-I SWE

I

23

Prioritizing D-requirements

[

essential

]

Every game character has the same set of qualities.

[

desirable

]

Each area has a set of preferred qualities.

[

optional

]

The player’s character shall age with every encounter. The

age rate can be set at setup time. Its default is one year per

encounter.

Martin Jud

NDS-I SWE

I

24

Status after

initial draft

Result of updating after

C-requirements

Result of updating after

D-requirements

Milestones

Initial

More detailed

Risks

Identify

Retire risks identified

previously;

seek more risks

Retire risks identified;

identify more risks

Schedule

Very high level

Preliminary project schedule

More detailed: shows class &

method development tasking

Personnel

Designate

C-requirements

engineers

Engineers designated for

D-requirements analysis

Designate software architects

Cost

Estimation

Crude estimates

First estimates based on job

content

Improved estimate based on

more specific function points

and/or past experience

Table 4.5 Updating the Project on Completing D-Requirements

(13)

Martin Jud

NDS-I SWE

I

25

Status

Requirement

Priority

Not

Fraction com pleteReady for

Designed

Integration

number

Essential

Optional started

1/3

2/3

Inspection

for

Unit

tested

Desirable

Inspected

tested

Responsible

engineer

Tracking Requirements

D-Requirements: Prozess

Martin Jud

NDS-I SWE

I

26

Concurrent Development of Requirements and Architecture

Aus einem STRAW’01 Paper von Bashar Nuseibeh