Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
02291: System IntegrationRequirements
Hubert [email protected]
DTU ComputeTechnical University of Denmark
Spring 2020
Activities in Software Developement
I Understand and document what kind of the software thecustomer wants→ Requirements AnalysisI external behaviour : what not how
I Determine how the software is to be built→ Design
I Build the software→ Implementation
I Validate that the software solves the customers problem→ Testing→ Verification→ Evaluation: e.g. User friendlieness
User Requirements vs System Requirements
1. User RequirementsI Used for business decision: go / no-goI Used to solicit offers from software housesI Done by the customer
2. System RequirementsI Define how the system is to be builtI Foundation for planning the project and cost estimationsI Done by the software house
Example of user requirements vs system requirements
Ian Sommerville, Software Engineering - 9
Types of Requirements
Functional RequirementsDescribe what the system should doI e.g. ”The user should be able to plan and book a trip”
Non-functional RequirementsEverything which is not functionalityI Where should the software run (e.g. operating system,
software environment, . . . )I What kind of UI the user prefers (e.g. stand alone
application, Web application, command line interface,graphical interface, . . . )
Categories of non-functional requirements
Ian Sommerville, Software Engineering - 9
Characteristics of good requirements
I TestableI Test whether the system satisfies the requirements or not
→ Measurable PropertiesI Makes non-functional requirements testable
Example of measurable requirements
I ”The system should be easy to use by medical staff andshould be organised in such a way that user errors areminimised”
I Better: ”Medical staff shall be able to use all the systemfunctions after four hours of training. After this training, theaverage number of errors made by experienced users shallnot exceed two per hour of system use.”
Example of measurable requirements
I ”The system should be easy to use by medical staff andshould be organised in such a way that user errors areminimised”
I Better: ”Medical staff shall be able to use all the systemfunctions after four hours of training. After this training, theaverage number of errors made by experienced users shallnot exceed two per hour of system use.”
Possible measures
Ian Sommerville, Software Engineering - 9
Requirements engineering process
Ian Sommerville, Software Engineering - 9
Requirements documentation
I How to document requirements1 Domain model (class diagram, glossary, . . . ) to explain the
domain2 Use cases for functional requirements3 Non-functional requirements
I Requirements documentation are importantI to record the requirementsI to agree upon requirements with the customer
Requirements issues
I As a developer: Refrain from inventing requirements→ ask the customer when in doubt
I Problem descriptions can be very vague→ Discuss with the customer→ Customer knows what he does not want
I Requirements can changeI e.g. after the customer has seen a first version of the
softwareI the business situation has changed
I Consider the contextI What is requirement and what is designI E.g. can choose programming language or it is a
requirement