Requirements Engineering Copyright, 1999 © Jerzy R. Nawrocki Jerzy Nawrocki...

Requirements EngineeringRequirements Engineering

Copyright, 1999 © Jerzy R. Nawrocki

Jerzy NawrockiJerzy Nawrocki

[email protected]@put.poznan.pl

Personal Software Process Personal Software Process

Lecture 2Lecture 2

J. Nawrocki, PSP, Lecture 2

IntroductionIntroduction

System engineeringSystem engineering::

• information engineering information engineering (a business enterprise)(a business enterprise)

• product engineering (a product engineering (a production process)production process)

Software engineering vs.Software engineering vs.

system engineering system engineering


Computer-based systemsComputer-based systems

• SoftwareSoftware

• HardwareHardware

• PeoplePeople

• DatabaseDatabase

• DocumentationDocumentation

• ProceduresProcedures


Restraining factorsRestraining factors

• AssumptionsAssumptions

• SimplificationsSimplifications

• LimitationsLimitations

• ConstraintsConstraints

• PreferencesPreferences


A good SRSA good SRS

• UnambiguousUnambiguous (one interpretation) (one interpretation)• VerifiableVerifiable (one can check that req. are met) (one can check that req. are met)• CompleteComplete (responses to invalid input) (responses to invalid input)• ConsistentConsistent (no conflicts between req.) (no conflicts between req.)• Modifiable (changes are not a big problem)Modifiable (changes are not a big problem)• Traceable (origin of each req. is clear)Traceable (origin of each req. is clear)• Usable during the Operation and Usable during the Operation and

Maintenance PhaseMaintenance Phase


Source Documents for RequirementsSource Documents for Requirements

.doc.doc

ManualManualSRSSRS

SRSSRS

Ver. nVer. n

Ver. n+1Ver. n+1


Source Documents for RequirementsSource Documents for Requirements

List of SD4Rs# Type Title From Since Place Comments

1 Email SRS Nowak 9.11.99 SDS/ Ambiguous2SD4R: Source document for requirements SD4R: Source document for requirements

Types of SD4R:Types of SD4R:

Email VideoEmail Video

File AudioFile Audio

Hard(copy) . . . Hard(copy) . . .

Advice:Advice:

Try to keep all theTry to keep all the

SD4Rs as text filesSD4Rs as text files

Advice:Advice:

Try to keep all theTry to keep all the

SD4Rs as text filesSD4Rs as text files


Requirements document (1)Requirements document (1)

1. Introduction1. Introduction

1.1 Purpose of the document1.1 Purpose of the document

1.2 Scope of the product1.2 Scope of the product

1.3 Definitions, acronyms and1.3 Definitions, acronyms and

abbreviationsabbreviations

1.4 References1.4 References

1.5 Overview of the document1.5 Overview of the document


Requirements document (2)Requirements document (2)2. General description2. General description

2.1 Product perspective2.1 Product perspective

2.2 Viewpoints2.2 Viewpoints

2.2.1 Stakeholders2.2.1 Stakeholders

2.2.2 Users2.2.2 Users

2.2.3 Domain2.2.3 Domain

2.2.4 Components2.2.4 Components

2.3 System architecture and use cases in UML2.3 System architecture and use cases in UML

2.4 General constraints2.4 General constraints

2.5 Assumptions and dependencies2.5 Assumptions and dependencies


Requirements document (3)Requirements document (3)3. Technical requirements 3. Technical requirements

3.1 Functional requirements3.1 Functional requirements

3.1.1 Requirement 13.1.1 Requirement 1

3.1.1.1 Introduction3.1.1.1 Introduction

Viewpoint and source(s)Viewpoint and source(s)

Firmness and importance Firmness and importance

Verifiability and clarityVerifiability and clarity

3.1.1.2 Inputs3.1.1.2 Inputs

3.1.1.3 Processing3.1.1.3 Processing

3.1.1.4 Outputs3.1.1.4 Outputs



3.1.2 Requirement 23.1.2 Requirement 2

. . . .

3.2 External interface requirements3.2 External interface requirements

3.2.1 User interfaces3.2.1 User interfaces

3.2.2 Hardware interfaces3.2.2 Hardware interfaces

3.2.3 Software interfaces3.2.3 Software interfaces

3.2.4 Communication interfaces3.2.4 Communication interfaces

3.3 Performance requirements3.3 Performance requirements



3.4 Design constraints3.4 Design constraints

3.4.1 Standards compliance3.4.1 Standards compliance

3.4.2 Hardware limitations3.4.2 Hardware limitations

. . .. . .

3.5 Attributes3.5 Attributes

3.5.1 Security3.5.1 Security

3.5.2 Maintainability3.5.2 Maintainability

. . .. . .



3.6 Other requirements3.6 Other requirements

3.6.1 Database3.6.1 Database

3.6.2 Operations3.6.2 Operations

3.6.3 Site adaptation3.6.3 Site adaptation

3.6.4 Training3.6.4 Training

. . .. . .

3.7 Non-technical requirements3.7 Non-technical requirements

AppendixesAppendixes

IndexIndex


Developers

Developers Custo

mer

s

Custo

mer

s

FASTFAST

FAST FAST = Facilitated = Facilitated Application Application Specification Specification TechniqueTechnique

JADJAD (Joint Application (Joint Application Development) is Development) is another approach to another approach to FASTFAST

Facilit

ator

Facilit

ator

Recorder

Recorder


FAST for SDSFAST for SDSPersons involvedPersons involved

FacilitatorFacilitator (5th year student) - runs the (5th year student) - runs the meeting(s)meeting(s)

RecorderRecorder (another 5th year student) - (another 5th year student) - takes notes, serves tape recorder or takes notes, serves tape recorder or video recorder (video recorder ( Piotr Giera) Piotr Giera)

DevelopersDevelopers (4th year students of MSE) (4th year students of MSE) and and customer representatives customer representatives (1 for (1 for each view) - work on requirementseach view) - work on requirements

Supervisor and Adam WojciechowskiSupervisor and Adam Wojciechowski - - know about the meeting date & timeknow about the meeting date & time


FAST for SDSFAST for SDS

Input documents (1)Input documents (1)

Product requestProduct request ( ( Project Proposal, in Project Proposal, in the customer’s language, HTML 3.0)the customer’s language, HTML 3.0)

Information about FAST Information about FAST placeplace (Polish- (Polish-German Centre?, 9:00 - 15:00) and German Centre?, 9:00 - 15:00) and timetime (2 - 4 hours by 29.10.99) - should (2 - 4 hours by 29.10.99) - should be agreed by 22.10.99 (customer, 5th be agreed by 22.10.99 (customer, 5th year students, and the bar manager)year students, and the bar manager)



The list of The list of stakeholdersstakeholders and views and views should be ready should be ready beforebefore the project the project leaders leaders startstart to organise the FAST to organise the FAST meeting.meeting.

Get from the customer the initial list of Get from the customer the initial list of requirements sourcesrequirements sources (manuals, (manuals, organisation charts, technical data, ..) organisation charts, technical data, ..) and and readread it it beforebefore the FAST meeting. the FAST meeting.

If not feasible, the meeting can be If not feasible, the meeting can be conducted via conducted via phonephone or or e-mail.e-mail.


FAST for SDSFAST for SDSInput documents (2)Input documents (2)

Worksheet to fill in:Worksheet to fill in:

Missing stakeholdersMissing stakeholders

Missing requirements sourcesMissing requirements sources

Objects (devices, documents, etc.):Objects (devices, documents, etc.):• external to the systemexternal to the system• produced by the systemproduced by the system• internal - used by the systeminternal - used by the system

Services that manipulate the objectsServices that manipulate the objects

Constraints (cost, size, time, accuracy, ..)Constraints (cost, size, time, accuracy, ..)


FAST for SDSFAST for SDSA FAST meetingA FAST meeting

Product justificationProduct justification (every one should (every one should agree) ~ n x 1’agree) ~ n x 1’

Presentation of the worksheetsPresentation of the worksheets (one by (one by one, one, no critiqueno critique) ~ n x 15’) ~ n x 15’

Deciding (Deciding (discussiondiscussion) about:) about:• Stakeholders ~ n x 1’Stakeholders ~ n x 1’• System architecture (objects) ~ n x 5’System architecture (objects) ~ n x 5’• Services ~ n x 10’Services ~ n x 10’• Constraints ~ n x 5’Constraints ~ n x 5’• Validation criteriaValidation criteria ~ n x 5’ ~ n x 5’



Meeting outcomesMeeting outcomes

Direct:Direct:• Meeting minutesMeeting minutes

Indirect:Indirect:• Software Requirements Specification Software Requirements Specification

(validation criteria!)(validation criteria!)


Davis’ Principles for REDavis’ Principles for RE

• Understand the problem before you begin to Understand the problem before you begin to create the analysis modelcreate the analysis model

• Develop prototypes showing how the human-Develop prototypes showing how the human-machine interaction will occurmachine interaction will occur

• Record the origin of and the reason for every Record the origin of and the reason for every requirementrequirement

• Use multiple views of requirements (data, Use multiple views of requirements (data, functional, and behavioural)functional, and behavioural)

• Prioritise requirementsPrioritise requirements• Work to eliminate ambiguityWork to eliminate ambiguity


Viewpoints negotiationViewpoints negotiation

A viewpoint represents partial informationA viewpoint represents partial information


An example of viewpointsAn example of viewpoints

An example: traffic lights An example: traffic lights

Prospective stakeholders Prospective stakeholders (viewpoints):(viewpoints):

• driversdrivers• cyclistscyclists• pedestrians pedestrians • emergency servicesemergency services• the highway authoritythe highway authority

Viewpoint = perspective on a systemViewpoint = perspective on a system


Viewpoints in REViewpoints in RE

Viewpoints: early stages of Viewpoints: early stages of requirements elicitationrequirements elicitation

Viewpoint-oriented methods:Viewpoint-oriented methods:

• CORE (G. Mullery, 1979)CORE (G. Mullery, 1979)

• SADTSADT

• PREviewPREview (I. Sommerville, P. (I. Sommerville, P. Sawyer, 1997)Sawyer, 1997)


Typical viewpointsTypical viewpoints

The system’s The system’s stakeholdersstakeholders (a human, (a human, role, or organisation)role, or organisation)

The system’s The system’s operating environmentoperating environment (other system/component)(other system/component)

The system’s The system’s domaindomain (phenomena (phenomena inherent in the application domain; inherent in the application domain; constraints on the system)constraints on the system)


Basic RE activitiesBasic RE activities

Requirements elicitationRequirements elicitation

<= 50 zł<= 50 zł



for 50 zł ?for 50 zł ?

Requirements analysisRequirements analysis



There is a conflict betweenThere is a conflict between

your requirements ..your requirements ..

Requirements negotiationRequirements negotiation


The PREview processThe PREview process

Requirements elicitationRequirements elicitationRequirements elicitationRequirements elicitation

Requirements analysisRequirements analysisRequirements analysisRequirements analysis

Requirements negotiationRequirements negotiationRequirements negotiationRequirements negotiation RequirementsRequirements

definitiondefinition

RequirementsRequirements

definitiondefinition


Local vs. global requirementsLocal vs. global requirements

Types of requirementsTypes of requirements

Local requirementsLocal requirements

((specific to a particularspecific to a particular

viewpointviewpoint))

Local requirementsLocal requirements

((specific to a particularspecific to a particular

viewpointviewpoint))

Global requirementsGlobal requirements

((likely to be mostlikely to be most

expensive to changeexpensive to change))

Global requirementsGlobal requirements

((likely to be mostlikely to be most

expensive to changeexpensive to change))

GlobalGlobal requirements = requirements = externalexternal requirements requirements


ConcernsConcerns

Concerns:Concerns:• crucial to the successcrucial to the success• non-negotiablenon-negotiable• vaguely definedvaguely defined• concepts rather than concepts rather than

concrete propertiesconcrete properties• serve as constraintsserve as constraints• converted into external converted into external

requirementsrequirements

A concern = a top-level, overriding goalA concern = a top-level, overriding goal


TCS: Train Control SystemTCS: Train Control System

A A humanhuman driver driver

Aim: to Aim: to monitormonitor & to & to interveneintervene when safety is when safety is in dangerin danger

If a train goes If a train goes too fasttoo fast or or crosses a stopping crosses a stopping point, TCS will apply the point, TCS will apply the emergency breaksemergency breaks

Hardware System Hardware System Interface (Interface (HSIHSI))


TCS: Train Control SystemTCS: Train Control System

TCS’ concerns:TCS’ concerns:• SafetySafety (contribution to train (contribution to train

safety)safety)• CompatibilityCompatibility with the HSI with the HSI

interfaceinterface

Concern questionConcern question for for compatibility: compatibility: Is the Is the requirement consistent with requirement consistent with the interface provided by the the interface provided by the HSI module ?HSI module ?


TCS: Train Control SystemTCS: Train Control SystemA requestA request: calculate a minimum : calculate a minimum

breaking distancebreaking distance

Required parametersRequired parameters::• speed, speed, • mass, mass, • line gradient, line gradient, • track surface conditionstrack surface conditions

QuestionQuestion: : are those values are those values available through the HSI available through the HSI interfaceinterface ? ?


Compatibility requirementsCompatibility requirementsExternal requirements for the External requirements for the ‘compatibility’‘compatibility’

concern:concern:

ER4ER4: The TCS software shall be executed in : The TCS software shall be executed in the the Ada environmentAda environment

ER5ER5: The TCS software shall execute within : The TCS software shall execute within the the application cycleapplication cycle of the existing on-board of the existing on-board softwaresoftware

ER6ER6: The TCS software shall react to the : The TCS software shall react to the change of state within change of state within 280 ms280 ms

ER7ER7: The real-time performance of the : The real-time performance of the existing existing on-board softwareon-board software shall be maintained shall be maintained


The safety concernThe safety concern

Hazards identification: Hazards identification: hazard analysis techniques hazard analysis techniques (fault-tree analysis, cause-(fault-tree analysis, cause-consequence analysis, ..)consequence analysis, ..)

TCS’ hazards:TCS’ hazards:• excess speed,excess speed,• overshooting a stopping overshooting a stopping

pointpoint


Safety requirementsSafety requirements

ER1ER1: The system shall detect the : The system shall detect the occurrence of occurrence of excess speedexcess speed

ER2ER2: The system shall detect the : The system shall detect the occurrence of occurrence of overshootovershoot

ER3ER3: The system shall apply : The system shall apply emergency emergency breakingbreaking when either excess speed or when either excess speed or overshoot are detectedovershoot are detected


Viewpoint identificationViewpoint identification

Model of organisationalModel of organisational

environmentenvironment

Model of organisationalModel of organisational


Model of operationalModel of operational


Model of operationalModel of operational


DomainDomain

expertiseexpertise

DomainDomain

expertiseexpertise

UserUser

viewpointsviewpoints

UserUser


ComponentComponent


ComponentComponent


DomainDomain


DomainDomain


StakeholderStakeholder


StakeholderStakeholder



TCS viewpointsTCS viewpoints

StakeholdersStakeholders::• driverdriver• maintenance technicianmaintenance technician• regulator (indirect)regulator (indirect)• normal operation (indirect)normal operation (indirect)• safe state assurance (indirect)safe state assurance (indirect)• erroneous state recovery (ind)erroneous state recovery (ind)

DomainDomain: braking characteristics: braking characteristics

Operating environmentOperating environment: HSI: HSI


Viewpoint structureViewpoint structure

• NameName

• FocusFocus

• Concerns applicable to Concerns applicable to the viewpointthe viewpoint

• Viewpoint sourcesViewpoint sources

• RequirementsRequirements

• HistoryHistory


Safe state assurance viewpointSafe state assurance viewpoint

NameName: Safe state assurance: Safe state assurance

FocusFocus: Detection of dangerous conditions : Detection of dangerous conditions and application of emergency brakingand application of emergency braking

ConcernsConcerns: safety, compatibility: safety, compatibility

SourceSource: customer procurement executive; : customer procurement executive; TCS preliminary hazard analysisTCS preliminary hazard analysis

RequirementsRequirements::

SS1SS1: detection of excess speed: detection of excess speed

SS2SS2: detection of overshooting: detection of overshooting

SS3SS3: frequency of invocation: frequency of invocation


Requirements discoveryRequirements discovery

IdentifierIdentifier: SS1 - detection of : SS1 - detection of excess speedexcess speed

DescriptionDescription: If the speed of the : If the speed of the train is excessive, emergency train is excessive, emergency breaking shall be appliedbreaking shall be applied

RationaleRationale: The train must be : The train must be forced to comply with the forced to comply with the speed limits in force on the speed limits in force on the tracktrack

Change historyChange history: -: -


Requirements elicitationRequirements elicitation

Concern identificationConcern identificationConcern identificationConcern identification

Concern elaborationConcern elaborationConcern elaborationConcern elaboration

Viewpoint identificationViewpoint identificationViewpoint identificationViewpoint identification

Requirements discoveryRequirements discoveryRequirements discoveryRequirements discovery


Requirements analysisRequirements analysis

Safe state assuranceSafe state assurance

SS1 SS2 SS3SS1 SS2 SS3

ER1: 1 0 0ER1: 1 0 0

ER2: 0 1 0ER2: 0 1 0

ER3: 1 1 0ER3: 1 1 0

ER4: 0 0 0ER4: 0 0 0

ER5: 0 0 1000ER5: 0 0 1000

ER6: 0 0 1000ER6: 0 0 1000

ER7: 0 0 1000ER7: 0 0 1000

Saf

ety

Saf

ety

Com

patib

ility

Com

patib

ility

Do not effectDo not effect

each othereach other

Mutually reinforcingMutually reinforcing

ConflictConflict


Requirements definition activitiesRequirements definition activities

1. Identify the structure of the requirements 1. Identify the structure of the requirements document. Divide it into sections.document. Divide it into sections.

2. Identify quality standards and prepare a checklist.2. Identify quality standards and prepare a checklist.

3. Allocate each external requirement into one of the 3. Allocate each external requirement into one of the sections.sections.

4. Repeat activity 3 for each viewpoint requirement.4. Repeat activity 3 for each viewpoint requirement.

5. Apply the checklist from activity 2 to each 5. Apply the checklist from activity 2 to each requirement.requirement.

6. Review each section and eliminate redundancy.6. Review each section and eliminate redundancy.


Further readingsFurther readings

IEEE Guide to Software IEEE Guide to Software Requirements Requirements specification, ANSI/IEEE specification, ANSI/IEEE Standard 830-1984Standard 830-1984

I. Sommerville, P. Sawyer, I. Sommerville, P. Sawyer, Requirements Requirements Engineering, John Wiley & Engineering, John Wiley & Sons, Chichester, 1997Sons, Chichester, 1997


SummarySummary

• Requirements documentRequirements document• The FAST methodThe FAST method• The PREview process: The PREview process:

elicitation, analysis, elicitation, analysis, negotiationnegotiation

At last!At last!


Quality assessmentQuality assessment

• What is your general What is your general impression ? (1 - 6)impression ? (1 - 6)

• Was it too slow or too fast ?Was it too slow or too fast ?

• Did you learn something Did you learn something important to you ?important to you ?

• What to improve and how ?What to improve and how ?

Date post:	22-Dec-2015
Category:	Documents
Upload:	susan-hood
View:	219 times
Download:	3 times