software engineering olli alm lecture 2: requirements, modelling & representation

Software engineering

Olli Alm

Lecture 2: requirements, modelling & representation

Phases of a software engineering project:requirements definition

(Pressman: ch. 7: Requirements engineering)(Sommerville: ch. 6-8 in Requirements) The idea: we have a customer with needs

well defined / untechnical / unclear / something? A customer in the broad sense: a company, a friend, a

financier or yourself? In this phase, we try to formalize and specify the customer needs (in order to implement a

program)

Requi

rem

ents

defini

tion

Impl

emen

tation

Mai

nten

ance

Test

ing

Des

ign


The result (should be) (a bunch of) specification documents

Description for customer (external, informal+formal) Description for the designers (internal, informal+formal)

agreement between customer and supplier (the contract!) requirements functional / non-functional cost + (initial) schedule representation in good level of abstraction (not too

specific, not too broad)

But…

Requi

rem

ents

defini

tion

Impl

emen

tation

Mai

nten

ance

Test

ing

Des

ign


Two representation levels: For the customer and team user requirements For the team system requirements

Requi

rem

ents

defini

tion

Impl

emen

tation

Mai

nten

ance

Test

ing

Des

ign


An example (Sommerville):

1. The software must provide a means of representing and1. accessing external files created by other tools.

1.1 The user should be provided with facilities to define the type of external files1.2 .1.2 Each external file type may have an associated tool which maybe applied to the file1.2 1.3 Each external file type may be represented as a specific icon on the user’s display1.21.4 Facilities should be provided for the icon representing an external file type to be defined by the user

1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the type of the external file to the file represented by the selected icon

1.21.2

User requirement definition

System requirements specification


An example (Sommerville):

1. The software must provide a means of representing and1. accessing external files created by other tools.

1.1 The user should be provided with facilities to define the type of external files1.2 .1.2 Each external file type may have an associated tool which maybe applied to the file1.2 1.3 Each external file type may be represented as a specific icon on the user’s display1.21.4 Facilities should be provided for the icon representing an external file type to be defined by the user

1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the type of the external file to the file represented by the selected icon

1.21.2

User requirement definition

System requirements specification

What user wants to do

How the systemmakes itpossible

Phases of a software engineering project:requirements definition: user requirements

User requirement guidelines (Sommerville):1. Use standard format / template2. Use consistent language, classify requirements (!)

(mandatory [’system shall…’, desirable [’system should’] etc.)

3. (- Highlight the keyparts of the text -)4. Avoid computer jargon!5. In addition to text, use diagrams & pictures

Phases of a software engineering project:requirements definition: system requirements

System requirements (Sommerville): Describe external behaviour of the system, not it’s

design or implementation (if possible) In some cases, selected architecture affect on

requirements design is included to requirements Extend the use cases


Distinction in types of requirements:functional requirements

Services that system should provide How the system should react particular inputs How the system should behave in particular situations

non-functional requirementsreliability, privacy, safety, efficiency, portability, usability

n-f requirements may affect also to the process, not only to the product (e.g. process quality(?) for safety)

Requi

rem

ents

defini

tion

Impl

emen

tation

Mai

nten

ance

Test

ing

Des

ign


Examples of non-functional requirements (Sommerville):”the user interface should be implement as simple HTML without frames or Java applet” (product requirement)

”the system development process and documents shall conform to the process and deliverables defined in XYZ…” (organizational requirement)

”The system shall not disclose any personal information…” (external requirement)

Requi

rem

ents

defini

tion

Impl

emen

tation

Mai

nten

ance

Test

ing

Des

ign


Requi

rem

ents

defini

tion

Impl

emen

tation

Mai

nten

ance

Test

ing

Des

ign

Property Measure

Speed Processed transactions/secondUser/Event response timeScreen refresh time

Size M BytesNumber of ROM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability

Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure

Portability Percentage of target dependent statementsNumber of target systems

Metrics for non-functionalrequirements (Sommerville)

Representing user interaction in high level

Forms of representation: Natural language (NL), structured templates (ST), diagrams (D)

In requirements analysis:1. Scenario descriptions2. Use cases3. Sequence diagrams

Representing user interaction in high level:1. scenarios

Scenario description: real-life example of the use case with the ”default progress / phases”

Case example, opening the door: ”The teacher is on the hallway. She wants to enter the class room. She takes the keys from her pocket and opens the door by turning the key in the lock and then pulling the door.”

Informative description to represent the system usage scenarios in high level

Description in natural language (previous example) or with controlled templates.

Representing user interaction in high level:1. scenarios (template)

Scenario description: real-life example of the use case with the ”default progress / phases”

Template: a form-like description, e.g.:Initial assumption: the situationNormal: usual flow of the caseWhat can go wrong: unexpected behaviorOther activities: what is happening simultaneouslySystem state or completion: where we are after this?


Initial assumption: The user has logged on to the LIBSYS system and has located the journal containing the copy of the article.

Normal: The user selects the article to be copied. He or she is then prompted by the system to either provide subscriber information for the journal or to indicate how they will pay for the article. Alternative payment methods are by credit card or by quoting an organisational account number.

The user is then asked to fill in a copyright form that maintains details of the transaction and they then submit this to the LIBSYS system.

The copyright form is checked and, if OK, the PDF version of the article is downloaded to the LIBSYS working area on the user’s computer and the user is informed that it is available. The user is asked to select a printer and a copy of the article is printed. If the article has been flagged as ‘print-only’ it is deleted from the user’s system once the user has confirmed that printing is complete.

An example [Sommerville, ch.7]


An example [Sommerville, ch.7]

What can go wrong: The user may fail to fill in the copyright form correctly. In this case, the form shouldbe re-presented to the user for correction. If the resubmitted form is s till incorrect then the userÕs requestfor the article is rejected.

The payment may be rejected by the system. The userÕs request for the article is rejected.

The article download may fail. Retry until successful or the user terminates the session.

It may not be possible to print the article. If the article is not flagged as Ōprint-onlyÕ then it is held in theLIBSYS workspace. Otherwise, the article is deleted and the userÕs account credited with the cost of thearticle.

Other activities: Simultaneous downloads of other articles.

System state on completion: User is logged on. The downloaded article has been deleted from LIBSYSworkspace if it has been flagged as print-only.

Representing user interaction in high level:2. use cases

How the user interacts with the system Actors involved, the type of the interaction Stick figures, named ellipses + arrow in between

Article printing© Sommerville, 2004

Representing user interaction in high level:2. use cases

How the user interacts with the system Actors involved, the type of the interaction Stick figures, named ellipses + arrow in between Roles of the users / user groups!

© Sommerville, 2004

Article printing

Article search

User administration

Supplier Catalogue services

LibraryUser

LibraryStaff

Representing user interaction in high level:3. scenario diagrams

Scenario diagrams extend use cases to describe also the inner behavior of the system Interaction between components Timely dependent description

In addition, sequence diagrams are also used to describe design and implementation of the system

how components interacts with each other



User

item:Article

copyrightForm:Form

request

complete

myWorkspace:Workspace

myPrinter:Printer

request

return

copyright OK

deliver

article OK

print send

confirminform

delete



Scenario diagram is also known by name sequence diagram

in general, sequence diagrams indicate interaction between objects or functional units to fulfill a certain (”bigger”) task.

Timely dependence: sequence diagram states explicitly the order of the interaction

But not (usually) the processing time of a component Relative processing time can be described by the vertical length of the activity



User

item:Article

copyrightForm:Form

request

complete

myWorkspace:Workspace

myPrinter:Printer

request

return

copyright OK

deliver

article OK

print send

confirminform

delete

activityof the object

time


The output of this phase is software requirements document

IEEE standard IEEE/ANSI 830-1998 Should state WHAT the system should do, not HOW it

does it (how design document) [Sommerville]

Requi

rem

ents

defini

tion

Impl

emen

tation

Mai

nten

ance

Test

ing

Des

ign

Software requirements document

Adapted from Sommerville, Software engineering 7, p.139

Document structure:1) Preface2) Introduction3) Glossary4) User requirements definition5) System architecture6) System requirements specification7) System models8) System evolution9) Appendices10) Index



Document structure:1) Preface-expected readership-version history (of this document)-what is new in this version-summary of changes



Document structure:2) Introduction-need for the system (=why?)-short description of functions-business / strategic objectives of the customer



Document structure:3) Glossary -technical terms explained



Document structure:4) User requirements definition-user requirements-non-functional system requirements-natural language, diagrams, controlled language,

templates…



Document structure:5) System architecture-high-level overview of the system-main modules and their functions represented



Document structure:6) System requirements specification-functional requirements in detail-non-functional requirements in detail



Document structure:7) System models-relations between system modules-object models? Flow models?



Document structure:8) System evolution-explicit notion how the system will adapt for

changing user needshardware evolution



Document structure:9) Appendices-technical, detailed documentation



Document structure:10) Index-for finding descriptions


Document structure (revisited), essential parts bolded:1) Preface2) Introduction3) Glossary4) User requirements definition5) System architecture6) System requirements specification7) System models8) System evolution9) Appendices10) Index

Software requirements: case study

Define requirements for door access system Give a general description of the system Define functional requirements Define non-functional requirements Can you specify different groups of users? Define use cases Give examples of basic scenarios

software engineering olli alm lecture 2: requirements, modelling & representation

Documents