Requirements Analysis

Based on K. E Wiegers Software Requirements, Chap 5, 14D. Leffingwell & D. Widrig, Managing Software Requirements A use case approach, Chap 5

Requirements Analysis

    The process of classifying requirements information into various categories, evaluating requirements for desirable qualities, representing requirements in different forms, deriving detailed requirements from high­level requirements, negotiating priorities, and so on. [K. Wiegers]

Requirements Analysis● Objectives of analysis

– detect and resolve conflicts between requirements– discover the bounds of the software and how it must interact 

with its environment– elaborate system requirements to derive software requirements 

such that managers can construct realistic project estimates and developers can design and implement and test

Requirements Analysis● Takes elicitation notes as input● However analysis and elicitation feed each other

Elicitation

Analysis

Elicitation notes

Prompt for questions and points to ponder

Requirements specification

Requirements Analysis● Includes:

● Problem analysis● Development of Product Vision and Project Scope

● Requirements Classification● Organize requirements in coherent clusters● Allocate requirements to subsystems

● Conflict resolution● Reconciling several stakeholders views

● Requirements Prioritizing● Finding the most important requirements● Determine which features will be included in each release 

● Analysis goes in parallel with modeling (specification)● Modeling help in most of the analysis activities

Requirements Classification● Organization of related functional requirements in logical clusters● Possible organizational options

– features– use cases– mode of operation– by user class– by subsystem– ...

● Makes it easy to understand the product intended capabilities● It is more effective to manage and prioritize large chunks rather 

than single requirements

Conflicts Resolution

● Possible conflicts among Stakeholders – between supplier and customers about costs, benefits, 

risks– power struggle within customer organization,– conflicts with other projects about resources– conflicting goals, features, requirements– ...

Conflicts Resolution

● Conflict resolution involves negotiation– group discussion– have each party explain what they believe the other 

party wants and why– analyze each party goals, find solutions that don't 

conflict but support everybody goals

Requirements Prioritizing

● Why Prioritize Requirements ?– Too many requirements

● requirements from different sources– Limited resources (budget, time)– Developers don't know the value of the requirements– Customers don't know the complexity of implementing 

requirements

Requirements Prioritizing

● Prioritizing is needed, but:● how to know which requirements are more 

important ?● what criteria to use for prioritizing ?● when each requirement would be considered 

(iteration)

Requirements PrioritizingDifficulties

● Different stakeholders may have different  priorities           

● Organizations lack systematic data, metrics    techniques to        help the prioritizing process

– Prioritizing often carried out informally     

● Wrong idea that everything in a specification can be done

– however, in practice, some requirements are left­out when deadline can't be meet

Requirements Prioritizing● Deciding which requirements really matter       

● Or those that need to be implemented in              the current release   

● Also referred to as requirements         triage● Needed because there will almost always be the need f                 

or trade offs:  ‐

– Required functionality vs. time and resources         

Requirements Prioritizing Process● Must be simple and fast, for industry  adoption             

● Yield accurate and trustworthy results       

● Should consider issues of:     

– Importance of requirement to the user  (maximize)           

– Cost of implementation (minimize)     

– Time to delivery (minimize)‐ ‐  

Importance of Prioritizing

Prioritizing requirements help:   ● Making acceptable tradeoffs among goals of cost and 

time­to­market ● Project planning in allocating resources based        

on requirements importance to the project as a whole  

Requirements Analysis● Approaches

– Structured analysis (1970) – Object­oriented analysis (1990)– Problem Frames (1995)

Structured Analysis● Data­oriented approach 

– Based on analysis of flow of information● Models

– Dataflow diagram (DFD) ­ flow of information in system– Entity Relation Diagrams (ERD) – describe data – Data dictionary  ­ define all data elements– State Diagram – describe state based behavior 

Structured Analysis● Mainly used for information systems

– Extensions have been developed for real­time systems● Analysis consists on modeling current system (can be a 

manual system)– New system derived from understanding current system– What if there is no current system ?

Structured Analysis● Approaches

– Structured Analysis and Design Technique (SADT) ­ Doug Ross

– Structured Analysis and System Specification(SASS) – Yourdon and DeMarco

– Structured System Analysis (SSA) – Gane and Sarsan– Structured Requirements Definition (SRD) – Ken Orr– Structured Analysis / Real Time (SA/RT) ­ Ward and Mellor– Modern Structured Analysis ­ Yourdon

Structured Analysis

SASS Steps1. Analysis of  current physical system

• DFD to show current data flow through the organisation• Shows physical organisational units or individuals

2. Derivation of logical model• Logical functions replace physical units

3. Derivation of proposed logical model• DFD modified to reflect new proposed system

4. Implementation of new physical system• Several alternatives considered

Structured Analysis

1. Produce statement of purpose (objective of new system)2. Develop essential environmental model (of new system)

– Context diagram (DFD­0)– Data dictionary– Event list

3. Develop essential behavioural model (of new system)– Data flow diagram(s) (modelling the “functionality” of the new system) 

(DFD­1, DFD­2, ...)– Mini­specs (for the transformation processes)– State transition diagrams (for any control processes)– Entity relationship diagram– Supporting text (?)

(Note, these documents constitute the analysis and the specification documentation)

Modeling of new system

Structured Analysis

Dataflow notation

T r a n s f o r m

T e r m in a to r

D a ta d ic tio n a r y

I n p u t O u tp u t

Structured Analysis – example (Bray 2004)

Statement of purposeA software­based system is required to control lifts (elevators) manufactured by Skyhi Lifts. Lifts are constrained to shafts (one lift per shaft) and moved up and down by winding motors (one winding motor per lift).Users can call lifts by pressing buttons either inside the lift (a lift button) or outside the lift (a floor button) and there is an indicator system to show the users the current position of the lift.

Structured Analysis – example (Bray 2004) Context diagram (DFD­0)

lift

buttonsignal

sensorsignal

motorsignal

doorsignal

floor

button

signal

liftcontrolsystem

windingmotor

indicator

sensor

liftbutton

doorfloorbutton

indicatorsignal

Structured Analysis – example (Bray 2004) Data Flow Diagram (DFD­1) 

liftbutton

floorbutton

monitorrequests

requestqueue

controlindicators

indicatorsensor

doorcontroller

windingmotor

monitorlifts

despatchlifts

liftdata

controllifts

sensorsignals

liftdetail

liftposition

liftdetail

liftstatuslift

detail

liftstatus

request

request

liftbuttonpress

request

requestcancel

doorcommand

motorcommand

floorbuttonpress

indicatorcommand

Structured Analysis – example (Bray 2004)

Entity Relationship Diagram

liftshaft

building indicator

set

door

floor

lift

button

floor

button

sensor

indicator

Structured Analysis – example (Bray 2004)

Mini – specsmonitor buttonsloop

if lift_button press receivedif relevant lift/floor not requested

record requestif floor_button press received

if relevant floor/direction not requestedrecord request

Structured Analysis

Problems• Over­emphasis on modelling (there’s more to analysis !) • Models the pre­existing solution system (rather than the 

Domain)• Essentially process­based models (encourage structural model 

of the pre­existing system)• Difficulty in integrating DFD and ERD models• No explicit mention of requirements! (an implicit assumption 

that the pre­existing system already meets the requirements ­ apart from not being computer­based !) (SSADM eventually added the Problem/Requirements List ­ PRL)

• This assumption is carried through into design (the new system inherits its basic structure from the  pre­existing system)

• Lack of a behavioural (functional) specification

Object­Oriented Analysis● Based on modeling a system as objects relations 

between objects and interaction of objects.● Concepts

– Object: major actors, agents, and servers in the problem space of the system

– Class: abstraction of objects (type)– Encapsulation: packaging of data and operations, 

detail of operations are hidden– Inheritance: define classes inclusion

Object­Oriented Analysis● Main steps

" Identify core classes within problem domain" Model relationships between classes (class diagram)" Define the attributes associated with each class" Determine relevant operations for each class" Define the messages that may be passed between 

objects (interaction diagram, state diagram)

Object modeling ­ Library example (Sommerville & Kontoya)

● A library system is intended to provide its users with the ability to automate the process of:" Acquiring library items" Cataloguing library items" Browsing library items" Loaning library items

● Library items comprise published and recorded material● The system will be administered by a member of the library staff● Users must register with the system administrator before they can 

borrow library items

Library example (contd.)● Library users are drawn from three primary groups:

 Students, Members of staff and External users● All library users have as part of their registration: 

Name, Library number, Address, Account● In  addition  the  following  information  also  required 

for registration:Students ­ Degree programme and admission number. Staff ­ Staff number External users ­  Employer details

Step 1 ­ Initial classes identified

L ib r a r y u s e r L ib r a r y i t e m L ib r a r y s t a f f A c c o u n t

Step 2 ­ Relationships between classes● We can identify the following relationships from the 

partial requirements:(i)  A library user borrows a library item(ii) A library item is recorded or published(iii) The system administrator registers the library user(iv) Library users are students, staff and external users(v)  The system administrator catalogues the library items(vi) The library assistant issues the library items

Step 2 ­ Basic object model showing attributes and relationships

Library user

Library staff

Library item

NameAddressLibrary id

borrows

TitleClassmarkCall Number

Account

registers

browses

receives issues

catalogues

staff id

loaned itemdue date

1 1,N

1,NN

1

N

1

N N

1

1

N

Step 2 ­ Inheritance for Library user 

Library user

NameAddressLibrary id

Degree programmeAdmission number

Student

Staff number

Staff

Employer nameEmployer address

External

Account

loaned item iddue date

Step 2 ­ Inheritance for library itemLibrary item

TitleClassmark

Published item

FormatLength of playContents

Recorded item

Book Journal

PublisherY ear

A uthorISBN number

V olumeIssue

Step 3 ­ Identifying the attributes● Attributes can be revealed by the analysis of the system requirements●  For example, it is a requirement that all library users must be 

registered before they can use the library" This means that we need to keep registration data about 

library users" Library users may also be provided with an account to 

keep track of the items loaned to them● Library item has the attributes; title, description and classmark● The library user class has the attributes; name, address and library id

Step 4 ­ Object operations● This step is intended to describe operations to be 

performed on the objects● Certain operations are implicit from the object 

structure" These include operations for accessing and modifying 

the attribute values. These operations are assumed and we need not show them explicitly in the model

● One way of identifying operations is by modelling the messages that may be passed between the objects 

Step 4 ­ Messages between objects

L ib r a r y u s e r L ib r a r y ite m

L ib r a r y s ta f f

1 . is s u e2 . r e tu r n3 . b r o w s e

1 . a c q u ir e2 . c a ta lo g u e3 . d is p o s e

1 . r e g is te r2 . q u e r y

Step 4 ­ Operations for library user and library staff

Library user

N ameA ddressLibrary id

D egree programmeA dmission number

S tudent

S taff number

S taff

Employer nameEmployer address

External

registerquery

A ccount

loaned item iddue date

compute fine

Step 4 ­ Operations for library itemLibrary item

TitleClassmark

Published item

FormatLength of playContents

Recorded item

Book Journal

PublisherYear

AuthorISBN number

VolumeIssue

acquireissuereturndisposecatalogue

Step 5 ­ Define the messages that may be passed between objects

Library User (LU) System Library staff

Requests library item (1) Scans in LU registration (2)

accepts registration (3)

rejects registration (3)

verifies item loan to LU (4)

loans item (5)

denies loan (5)

Problems with Object-Oriented Analysis

● Not really analysis– Most OOA approaches actually address High­level 

design– Assume a pre­existing requirements document

● Use Cases analysis used to supplement OOA● Scaterring and Tangling effects

Problem Domain Analysis (PDOA)

● Approach developed by Michael Jackson (1995)● The focus of the approach consists in  representing and 

analyzing  a problem using a context diagram– represented as a problem diagram

● There are classes of problems with a “standard solution”– similar idea as for design patterns– each class is described by a generic problem diagram 

called a problem frame

PDOA – The problem and Solution

The worldoutside

the computer

The Computerand

its Software

The Problemis here

The Solutionis here

Connectionsbetween theworld and theComputer

Where?Where? How? What?How? What?

PDOA – The Problem ● Developing software is 

building a machine … MachineMachine

One problem, one machine The machine is a general­purpose computer…      … specialized by software The machine may be distributed One computer may support many machines Problem decomposition gives many sub problems…     … and so many machines

PDOA – The Problem ● Developing software is 

building a machine … ● … to solve a problem in a 

given domain ( a part of the world) …

MachineMachine

▲ The machine and the problem domain interact … at an interface of shared phenomena (events, states, etc.)

▲ Usually we need to structure the problem domain… and to structure the problem into subproblems

▲ The machine in one subproblem may be a part of the problem domain in another subproblem

MachineMachine DomainDomain

PDOA – The Problem ● Developing software is building a 

machine … 

● … to solve a problem in a given domain ( a part of the world) …

● … to meet a customer’s needs(the requirement)

MachineMachine

▲ The customer’s requirement is for some effect (or property or behavior) in the problem domain

▲           means that the requirement adds a constraint to the domain’s intrinsic properties or behavior

MachineMachine DomainDomain

MachineMachine DomainDomain RequirementRequirement

Problem TypesMichael Jackson suggests a classification of problems as (there may 

be more)● Control :­

– Required behaviour– Commanded behaviour

● Workpiece● Information

– Continuous display– Requested reports

● Transformation● Connection

Problem Types● The classification helps with the development process by 

– providing specific guidance for each type of problem– decomposing complex problems in a logical way

● Problem Frame model is used to  characterise the problem– Model the problem context

● model the relationships between domains  

Problem Frame

“A problem frame is a kind of pattern. It defines an intuitively identifiable problem in terms of its context and the characteristics of its domains, interfaces and requirements. Domain and interface characteristics are based on a classification of phenomena.” (M.A. Jackson)– Correspond to problem types

● Control ● Workpiece● Information● Transformation● Connection

Problem Frames ­ ExampleTransformation Frame

inputdata

outputdata

transformationsystem

mapping rules(requirements)

Transforms given input data to produce new output data according to some pre­defined rules.  

Problem Frames ­ ExampleTransformation Frame

Problem Frame for a program that produces a credit card statement, given a file of transactions

transactionfile

statementfile

credit card statement program

statementproduction rules

Problem Frames ­ Notation● Domains are shown thus :

● The SS (machine) is a “special” domainand has a special symbol:

● Domains (apart from the SS) that can be designedby the developer (realised domains):

● Relationships (interactions) betweendomains:

Domain name

Solutionsystem name

Domain name

connection not explicit: shared phenomena

Problem Frames ­ Notation● The requirements are represented thus  :

● Where the requirements reference (refer to) a domain this is shown as:

● Where the requirements constrain(impose upon) a domain this is shown as:

Requirements

Control FrameRequired behaviour: ­ controls some part of reality 

according to defined rules

ControlControlmachinemachine

ControlledControlleddomaindomain

Required Required behaviorbehavior

ProgramProgramsequencersequencer WashingWashing

machinemachineWashingWashing

rulesrules

Example:Example:

Control FrameCommanded behaviour: ­ controls some part of reality according to 

operators commands

controlleddomain

controlsystem

requiredbehaviour

source ofcommands

(user)

Examples: engine­management system, process control, ...

Information Frame

real world reports

informationsystem

information function(requirements)

requests(user)

Continuous (automatic) reporting: automatically provides information about some part of reality

Requested (upon demand) reporting: provides information about some part of reality upon request

Information Frame● For an information system, it is the real world’s data that is 

significant● The IS will often contain a model of the real world data – but note 

that there are two models – they may vary in structure and value!

requests

informationfunction

reports

update mechanism(connection system)

real world

informationsystem

Workpiece FrameSystem must perform directed operations upon objects that exist only within the system.

Provides for a user to create and edit documents

source ofcommands

(user)

workpiece(document)

workpiecesystem

operation effects(requirements)Examples:

● CAD tools

● CASE tools

● office utilities (word­processors, spreadsheets)

● desk­top publishing, web­site production tools

●...

Workpiece Frame ­Example

ProfessorStudent

GradeBookGrade Editor

Gradingguidelines

inclusion

Transformation Frame

inputdata

outputdata

transformationsystem

mapping rules(requirements)

Transforms given input data to produce new output data according to some pre­defined rules.  

Connection Frame

source destinationconnectionsystem

requirements

• This, common version resembles the transformation frame but there is a crucial difference:  the transformation system generates new data from old, the connection system just moves (logical) data from A to B

• The requirements will concern the acceptable delays and distortions that the system can introduce

Multi Frame Problems– Most real­life problem domains cannot be fitted with 

a single, simple problem frame– The problem must be partitioned and (overlapping) 

frames fitted to the recognisable parts

(This provides a very useful strategy for handling complex problems – divide and conquer!)

Multi Frame Problems

behaviourrules

sensors

lifts

motors

doorcontrollers

buttons

liftcontroller(control part)

usersindicators

liftcontroller(information system part)

information function

Example ­ lift system ­ control + information

PDOA ­ method1. Collect basic information and develop problem frame(s) 

in order to establish the type of the PD2. Guided by the PF type(s), collect further detail and 

develop a description of the relevant characteristics of the PD (This description may well incorporate conventional models such as Context diagrams, ERDs etc.)

3. In conjunction with the foregoing, collect and document the requirements for the new system