Upload
others
View
37
Download
0
Embed Size (px)
Citation preview
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 highlevel 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 leftout 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
timetomarket ● Project planning in allocating resources based
on requirements importance to the project as a whole
Requirements Analysis● Approaches
– Structured analysis (1970) – Objectoriented analysis (1990)– Problem Frames (1995)
Structured Analysis● Dataoriented 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 realtime 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 (DFD0)– Data dictionary– Event list
3. Develop essential behavioural model (of new system)– Data flow diagram(s) (modelling the “functionality” of the new system)
(DFD1, DFD2, ...)– Minispecs (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 softwarebased 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 (DFD0)
lift
buttonsignal
sensorsignal
motorsignal
doorsignal
floor
button
signal
liftcontrolsystem
windingmotor
indicator
sensor
liftbutton
doorfloorbutton
indicatorsignal
Structured Analysis – example (Bray 2004) Data Flow Diagram (DFD1)
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• Overemphasis on modelling (there’s more to analysis !) • Models the preexisting solution system (rather than the
Domain)• Essentially processbased models (encourage structural model
of the preexisting system)• Difficulty in integrating DFD and ERD models• No explicit mention of requirements! (an implicit assumption
that the preexisting system already meets the requirements apart from not being computerbased !) (SSADM eventually added the Problem/Requirements List PRL)
• This assumption is carried through into design (the new system inherits its basic structure from the preexisting system)
• Lack of a behavioural (functional) specification
ObjectOriented 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
ObjectOriented 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 Highlevel
design– Assume a preexisting 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 generalpurpose 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 predefined 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: enginemanagement 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 (wordprocessors, spreadsheets)
● desktop publishing, website 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 predefined 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 reallife 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