02291: System Integration Week 2 Hubert Baumeister

(1)

02291: System Integration

Week 2

Hubert Baumeister

hub@imm.dtu.dk

DTU Compute Technical University of Denmark

Spring 2013

(2)

Activities in Software Developement

I

Understand and document what kind of the software the customer wants

→ Requirements Analysis

I external behaviour: whatnothow

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

(4)

User Requirements vs System Requirements

1. User Requirements

I Used for business decision: go / no-go

I Used to solicit offers from software houses

I Done by the customer

2. System Requirements

I Define how the system is to be built

I Foundation for planning the project and cost estimations

I Done by the software house

(5)

Example of user requirements vs system requirements

(6)

Travel Agency Example

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

Problem Description

TravelGood wants to offer a trip-planning and booking

application to its customers. The application should allow the

customer to plan trips consisting of flights and hotels. First the

customer should be able to assemble the trip, before he then

books all the flights and hotels in on step. The user should be

able to plan several trips. Furthermore it should be possible to

cancel already booked trips.

(7)

Types of Requirements

Functional Requirements

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

I

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.

I

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, . . . )

(8)

Categories of non-functional requirements

Ian Sommerville, Software Engineering - 9

(9)

Characteristics of good requirements

I

testable

I One should be able to devise a test that can decide whether the system satisfies the requirements or not.

I Tests can be manual or automatic

I

mesurable

I Makes non-functional requirements testable

(10)

Example of measurable requirements

I

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

I

Better: ”Medical staff shall be able to use all the system

functions after four hours of training. After this training, the

average number of errors made by experienced users shall

not exceed two per hour of system use.”

(11)

Example of measurable requirements

I

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

I

Better: ”Medical staff shall be able to use all the system

functions after four hours of training. After this training, the

average number of errors made by experienced users shall

not exceed two per hour of system use.”

(12)

Possible measures

Ian Sommerville, Software Engineering - 9

(13)

Requirements engineering process

Ian Sommerville, Software Engineering - 9 course 02264: Requirements Engieering

(14)

Requirements Engineering Process: Techniques

I

Elicitation

I Interviews

I Domain Model

I Use Cases / User Stories

I

Specification

I Domain Model

I Use Cases / User Stories

I

Validation

I Criteria: Validity, Consistent, Complete, Realistic, . . .

I Techniques: Inspection, Test-case generation, Prototyping

(15)

Contents of the software requirements document

I

Generic document structure (IEEE standard)

I Preface

I Introduction

I Glossary/Domain Model

I User requirements definition

I System architecture

I System requirements specification

I e.g. Use Case Diagram and detailed use cases

I System models

I (System evolution)

I Appendices

I Index

(16)

Users of the software requirements document

(17)

Requirements documentation

I

How to document requirements

1 Use casesfor functional requirements

2 Domain model (class diagram, glossary, . . . ) to explain the domain

3 Non-functional requirements

I

Requirements documentation are important

I torecord the requirements

I traceability

I to agree upon requirements with the customer

→ requirements creep

I

Question: how to deal with changing and unclear requirements?

→ use an agile process

→ freeze the specification of the requirements as late as possible

(18)

Requirements issues

I

Refrain from inventing requirements

I

Problem descriptions can be very vague

→ Discuss with the customer

→ Customer knows what he does not want

I

Requirements can change

I e.g. after thecustomer has seen a first version of the software

I thebusiness situationhas changed (cf. finance crises)

(19)

Domain model

I

Purpose: capture the customer’s knowledge of the domain so that the system builders have the same knowledge

I

Helps customer and system builders to speak the same language

→

Necessary to define the terminology used

→ Glossary

→

Relationships between terms are shown in a class diagram

→ Related to the concept of anontology

→

If necessary, make business processes visible

→ Represented by UML Activity Diagrams

(21)

Glossary

I

List of terms with explanations

I

Terms can be nouns (e.g. those mentioned in a problem description) but also verbs or adjectives e.t.c.

I

Warning

I Capture only knowledge relevant for the application

I Don’t try to capture all possible knowledge

(22)

Example

Part of a glossary for a library application Book

I

A book is a is a conceptual entity in a library. A book is defined by its title, the name of his authors, the publisher and the edition. A library can have several copies of the same book.

Copy

I

A copy is a physical copy of a particular book. For example, the library has three copies of the book ”Using UML” by Perdiate Stevens.

. . .

(23)

Terms and their relations

I

Class diagrams

I

Usually

I Classes (for nouns)

I Associations: for static relationships

I Generalizations

I Use of attributes possible

I Often withoutoperations

I verbs→operations

I

Warning

I Showscustomer knowledge

I Should not be biased by implementation

(24)

Domain model (terms and their relations)

Associations Name of the association Multiplicities Class

Attributes

Reading direction Generalization

(25)

Purpose of Use Cases

I

Capture mainly functional requirements

I

Use Cases for planning

I Use Case Driven Design

I Planning Game (from Extreme Programming)

I

System Validation

I Show that the sceanarios of the use cases can berealized by the system, e.g. by drawing sequence diagrams

→ Walking the use case

I

Use Cases describe what is to be achieved and not how

(27)

Def Use Case

Introduced by Ivar Jacobson in the early 1990’s

Use Case

A Use Case is a set of interaction scenarios of one or several actors with the system serving a common goal.

I

Interaction

I Anything theactor does with the system

I System responses

I Effects visible/important to the customer

I

Not part of the interaction: What the system internally does

(28)

Use Case

1. Use case diagrams

I Gives an overview of the use cases and actors for a system

I Uses graphical notation

I Shows relations between actors: Generalization:

I Shows relations between use cases: Generalization, Inclusion,Extension

2. Simple use case description

I Textual description of what is achieved by the use case

3. Detailed use case description

I Detailed description of what is achieved by the use case

I Follows a use casetemplate

I Describes pre- / postconditions, main- and secondary scenarios (among others)

(29)

Example: Use Case Diagram

(30)

Example: Simple Use case description

Borrow Book

A borrower presents a book or DVD. the system checks that the

potential borrower is a member of the library, and does not

already have 5 books or DVDs on loan. If both checks succeed,

the system records that this library member has this copy of the

book on loan.

(31)

Example: Detailed Use Case description

(32)

Detailed use cases: Template

Template to be used in this course for detailed use case descriptions

name: The name of the use case

description:A short description of the use case actor:One or more actors who interact with the system

precondition:Possible assumptions on the system state to enable the use case

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

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

alternative scnearios:Secondary scenarios;failscenarios

postcondition:What has been achieved after the use case has been executed?

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

(33)

Travel Agency: detailed use case list available flights

name: list available flights

description:the user checks for available flights actor:user

main scenario:

1. The user provides information about the city to travel to and the arrival and departure dates

2. The system provides a list of available flights with prices and booking number

alternative scenario:

1a. The input data is not correct (see below)

2. The sytem notifies the user of that fact and terminates and starts the use case from the beginning

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

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

(34)

Travel Agency: detailed use case cancel trip

name: cancel trip

description: cancels a trip that was booked actor: user

precondition:

I the trip must have been booked

I the first date for a hotel or flight booking must be one day in the future

main scenario:

1. user selects trip for cancellation

2. the system shows how much it will cost to cancel the trip 3. selected trip will be cancelled after a confirmation

(35)

Travel Agency: detailed use case plan trip

name: plan trip

description: The user plans a trip consisting of hotels and flights

actor: user main scenario:

repeat any of the following operations in any oder until finished

1. list avaialbe flights (use case) 2. add flight to trip (use case) 3. list availabe 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

(36)

Travel Agency: detailed use case save trip

name: save trip

description: provides the current trip with a name and saves it for later retrievel

actor: user

precondition: the current trip is not empty main scenario:

1. user provides a name for the trip

alternative scenarios:

1: the name is not valid

2: notify the user of the fact and end the use case 1: a trip with the name already exists

2: ask the user if the trip should overwrite the stored trip 3a: If yes, overwrite the stored trip

3b: If no, end the use case

(37)

Use Case Diagrams Concepts

I

Use case diagram = special type of class diagram

I Classes: actor and use case

I Associations: Lines between actor and use case (no arrow)

I Dependencies: Broken arrows between use cases (a broken line)

I Inheritance: Lines with a closed arrow (example later)

(38)

Actors

I

Who should be actor

I Beneficionary of the use case

I Participant in the use case

I

What role does the actor play

I not specific persons like action John Doe

I ”A person wearing a particular hat”

I

Actors can be

I Human: e.g the user of the system

I Non Human: an external system or device

(39)

Subject of a use case / system boundary

I

The class described by a set of use cases

I

Usually these are systems or subsystems

I

Shown as a subject/system boundary

(40)

Use cases and subsystems

Game Server Phone

MUD

* 1

→

Use cases: on any abstraction level

→

Describe requirements on the system, as well as the subsystem level

→

Subsystems of a system don’t appear as actors

(41)

Relationships among use cases and actors

I

Between use cases

I Includes

I Extends

I Generalizations

I

Between actors

I Generalization

→

Note: Almost all model elements in the UML can be used

to inherit from

(42)

Includes Relationship

(43)

Extends Relationship

(44)

Extends Relationship

I

One use case can extend another use case at a given extension point

I

extends is used if one wants to indicate variation of the original use case

I

extends implies optional path

I

includes implies mandatory path

(45)

Extends Relationship

(46)

Generalisation between actors

(47)

Generalisation between use cases

I

Special use case: same or more specialised goal then the

general use case

(48)

Types of use cases

a) Business use cases (kite level use case (from Alistair Cockburn))

b) System use cases / sea level use case

c) Use cases included in sea level use cases are called fish level use cases by Alistair Cockburn

UML Destilled, Martin Fowler

(49)

Travel Agency functional requirements: Business use

cases

(50)

Travel Agency functional requirements: System level use cases (only part of the system)

Search Avaialbe Flights

Search Available Hotels

User

TravelAgency

Add Hotel to Trip Add Flight to Trip

List Trip Delete Hotel from Trip

Delete Flight from Trip

(51)

Travel Agency functional requirements: System level

use cases relating to busines use cases

(52)

Use Case Benefits

I

Technique for capturing the functional requirements of a system

I

Easily understandable

I

Easy to check for completness

I Use case diagram

I Use case main vs. alternative scenarios: catch all possible interactions

I

Use cases in planning

I Basis for the estimating, scheduling, and validating effort

I Use cases can be relatively easily added and removed from a software project as priorities change.

I

Test Cases (System, User Acceptance and Functional) can

be directly derived from the use cases

(53)

Use Case Limitations

I

Not good for capturing non-interaction based requirements e.g.

I algorithm or mathematical requirements

I non-functional requirements (such as platform, performance, timing, or safety-critical aspects)

I

Abstracts away from the GUI

I Use case theory suggests that UI not be reflected in use cases

I but GUI mock ups (paper based, powerpoint based, etc.), prototypes may be more useful than abstract functionality

(54)

Summary

I

Requirements Engineering

I What the customer expects from the system

I

Requirements Process: Elicitation, Documentation, Validation

I

Requirements Elicitation: Interviews, Scenarios, Use Cases

I

Requirements Documentation

I Domain Model: Class diagram + possibilty activity diagram for business processes

I Use Cases:

I 1) Use Case Diagram→provides an overview over the functionality of the system

I 2) Detailed use cases→provide the details of the

I User Stories

I

Use case driven developement

(56)

Tools

I

Two classes: simple drawing tools and meta model based modelling tools

I

Drawing tools

I UMLet (Eclipse pluginwww.umlet.com)

I Violet UML (Eclipse pluginhttp:

//alexdp.free.fr/violetumleditor/page.php)

I Visio (Windows only; available though DTU agreement with Microsoft)

I

Modeling tools

I Topcased (www.topcased.org)

I MagicDraw

I Rational Modeller (IBM)

I Eclipse UML (Omondowww.omondo.com)

I eUML (Soyatecwww.soyatec.com) (Only class and sequence diagrams)

(57)

Tools

I

Two classes: simple drawing tools and meta model based modelling tools

I

Drawing tools

I

Modeling tools

I MagicDraw

(58)

Tools

I

Two classes: simple drawing tools and meta model based modelling tools

I

Drawing tools

I

Modeling tools

I MagicDraw

02291: System Integration Week 2 Hubert Baumeister