Software Engineering I (02161) · A use case diagram provides and overview over the use cases of a systemandwhois using the functionality. Detailed Use Case description A detailed

Software Engineering I (02161)Week 2

Assoc. Prof. Hubert Baumeister

Informatics and Mathematical ModellingTechnical University of Denmark

Spring 2011

c©2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 49 / 92

Recap

Recap

Software Engineering is an engineering discipline focusing ontheories, methods, and tools for the production of (large) softwareBasic activities in software engineering (each with their own set oftheories, methods, and tools):

Understand and document what kind of the software the customerwantsDetermine how the software is to be builtBuild the softwareValidate that the software solves the customers problem

Software development process: Organise the production of thesoftware

WaterfallRational Unified Process (iterative process)eXtreme Programming (agile process)Lean software development (agile process)

Exercise: Library application: Set of tests to be implemented


What are software requirements?

Requirements Engineering

Requirements AnalysisUnderstand and document the kind of software the customer wants

Describe mainly the external behaviour of the system and not howit is realised

But: Sometime the costumer defines realisation constraints: E.g.the application should be a Web application, . . .

Steps1) Discover and understand the requirements2) Document the requirements3) Validate the requirements→ iterative

Techniques for discovering, understanding, and documentationUse Cases

Detailed Use CasesUse Case Diagram

Glossary



Travel Agency Example

The travel agency TravelGood comes to you as software developerswith the following proposal for a software project:

Problem description or user requirementsTravelGood wants to offer a trip-planning and booking application to itscustomers. The application should allow the customer to plan tripsconsisting of flights and hotels. First the customer should be able toassemble the trip, before he then books all the flights and hotels in onstep. The user should be able to plan several trips. Furthermore itshould be possible to cancel already booked trips.

What do you do?What are the system requirements?



Usage of the term ”requirement”

1. User RequirementsUsed to describe the requirements in informal language and inbroad terms.Intended, e.g., to solicit bids from software companies

2. System RequirementsMore precise than user requirementsUsed in the contract phase to define how the system should work



Requirements: Issues

Problem descriptions can be very vague→ it is important to discuss with the customer what his/her

requirements are→ Process called: Requirements elicitation

Requirements can changee.g. after the customer has seen a first version of the softwarethe business situation has changed (cf. finance crises)

Requirements need to be documentedCustomer and software developer agree on what the system shouldbe doing)Several ways: user stories and acceptance tests or

use cases (use case diagram, detailed use case)



Types of Requirements

Functional Requirements

Describe the users expectation which functionalities the system should have; i.e. whatthe system should do E.g.

the user should be able to plan and book a trip

Non-functional Requirements

Everything which the user requires from the system, but which is not functionality: E.g.

Where should the software run (e.g. operating system, software environment,. . . )What kind of UI the user prefers (e.g. stand alone application, Web application,command line interface, graphical interface, . . . )

Travel Agency Example of non-functional requirementsSystem should be a Web application accessible from all operatingsystems and most of the Web browsersIt must be possible to deploy the Web application in a standardJava application servers like GlassFish or TomcatThe system should be easy to handle (it has to a pass a usabilitytest)c©2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 57 / 92


Categories of non-functional requirements

Ian Sommerville, Software Engineering - 9



Non-functional requirements need to be measurable

The system should be easy to use by medical staff and should beorganised in such a way that user errors are minimised

Can’t be measured; when does the system satisfy the requirement?Better: Medical staff shall be able to use all the system functionsafter four hours of training. After this training, the average numberof errors made by experienced users shall not exceed two perhour of system use.



Requirements engineering process

Requirements engineering process

A spiral view of the requirements engineering process



Requirements engineering process Requirements elicitation

Requirements elicitation and analysis

How to discover the requirements?Several techniques

InterviewsUse casesScenarios→ User stories in XP. . .



Travel Agency functional requirements: Overview usecase diagram



Use Case

Use Case (Wikipedia)A use case in software engineering and systems engineering is adescription of a system’s behaviour as it responds to a requestthat originates from outside of that system.In other words, a use case describes who can do what with thesystem in question.

Use Case DiagramA use case diagram provides and overview over the use cases of asystem and who is using the functionality.

Detailed Use Case descriptionA detailed use case description describes the interaction between theuser and the system as a set of scenarios



Travel Agency functional requirements: Detailed usecase diagram manage trip



Travel Agency functional requirements: Detailed usecase diagram plan trip



Travel Agency functional requirements: Detailed usecase diagram manage flights



Travel Agency functional requirements: Detailed usecase diagram manage hotels



Detailed use cases: Template

Template to be used for detailed use case descriptions

name: The name of the use casedescription: A short description of the use caseactor: One or more actors who interact with the systemprecondition: Possible assumptions on the system state to enable the use case

main scenario: A description of the main interaction between user and system

→ Note: should only explain what the system does from the user’sperspective

alternative scenarios:note: Used for everything that does not fit in the above categories

Note: One can find many different types of templates in the literature

However, all have in common to state the main scenario and thealternative scenarios”A use case is a set of scenarios tied together by a common usergoal” (From Martin Fowler, UML Destilled)



Travel Agency: detailed use case list available flights

name: list available flightsdescription: the user checks for available flightsactor: user

main scenario:1. The user provides information about the city to travel to and the

arrival and departure dates2. The system provides a list of available flights with prices and

booking numberalternative scenario:1a. The input data is not correct (see below)

2. The system notifies the user of that fact and terminates and starts theuse case from the beginning

2a. There are no flights matching the users data3. The use case starts from the beginning

note: The input data is correct, if the city exists (e.g. is correctly spelled), thearrival date and the departure date are both dates, the arrival date is before thedeparture date, arrival date is 2 days in the future, and the departure date is notmore then one year in the future



Travel Agency: detailed use case cancel trip

name: cancel tripdescription: cancels a trip that was bookedactor: userprecondition:

the trip must have been bookedthe first date for a hotel or flight booking must be one day in thefuture

main scenario:1. user selects trip for cancellation2. the system shows how much it will cost to cancel the trip3. selected trip will be cancelled after a confirmation



Travel Agency: detailed use case plan trip

name: plan tripdescription: The user plans a trip consisting of hotels and flightsactor: usermain scenario:

repeat any of the following operations in any oder until finished1. list available flights (use case)2. add flight to trip (use case)3. list available hotels (use case)4. add hotel to trip (use case)5. list trip (use case)6. delete hotel from trip (use case)7. delete flight from tip (use case)

Note: the trip being planned is referred to as the current trip



Travel Agency: detailed use case save trip

name: save tripdescription: provides the current trip with a name and saves it forlater retrievalactor: userprecondition: the current trip is not emptymain scenario:

1. user provides a name for the tripalternative scenarios:

1: the name is not valid2: notify the user of the fact and end the use case

1: a trip with the name already exists2: ask the user if the trip should overwrite the stored trip

3a: If yes, overwrite the stored trip3b: If no, end the use case



User stories from eXtreme Programming

A user story describes a scenario of interaction with the systemrelevant for the user of the systemCan be, e.g., a main scenario of a use case; but also one of thealternative or exceptional scenarios

e.g. borrow book scenariofocus on: books (not general media), number of books borrowed(no overdue books), e.t.c.On contrast: a use case for borrow books need to describe allthese aspects

Can define also non-functional requirementsAre documented informally as index cards and formally usingacceptance tests



Example of a User story index card

Kent Beck, Extreme Programming, 1st ed.



User stories and requirements engineering

Important: Requirements engineering is done in parallel with thedevelopment of the system

User story index cards are created by the customer and discussedwith the developerUser story index cards are assigned to iterations based onimportance to the customerOnly within each iteration the user stories are refined and tests areimplemented

Two level approach1) Make coarse user stories for planning2) Detail user stories when they are about to be implemented→ Compare with waterfall: Already in the requirements phase make

all the requirements as precise and detailed as possible


Requirements engineering process Software requirements document

Contents of the software requirements document

Generic document structure (IEEE standard)PrefaceIntroductionGlossaryUser requirements definitionSystem architectureSystem requirements specification

e.g. Use Case Diagram and detailed use cases

System models(System evolution)AppendicesIndex



Users of the software requirements document



Glossary

Purpose: capture the customer’s knowledge of the domain so thatthe system builders have the same knowledgeHelps customer and system builders to speak the same language

→ Necessary to define the terminology used→ Glossary

glossary (plural glossaries)”1. (lexicography) A list of terms in a particular domain of knowledgewith the definitions for those terms.” (Wikitionary)

List of terms with explanationsTerms can be nouns (e.g. those mentioned in a problemdescription) but also verbs or adjectives e.t.c.



Example

Part of a glossary for the travel agency

User: The person who is using the travel agencyTrip: A trip is a collection of hotel and flight informations. A trip can be bookedand, if booked, cancelled.Booking a trip: A trip is booked by making a hotel reservation for the hotels onthe trip and a flight booking for the flights of the tripFlight booking: The flight reservation is booked with the flight agency and ispayed.Reserving a hotel: A hotel is reserved if the hotel informed that a guest will bearriving for a certain amount of time. It is possible that the hotel reservationrequires a credit card guarantee.. . .

Warning

Capture only knowledge relevant for the applicationDon’t try to capture all possible knowledge


Requirements engineering process Requirements validation

Requirements validation

ChecksValidity checks

Does the system fit the needs of the user?Consistency checks

Are the requirements consistent with each other?Completeness checks

Are they complete?Realism checks

Can they be realised?Verifiability

Can one decide if the system fulfils a requirement or not?

Validation techniquesRequirements reviewsPrototypingTest-case generation


Summary

Summary

Requirements analysis is about finding out what the softwareshould be able to doTwo types of requirements functional and non-functionalrequirementsProcess: Discover, Document, ValidateUse cases

Used for both finding and documenting the requirementsWhat are the functions the user can perform with the software?

Detailed use cases: Detailed (textual) description of what thesoftware should doUse case diagram: Graphical overview over the functionality of thesoftware

User Stories (used in XP)Focus on interaction scenarios relevant for the user; tell a ”story”about the system

Glossary: Document domain knowledge and define a commonlanguage between customer and software developer


Documents

Software Engineering I (02161) · A use case diagram provides and overview over the use cases of a systemandwhois using the functionality. Detailed Use Case description A detailed