02291: system integration · characteristics of good requirements i testable i test whether the...

02291: System IntegrationRequirements

Hubert Baumeisterhuba@dtu.dk

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