Upload
brittany-meagan-chapman
View
223
Download
1
Embed Size (px)
Citation preview
Phases of a software engineering project:requirements definition
(Pressman: ch. 7: Requirements engineering)(Sommerville: ch. 6-8 in Requirements) The idea: we have a customer with needs
well defined / untechnical / unclear / something? A customer in the broad sense: a company, a friend, a
financier or yourself? In this phase, we try to formalize and specify the customer needs (in order to implement a
program)
Requi
rem
ents
defini
tion
Impl
emen
tation
Mai
nten
ance
Test
ing
Des
ign
Phases of a software engineering project:requirements definition
The result (should be) (a bunch of) specification documents
Description for customer (external, informal+formal) Description for the designers (internal, informal+formal)
agreement between customer and supplier (the contract!) requirements functional / non-functional cost + (initial) schedule representation in good level of abstraction (not too
specific, not too broad)
But…
Requi
rem
ents
defini
tion
Impl
emen
tation
Mai
nten
ance
Test
ing
Des
ign
Phases of a software engineering project:requirements definition
Two representation levels: For the customer and team user requirements For the team system requirements
Requi
rem
ents
defini
tion
Impl
emen
tation
Mai
nten
ance
Test
ing
Des
ign
Phases of a software engineering project:requirements definition
An example (Sommerville):
1. The software must provide a means of representing and1. accessing external files created by other tools.
1.1 The user should be provided with facilities to define the type of external files1.2 .1.2 Each external file type may have an associated tool which maybe applied to the file1.2 1.3 Each external file type may be represented as a specific icon on the user’s display1.21.4 Facilities should be provided for the icon representing an external file type to be defined by the user
1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the type of the external file to the file represented by the selected icon
1.21.2
User requirement definition
System requirements specification
Phases of a software engineering project:requirements definition
An example (Sommerville):
1. The software must provide a means of representing and1. accessing external files created by other tools.
1.1 The user should be provided with facilities to define the type of external files1.2 .1.2 Each external file type may have an associated tool which maybe applied to the file1.2 1.3 Each external file type may be represented as a specific icon on the user’s display1.21.4 Facilities should be provided for the icon representing an external file type to be defined by the user
1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the type of the external file to the file represented by the selected icon
1.21.2
User requirement definition
System requirements specification
What user wants to do
How the systemmakes itpossible
Phases of a software engineering project:requirements definition: user requirements
User requirement guidelines (Sommerville):1. Use standard format / template2. Use consistent language, classify requirements (!)
(mandatory [’system shall…’, desirable [’system should’] etc.)
3. (- Highlight the keyparts of the text -)4. Avoid computer jargon!5. In addition to text, use diagrams & pictures
Phases of a software engineering project:requirements definition: system requirements
System requirements (Sommerville): Describe external behaviour of the system, not it’s
design or implementation (if possible) In some cases, selected architecture affect on
requirements design is included to requirements Extend the use cases
Phases of a software engineering project:requirements definition
Distinction in types of requirements:functional requirements
Services that system should provide How the system should react particular inputs How the system should behave in particular situations
non-functional requirementsreliability, privacy, safety, efficiency, portability, usability
n-f requirements may affect also to the process, not only to the product (e.g. process quality(?) for safety)
Requi
rem
ents
defini
tion
Impl
emen
tation
Mai
nten
ance
Test
ing
Des
ign
Phases of a software engineering project:requirements definition
Examples of non-functional requirements (Sommerville):”the user interface should be implement as simple HTML without frames or Java applet” (product requirement)
”the system development process and documents shall conform to the process and deliverables defined in XYZ…” (organizational requirement)
”The system shall not disclose any personal information…” (external requirement)
Requi
rem
ents
defini
tion
Impl
emen
tation
Mai
nten
ance
Test
ing
Des
ign
Phases of a software engineering project:requirements definition
Requi
rem
ents
defini
tion
Impl
emen
tation
Mai
nten
ance
Test
ing
Des
ign
Property Measure
Speed Processed transactions/secondUser/Event response timeScreen refresh time
Size M BytesNumber of ROM chips
Ease of use Training timeNumber of help frames
Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability
Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure
Portability Percentage of target dependent statementsNumber of target systems
Metrics for non-functionalrequirements (Sommerville)
Representing user interaction in high level
Forms of representation: Natural language (NL), structured templates (ST), diagrams (D)
In requirements analysis:1. Scenario descriptions2. Use cases3. Sequence diagrams
Representing user interaction in high level:1. scenarios
Scenario description: real-life example of the use case with the ”default progress / phases”
Case example, opening the door: ”The teacher is on the hallway. She wants to enter the class room. She takes the keys from her pocket and opens the door by turning the key in the lock and then pulling the door.”
Informative description to represent the system usage scenarios in high level
Description in natural language (previous example) or with controlled templates.
Representing user interaction in high level:1. scenarios (template)
Scenario description: real-life example of the use case with the ”default progress / phases”
Template: a form-like description, e.g.:Initial assumption: the situationNormal: usual flow of the caseWhat can go wrong: unexpected behaviorOther activities: what is happening simultaneouslySystem state or completion: where we are after this?
Representing user interaction in high level:1. scenarios (template)
Initial assumption: The user has logged on to the LIBSYS system and has located the journal containing the copy of the article.
Normal: The user selects the article to be copied. He or she is then prompted by the system to either provide subscriber information for the journal or to indicate how they will pay for the article. Alternative payment methods are by credit card or by quoting an organisational account number.
The user is then asked to fill in a copyright form that maintains details of the transaction and they then submit this to the LIBSYS system.
The copyright form is checked and, if OK, the PDF version of the article is downloaded to the LIBSYS working area on the user’s computer and the user is informed that it is available. The user is asked to select a printer and a copy of the article is printed. If the article has been flagged as ‘print-only’ it is deleted from the user’s system once the user has confirmed that printing is complete.
An example [Sommerville, ch.7]
Representing user interaction in high level:1. scenarios (template)
An example [Sommerville, ch.7]
What can go wrong: The user may fail to fill in the copyright form correctly. In this case, the form shouldbe re-presented to the user for correction. If the resubmitted form is s till incorrect then the userÕs requestfor the article is rejected.
The payment may be rejected by the system. The userÕs request for the article is rejected.
The article download may fail. Retry until successful or the user terminates the session.
It may not be possible to print the article. If the article is not flagged as Ōprint-onlyÕ then it is held in theLIBSYS workspace. Otherwise, the article is deleted and the userÕs account credited with the cost of thearticle.
Other activities: Simultaneous downloads of other articles.
System state on completion: User is logged on. The downloaded article has been deleted from LIBSYSworkspace if it has been flagged as print-only.
Representing user interaction in high level:2. use cases
How the user interacts with the system Actors involved, the type of the interaction Stick figures, named ellipses + arrow in between
Article printing© Sommerville, 2004
Representing user interaction in high level:2. use cases
How the user interacts with the system Actors involved, the type of the interaction Stick figures, named ellipses + arrow in between Roles of the users / user groups!
© Sommerville, 2004
Article printing
Article search
User administration
Supplier Catalogue services
LibraryUser
LibraryStaff
Representing user interaction in high level:2. use cases
How the user interacts with the system Actors involved, the type of the interaction Stick figures, named ellipses + arrow in between Roles of the users / user groups!
© Sommerville, 2004
Article printing
Article search
User administration
Supplier Catalogue services
LibraryUser
LibraryStaff
Representing user interaction in high level:3. scenario diagrams
Scenario diagrams extend use cases to describe also the inner behavior of the system Interaction between components Timely dependent description
In addition, sequence diagrams are also used to describe design and implementation of the system
how components interacts with each other
Representing user interaction in high level:3. scenario diagrams
© Sommerville, 2004
User
item:Article
copyrightForm:Form
request
complete
myWorkspace:Workspace
myPrinter:Printer
request
return
copyright OK
deliver
article OK
print send
confirminform
delete
Representing user interaction in high level:3. scenario diagrams
© Sommerville, 2004
Scenario diagram is also known by name sequence diagram
in general, sequence diagrams indicate interaction between objects or functional units to fulfill a certain (”bigger”) task.
Timely dependence: sequence diagram states explicitly the order of the interaction
But not (usually) the processing time of a component Relative processing time can be described by the vertical length of the activity
Representing user interaction in high level:3. scenario diagrams
© Sommerville, 2004
User
item:Article
copyrightForm:Form
request
complete
myWorkspace:Workspace
myPrinter:Printer
request
return
copyright OK
deliver
article OK
print send
confirminform
delete
activityof the object
time
Phases of a software engineering project:requirements definition
The output of this phase is software requirements document
IEEE standard IEEE/ANSI 830-1998 Should state WHAT the system should do, not HOW it
does it (how design document) [Sommerville]
Requi
rem
ents
defini
tion
Impl
emen
tation
Mai
nten
ance
Test
ing
Des
ign
Software requirements document
Adapted from Sommerville, Software engineering 7, p.139
Document structure:1) Preface2) Introduction3) Glossary4) User requirements definition5) System architecture6) System requirements specification7) System models8) System evolution9) Appendices10) Index
Software requirements document
Adapted from Sommerville, Software engineering 7, p.139
Document structure:1) Preface-expected readership-version history (of this document)-what is new in this version-summary of changes
Software requirements document
Adapted from Sommerville, Software engineering 7, p.139
Document structure:2) Introduction-need for the system (=why?)-short description of functions-business / strategic objectives of the customer
Software requirements document
Adapted from Sommerville, Software engineering 7, p.139
Document structure:3) Glossary -technical terms explained
Software requirements document
Adapted from Sommerville, Software engineering 7, p.139
Document structure:4) User requirements definition-user requirements-non-functional system requirements-natural language, diagrams, controlled language,
templates…
Software requirements document
Adapted from Sommerville, Software engineering 7, p.139
Document structure:5) System architecture-high-level overview of the system-main modules and their functions represented
Software requirements document
Adapted from Sommerville, Software engineering 7, p.139
Document structure:6) System requirements specification-functional requirements in detail-non-functional requirements in detail
Software requirements document
Adapted from Sommerville, Software engineering 7, p.139
Document structure:7) System models-relations between system modules-object models? Flow models?
Software requirements document
Adapted from Sommerville, Software engineering 7, p.139
Document structure:8) System evolution-explicit notion how the system will adapt for
changing user needshardware evolution
Software requirements document
Adapted from Sommerville, Software engineering 7, p.139
Document structure:9) Appendices-technical, detailed documentation
Software requirements document
Adapted from Sommerville, Software engineering 7, p.139
Document structure:10) Index-for finding descriptions
Software requirements document
Document structure (revisited), essential parts bolded:1) Preface2) Introduction3) Glossary4) User requirements definition5) System architecture6) System requirements specification7) System models8) System evolution9) Appendices10) Index