software engineering lecturer: giuseppe santucci (thanks to … · 2015-05-18 · requirement...

Software engineering

Lecturer:Giuseppe Santucci

(Thanks to Paolo Ciancarini)

Requirement engineering

1

Main issues

• Specification

• Requirements specification

• Conceptual models

• Requirements engineering

• UML

2

Specification (Specifica)• Explicit set of requirements:

– functional

– not functional• quality!

that must be satisfied by a material, product or service

• Detailed description of the design and development criteria of an artifact

• Detailed description of an algorithm, a Java class, an interface ...

• ...3

Kinds of specifications

• Requirements (between the study of feasibility and the design):

– Documents that define the system functionalities

– Agreement between customer and developer

• Design (during the design phase):

– Documents that define the project requirements

– Agreement between designers and implementers

• SW modules (during implementation):

– Document that defines what should be a SW module

– Agreement between implementers and programmers that will use it

4

What is a requirement?

• An abstract and vague description of a system

service or a constraint, or a detailed

specification of a system function

• This because requirements have a double face:

– They are the basis for bidding for a contract, so they

must be open to different interpretations

– They are the basis for granting a contract: then they

must include sufficient details to exclude unwanted

interpretations

5

Requirement specification• Definition of

– functionalities

– constraints

– performance

– interfaces

– quality criteria

– any other user-required feature

• Collected in a Software Requirements Specification document (SRS) that should be – complete

– accurate

– consistent

– unambiguous

– understandable

• to both the customer and developer

6

Goals of a SRS document

• Give feedback to the user

• Decompose a problem in independent sub-

problems

• Input for the design phase

• Input for the testing, verification, and validation

phases

• It is not a design document

• It says what, not how the system will do

7

Relevance of a SRS document

• Is the convergence of the points of view of the customer, user, and developer

• Provides a reference point for the validation of the final product

• Is a prerequisite for the SW quality:

– errors in SRS-system --> errors in the system

• Reduces development costs, as it facilitates the discovery of defects

8

Useful questions when writing a requirement

document

• What is the goal of the system?

• What is the goal of its users?

• How it will interface with users, hardware, and other software systems?,

• Which perfomance do we expect from the system?

• Which constraints should be satisfied?

9

Problems with Natural Language

• Specification writers and readers should use the same NL wording with the same meaning, but this is rarely the case

• A specification written in NL has always several alternative interpretations

• The requirements should be partitioned and ranked but NL is not suitable for this

10

Techniques for requirements elicitation

• Interviews and forms

• Requirements workshop

• Brainstorming

• Storyboards

• Use cases

• Prototyping

11

Main activities during the elicitation

• Identify the actors

• Identify the use cases

• Identify the non functional requirements

12

Requirement specification techniques

• Informal (a system model does not exist):• Natural language

• Interviews

• Questionnaires

• Conceptual models:• System and domain representations are included in the SRS

document

• Less or more formal

• Prototype:• Working

• Not working (paper based prototype)

13

Conceptual models

• Structured analysis:

– Data Flow Diagrams (DFD)

– Function decompositions

– Data oriented models, e.g., ER

• OO analysis:

– Decomposition of the system in domain "concepts"

– Modeling languages, e.g., UML

14

Kinds of specification languages

• Two orthogonal classification coordinates

• Semantics

– informal

– semiformal

– Formal

• Style

– operational

– descriptive

15

Semantics

• Informal specifications

– Natural language (good for the customer)

• Semi-formal specifications

– Comprehensible but ambiguous

– Graphical notation + natural language

– Widely used

• Formal specifications

– Not ambiguous

– Automatic consistency check

– Not easy to use

16

Style: operational• It describes the needed steps

• Example (sorting a vector): • A is a vector of n elements.

• The result of sorting A is a vector B of n elements:

– the first element is the minimum (if multiple elements have the same value, each of them is acceptable),

– the second element is the minimum in the vector of n-1 elements obtained by eliminating the minimum

– third and subsequent elements are defined in the same way, until all items are disposed in place

17

Style: descriptive

• It describes the desired properties in a purely declarative way

• Example (sorting a vector):• A is vector of n elements.

• The result of sorting A is a vector B n such that:

– it is an A permutation:

– it is ordered

– (in case the concept of permutation and sorting were not sufficiently clear, we can specify them with the same style, e.g., for every v [i], v [j] If i > j then v [i] > = v [j])

18

Some considerations

• Each of the styles (operational/descriptive) suggests a different way to implement the sorting

• It is not required to implement the sorting in any of that ways (although operational style strongly "suggests" a choice)

• Descriptive specifications are typically more general than operational but can lead to less efficient implementations

19

Example (Operational): DFD

• DFD (Data Flow Diagrams) are used to specify information system functionalities

• Four elements:

– Functions

– Data flow

– Data store

– Interface, producing or consuming data

Customer management

InfoCustomer

Employee

20

Example

management

Invoice

management

InfoCUSTOMERS

EmployeeInfoINVOICES

InfoITEMS

Customer

visualization andprinting

Invoice

Employee

21

Comments

• A DFD diagram can be refined, for example specifying the function "manage invoices"

• Symbol semantics is specified only by chosen identifiers

• In some cases this is sufficient, whereas in others you need a more precise definition (which is not part of the DFD)

22

Comments (2)• Control is not specified:

• D needs A, B and C to be executed, but can start only when only A it is done?

• (E) and (F) need the same data from D?

D

E

F

C

B

A

23

Comments (3)

• DFD is a semi formal model:

– syntax is formal

– semantics is not formal

24

Other operational example: finite state automata

• A FSA defines admissible states, inputs, and transitions:– S is the finite and not empty set of state

– I is the set of inputs

– d is the transition function S X I -> S

• Example: a lamp (2 states, 1 input)

Push button

OffOn

25

Push button

FSA with output

• <S, I, O, d, t, s0>

– S is the finite and not empty set of state

– I is the set of inputs

– 0 is the set of outputs

– d is the transition function S X I -> S

– t the function that computes the output S X I -> 0

– s0 is the initial state• Example: office phone (9 states, 6 inputs, 3 outputs)

26

Phone down

Waiting

first digit

lift phone/

internal tone

Waiting first

external digit

0/external tone

Waiting next

internal digit

1..9/-

hang up/-

Waiting next

external digit

1..9/- 0..9/-

0..9/-

valid number reached/

Waiting

connection

Remote phone

ringing

Talk

No conversation

is possible

busy/

busy tone

free/

ringing tone

lift remote phone/-

27

hang up/-

hang up/-

hang up/-

hang up/-

valid number reached/

Comments• Finite state automata are an example of a formal

specification (syntax and semantics are formally defined)

• They are particularly suited for describing control flow (that is missing in the DFD)

• They are suitable for describing synchronous systems and non-concurrent (for each instant of time the global state of the system should be defined and only a single transition may happen)

• Not easy to use!!!

28

Example (descriptive, semiformal) : ER model

Cliente Articolo

Fattura

0,N

1,1

1,N

1,N

n.pezzi

descaliquotacosto

#fatturadata emissionedata pagamento

29

Requirements engineering• Problem analysis

– Focus on: • problem

• constraints

• possible solutions

– The final goal is to understand what the system should do

• Requirements specification– Map requirements in a structured document (SRS)

• Requirements validation– Review requirements with

• a) technical people and

• b) customer (contract review)

30

Categories of requirements

• Functional requirements: describe the behavior and interactions between the system and its environment– Eg.: the e-learning platform tracks student’s activities

– Eg.: the platform is used for both reading texts and participating to exams

• Non functional requirements: describe the system properties visible to the users and not directly related to its functional behavior– Eg.: the platform has to manage up to 100 students concurrently

– Eg.: If a user posts a question he must have an an answer in max 48h

– Eg.: The platform has to be available 24h per day 7 days per week (24/7)

• Constraints(“Pseudo requirements”): defined by the stakeholders– Eg.: The programming language will be Java

– Eg.: The platform must deal with documents written in Office Word on Vista

31

What is NOT a requirement?

• System structure (or “architecture”)

• Implementation technologies

• Development method

• Development environment

• Programming language

• Reuse and portability concerns

• Instead the real world domain descriptions are included

in the requirement document

32

Conflicts and priorities

• Different stakeholders have different priorities

• Final users have expectations different from

funding people

• Difficult to anticipate all problems and conflicts

• Prototyping is a useful technique to mitigate

conflicts and anticipate problems

33

Using NL: the library example

A library is managed by some staff and has some

users who can search and borrow books. A user

can keep a book for one month, then has to give it

back. The library contains one million books, and

the staff buy about 10.000 books each year. A new

book cannot be borrowed before six weeks. If a

book is not available, the request is put in a waiting

list. When a book is lost it is deleted from the

catalog and its waiting list is canceled…

34

The library example

– “The system shall maintain records of all library materials including books, serials, newspapers and magazines, video and audio tapes, reports, collections of transparencies, computer disks and CD-ROMS.”

– “The system shall allow the users to search for an item by title, author, or ISBN.”

– “The system’s user interface shall be displayed using Firefox 2 and above”

– “The system shall support at least 20 transactions per second.”

– “There should be no more than 3 clicks from homepage to reach search results.”

– “The access permissions for system data may only be changed by the system’s data administrator”

35

Using structured NL

• The NL can be restricted in order to increase clarity and precision

• A structured NL can avoid some typical ambiguities by constraining the requirement documents to have some structure

• Usually a structured NL specification is based on a pre-defined form

36

Example

ECLIP SE/W orkstation/Tools/DE/FS/3.5.1

Func tion Add node

Desc ription Adds a node to an existing de sign. The user selects the ty pe of node, and its position.W hen a dde d to the design, the node bec ome s the current selection. The user choose s the node position bymoving the cursor to the a rea whe re the node is added.

Inputs Node ty pe , Node position, De sign identifie r.

Sourc e Node ty pe a nd Node position are input by the user, De sign identifie r from the database.

Outputs Design ide ntifier.

Destination The de sign database. The design is com mitted to the database on c omple tion of theoperation.

Requires Design graph rooted at input design ide ntifier.

Pre-c ondition The de sign is open and display ed on the user' s sc reen.

Post-condition The de sign is uncha nge d apa rt from the addition of a node of the specified typeat the given position.

Side -effec ts None

Definition: ECLIPSE/W orkstation/Tools/DE/RD/3.5.1

37

Non-functional requirements• Non-functional requirements are criteria usable to

judge the operation of a system, rather than its specific behaviors

• They define the critical properties of a system. Examples: reliability, throughput, answer time, security, user-friendliness

• Some non-functional requirements put constraints on the system development process or infrastructure

• Non functional requirements are often more important than functional ones, because if they are not satisfied the system will be refused

38

Tracking techniques

• Assign a unique id to each requirement

• Cross reference of requirements in a traceability matrix

• Hypertext management of requirements in order to support effective navigation mechanisms

40

The IEEE 830-1993 standard

• The Software Requirement Specification

document (SRS) must correctly define all of

the software requirements, but no more

• Eight qualities:1. Unambigous

2. Correct

3. Complete

4. Verifiable

5. Consistent

6. Modifiable

7. Traceable

8. Ranked (for importance and/or stability)

41

SRS document characteristics (1)

• Correctness– Is it representing requirements in a correct way?

• Completeness– Internal: any used concept (acronym) must be defined

– With respect to requirements: all requirements must be included in the SRS

– Typically it is an incremental process

• too many details

• some requirements rise during the development

• Consistency– No contradictions

42


• Non-ambiguity

– Any concept, requirement has a unique interpretation

• Verifiability

– A precondition is the non-ambiguity

– Same properties (BUT not all) are verifiable in a rigorous way

• To handle the requirements we need

– Modifiability (e.g., not duplications)

– Traceability (e.g., section numbering, statement numbering, requirement numbering)

43


• Traceability– The source of each requirement is clear and it is possible to

reference it in the future (def. IEEE)

– Traceability matrixes • requirements/functionality

• requirements/subsystems

• requirements/interfaces

• dependency among requirements

– Forward traceability: requirement->> code

– Backward traceability: code-->> requirement

44

SRS structureStandard IEEE 830-1993:

• Table of contents

• 1.Introduction

– 1.1. Purpose

– 1.2. Scope

– 1.3. Definitions, Acronyms, and Abbreviations

– 1.4. References

– 1.5. Overview

• 2.General Description

– 2.1. Product Perspective

– 2.2. Product Functions

– 2.3. User Characteristics

– 2.4. General Constraints

– 2.5. Assumptions and Dependencies

45

SRS structure (2)• 3.Specific Requirements

– 3.1. External Interface Requirements•3.1.1. User Interfaces

•3.1.2. Hardware Interfaces

•3.1.3. Software Interfaces

•3.1.4. Communications Interfaces

– 3.2. Functional Requirements / Objects

– 3.3. Performances Requirements

– 3.4. Logical database requirements

– 3.5. Design Constraints•3.5.1 Standard Compliance

•3.5.2. Hardware Limitation

•…

– 3.6. Attributes (quality)•3.6.1 Reliability

•…

– 3.7. Other Requirements

• 4. Appendixes

46

SRS structure (3)

• 3.2. Class/Object

– 3.2.1. Class/Object 1• 3.2.1.1. Attributes

– 3.2.1.1.1 Attribute 1.1

– …

• 3.2.1.2 Functions (methods)

– 3.2.1.2.1 Functional requirement

– …

• 3.2.1.3. Messages (received or sent)

– 3.2.2. Class/Object 2

• …

47

UML

• general concepts

48

UML introduction

• Method convergence history

• Main models within UML:

Use Case Diagram

Class Diagram

Sequence Diagram

Collaboration Diagram

Activity Diagram

State Diagram

Component Diagram

Deployment Diagram

49

Unified Modeling Language

• Notation/standard for:• Expressing software requirements

• Expressing software architecture

• Expressing the structure and behavior of the software

– Current version, maintained by OMG (Object Management Group): 2.4.1 (August 2011) http://www.omg.org/spec/UML/

50

Unified Modelling Language

• UML is a graphic notation system (with clear syntax and semantics ) for modeling OO software applications

• UML is not a process, or a proprietary notation: it is an OMG standard (Object Management Group), defined using a metamodel

• It includes: – Views (show various faces of the system: user, operational, structural,

etc., also in relation with the development process)

– Diagrams (graphs that describe the contents of a view)

– Modeling Elements (constructs used in the diagrams)

51

Metamodel ?

52

Convergence of methods– 1980s, first OO methodologies

– 1989-1994 more than 50 languages for modeling OO applications are presented

– 1994 Grady Booch and James Rumbaugh begin their unification work : Booch + OMT

– 1995 : Unified Method 0.8, in the same year, IvarJacobson joins the group bringing his OOSE: the unification of approaches has started

– 1996 UML version 0.9 and 0.91 are released and many other partners join to support UML

– 1997 : UML 1.0 and OMG adopts it as standard ...

– June 99--2015: 1.1-1.2-1.3-1.4-....2.5 beta 2 ....

53

UML evolution • 1995 UML published by Rational

• 1997 UML 1.1: OMG standard

• 1999 UML 1.3: OMG

• 2001 UML 1.4: OMG

• 2003 UML 1.5: OMG

• 2004 Standard ISO/IEC 19501,

• 2007 UML 2.1.2: OMG

• 2010 UML 2.3

• 2011 UML 2.4.1

• 2011-2015 resting / minor details

– Superstructure: It defines the user level constructs required for UML

– UML Infrastructure: The infrastructure defines base classes that form the foundation not only for the UML superstructure, but also for MOF (Meta Object Facility) . It defines the foundational language constructs required for UML

– UML Object Constraint Language (OCL): This allows setting of pre- and post-conditions, invariants, and other conditions

– UML Diagram Interchange: This specification extends the UML metamodel with a supplementary package for graph-oriented information, allowing models to be exchanged or stored/retrieved and then displayed as they were originally.

54

UML evolution

Booch

Unified Method 0.8

UML 1.1

OMT

(Rumbaugh)OOSE/Objectory

(Jacobson)

UML 0.9

OOPSLA ´95

WWW - June ´96

Beta version OOPSLA ´96

OMG, gennaio ´97

Basic document

Three books (from the 3

Amigos):

-- User Guide

-- Reference Manual

-- Process Book

Only on Web

Other methods

Public

feedback

UML 1.5

OMG, 2001

IBM compra Rational, 2002

UML 2.5OMG 2007-2015

Standard ISO/IEC 19501

UML 1.4

55

Some UML partners• Digital Equipment. http://www.dec.com

• Hewlett-Packard http://www.hp.com

• i-Logix http://www.ilogix.com

• ICON Computing http://www.iconcomp.com

• MCI Systemhouse http://www.systemhouse.mci.com.

• Microsoft http://www.microsoft.com

• Oracle http://www.oracle.com

• Rational Software http://www.rational.com/uml

• Texas Instruments http://www.ti.com/software http:// www.ti.com/software/cbd.htm

• Unisys http://www.unisys.com

56

Some software tools that use UML

57

UML ?

• Can describe

– The use of the software

– How it works

– How to build it

– The agreement (contract) between customer and developer

58

13 Canonical diagrams

(Superstructure)

59

http://www.agilemodeling.com/essays/umlDiagrams.htm

Superstructure

60

Main UML diagrams

• Use Case Diagram

– It represents relationships among use cases and actors

– A system use case describes a system that automates abusiness use case or process. It is normally described at thesystem functionality level (for example, "create voucher") andspecifies the function or the service that the system providesfor the actor. The system use case details what the system willdo in response to an actor's actions. For this reason it isrecommended that system use case specification begin with averb (e.g., create voucher, select payments, exclude payment,cancel voucher). An actor can be a human user or anothersystem/subsystem interacting with the system being defined.

Actor 1 use caseActor 2

61

Use cases• An Use Case is a system view showing his behavior as it will appear to

users

• Partition functionalities in transactions ('use cases ') meaningful to users (' actors ').

• Consists of typical scenarios-interactions between a user and a computer system

• Properties: – Shows functions visible to the user

– Achieves objectives specific to the user

– It does not represent the order or the number of times a function is executed

• It is built talking with the user

• It is used to construct structural models, operational, and also to prepare test cases

62

An example• Phone selling system

63

Main UML diagrams

• Design model: Class Diagram (Static Structure Diagram)

– The diagram that shows the static elements of a model along with their properties and relationships among them i

– It is used by the developers

• It starts the description of how the system will be built

64

Example

• Shows which sw components are used and how relate to each other

Check

Number: StringDate : Date

Status : CheckStatus

ContoCorrente

Count# : String

Balance : Double

CheckBlock()

SetAuthorization()

Cash

Material object

Import : Double

Object

Divisa : Currency

On

65

Main UML diagrams• Design model: Behavioural Diagrams (Interaction Diagrams)

– Sequence Diagram

• The diagram that represents the interactions between objects by arranging them in sequence. In particular it shows the objects participating in the interaction and sequence of the messages exchanged.

– Collaboration Diagram

• The diagram that shows interactions organized around system objects and links between these objects.

66

Sequence diagram

It shows the

object interaction

temporal

sequence

67

time

Control

Object's life

Collaboration diagram

Shows the

interactions

among

objects

and their

visibility

68

Main UML diagrams

• Design model: Behavioral Diagrams

– State Diagram

• It described, in a detailed way, an object behaviour, through a FSA

– Activity Diagram

• It describes parallel processes

69

An object status

• A State transition diagram shows:

– the life cycle of an object of a class

– the events that cause a transition from one state to another one

– the actions resulting from a change of state

• these diagrams are created only for objects with significant dynamic behavior

70

Main UML diagrams • Example: A University Course

InitializationOpen

entry: Register student

exit: Increment count

Closed

Canceled

do: Initialize course

do: Finalize course

do: Notify registered students

Add Student / Set count = 0

Add student [ count < 10 ]

[ count = 10 ]

Cancel

Cancel

Cancel

71

Main UML diagrams

• Implementation Model

– Component Diagram• It represents the system software modules (components) and

their dependencies

• A component can be:

– Source code

– RunTime library

– Executable code

– Deployment Diagram• It describes the run-time component locations and the

computing network

72

Course Courses

Student Professor

Component diagram

Course.dll

Person.dll

Secretery.exeContability.exe

stereotypes

<<executable>>

<< library>>

<< table>>

<< file>>

<< document>> 73

Components

• UML component icon:

• A software component is "a non-trivial software module: a package or subsystem that has a precise function and well delineated, and can be integrated into a well defined architecture "

• key concepts in this definition: – non-trivial function

– well outlined

– precise function

Payment

System

74

The phisical system

• The deployment diagram shows the run time configuration of sw components and elements of software processes that live in them

• The deployment diagram shows the distribution of the components within the enterprise

75

Deployment diagram

76

Deployment diagram with components

77