Post on 22-Dec-2015
transcript
Requirements EngineeringRequirements Engineering
Copyright, 1999 © Jerzy R. Nawrocki
Jerzy NawrockiJerzy Nawrocki
Jerzy.Nawrocki@put.poznan.plJerzy.Nawrocki@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
J. Nawrocki, PSP, Lecture 2
Computer-based systemsComputer-based systems
• SoftwareSoftware
• HardwareHardware
• PeoplePeople
• DatabaseDatabase
• DocumentationDocumentation
• ProceduresProcedures
J. Nawrocki, PSP, Lecture 2
Restraining factorsRestraining factors
• AssumptionsAssumptions
• SimplificationsSimplifications
• LimitationsLimitations
• ConstraintsConstraints
• PreferencesPreferences
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
Source Documents for RequirementsSource Documents for Requirements
.doc.doc
ManualManualSRSSRS
SRSSRS
Ver. nVer. n
Ver. n+1Ver. n+1
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
Requirements document (4)Requirements document (4)
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
J. Nawrocki, PSP, Lecture 2
Requirements document (5)Requirements document (5)
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
. . .. . .
J. Nawrocki, PSP, Lecture 2
Requirements document (6)Requirements document (6)
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
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
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)
J. Nawrocki, PSP, Lecture 2
FAST for SDSFAST for SDS
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.
J. Nawrocki, PSP, Lecture 2
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, ..)
J. Nawrocki, PSP, Lecture 2
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’
J. Nawrocki, PSP, Lecture 2
FAST for SDSFAST for SDS
Meeting outcomesMeeting outcomes
Direct:Direct:• Meeting minutesMeeting minutes
Indirect:Indirect:• Software Requirements Specification Software Requirements Specification
(validation criteria!)(validation criteria!)
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
Viewpoints negotiationViewpoints negotiation
A viewpoint represents partial informationA viewpoint represents partial information
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
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)
J. Nawrocki, PSP, Lecture 2
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)
J. Nawrocki, PSP, Lecture 2
Basic RE activitiesBasic RE activities
Requirements elicitationRequirements elicitation
<= 50 zł<= 50 zł
J. Nawrocki, PSP, Lecture 2
Basic RE activitiesBasic RE activities
for 50 zł ?for 50 zł ?
Requirements analysisRequirements analysis
J. Nawrocki, PSP, Lecture 2
Basic RE activitiesBasic RE activities
There is a conflict betweenThere is a conflict between
your requirements ..your requirements ..
Requirements negotiationRequirements negotiation
J. Nawrocki, PSP, Lecture 2
The PREview processThe PREview process
Requirements elicitationRequirements elicitationRequirements elicitationRequirements elicitation
Requirements analysisRequirements analysisRequirements analysisRequirements analysis
Requirements negotiationRequirements negotiationRequirements negotiationRequirements negotiation RequirementsRequirements
definitiondefinition
RequirementsRequirements
definitiondefinition
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
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))
J. Nawrocki, PSP, Lecture 2
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 ?
J. Nawrocki, PSP, Lecture 2
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 ? ?
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
Viewpoint identificationViewpoint identification
Model of organisationalModel of organisational
environmentenvironment
Model of organisationalModel of organisational
environmentenvironment
Model of operationalModel of operational
environmentenvironment
Model of operationalModel of operational
environmentenvironment
DomainDomain
expertiseexpertise
DomainDomain
expertiseexpertise
UserUser
viewpointsviewpoints
UserUser
viewpointsviewpoints
ComponentComponent
viewpointsviewpoints
ComponentComponent
viewpointsviewpoints
DomainDomain
viewpointsviewpoints
DomainDomain
viewpointsviewpoints
StakeholderStakeholder
viewpointsviewpoints
StakeholderStakeholder
viewpointsviewpoints
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
Viewpoint structureViewpoint structure
• NameName
• FocusFocus
• Concerns applicable to Concerns applicable to the viewpointthe viewpoint
• Viewpoint sourcesViewpoint sources
• RequirementsRequirements
• HistoryHistory
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
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: -: -
J. Nawrocki, PSP, Lecture 2
Requirements elicitationRequirements elicitation
Concern identificationConcern identificationConcern identificationConcern identification
Concern elaborationConcern elaborationConcern elaborationConcern elaboration
Viewpoint identificationViewpoint identificationViewpoint identificationViewpoint identification
Requirements discoveryRequirements discoveryRequirements discoveryRequirements discovery
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
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.
J. Nawrocki, PSP, Lecture 2
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
J. Nawrocki, PSP, Lecture 2
SummarySummary
• Requirements documentRequirements document• The FAST methodThe FAST method• The PREview process: The PREview process:
elicitation, analysis, elicitation, analysis, negotiationnegotiation
At last!At last!
J. Nawrocki, PSP, Lecture 2
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 ?