Requirements Analysis Models

1
Requirements Analysis Models
2
The Unified Modeling Language

• Devised by the developers of widely used
  object-oriented analysis and design methods
• Has become an effective standard for
  object-oriented modelling
• Notation

• Use Case Diagrams
• Class Diagrams
• Object Interaction Diagrams
• Collaboration Diagrams
• Message Sequence Diagrams

• Activity Diagrams
• State Diagrams
• Component Diagrams
• Deployment Diagrams
• etc.
• Stereotypes

3
Scenarios

• Scenarios are descriptions of how a system is
  used in practice
• They are helpful in requirements elicitation as
  people can relate to these more readily than
  abstract statement of what they require from a
  system
• Scenarios are particularly useful for adding
  detail to an outline requirements description

4
Use cases

• Use-cases are a scenario based technique in the
  UML which identify the actors in an interaction
  and which describe the interaction itself
• A set of use cases should describe all possible
  interactions with the system
• Sequence diagrams may be used to add detail to
  use-cases by showing the sequence of event
  processing in the system

5
Lending use-case
6
Library use-cases
7
Catalogue management
8
Object models

• Object models describe the system in terms of
  object classes
• Natural ways of reflecting the real-world
  entities manipulated by the system
• An object class is an abstraction over a set of
  objects with common attributes and the services
  (operations) provided by each object
• Various object models may be produced
• Inheritance models
• Aggregation models
• Interaction models
• Object class identification is recognised as a
  difficult process requiring a deep understanding
  of the application domain

9
Object class in UML notation
Class name
Attributes (state)
Operations (services)

• May hide compartments in diagram
• May not show all attributes and/or operations in
  a compartment

10
Structure interacting objects
client
server
Note this is an object collaboration diagram,
NOT a class diagram (the arrows mean different
things in each)
11
Object-oriented Design (OOD)

• Designing systems using interacting objects
• Think in terms of things instead of operations
  or functions
• Instead of programming a set of functions that
  exchange data through parameters and through
  shared memory (global variables, files,
  databases)
• Program with interacting objects that maintain
  their own local state and define operations on
  that state
• client objects request that server objects
  implement their operations

12
Object communication

• Conceptually, objects communicate by message
  passing.
• Messages
• The name of the service requested by the calling
  object.
• Copies of the information required to execute the
  service
• Name of a holder for the result of the service.
• In practice, messages are often implemented by
  procedure calls
• Name procedure name.
• Information parameter list.
• Result return value of procedure.

13
Message examples
// Operation on a buffer object that returns //
the next value in the buffer v
circularBuffer.Get() // Operation on a thermostat
object that sets // the temperature to be
maintained thermostat.setTemp(20)
Note clients access object state through
operations
14
Class associations

• Associations very general relationship between
  class instances
• e.g. class has an attribute whose type is another
  class
• e.g. class instances know about (are a client of)
  instances of other class in relation
• Specific associations
• aggregation, specialization, dependency, role,
  stereotype, interface implementation, etc.

• Navigating associations
• Employee3.is-member-of() returns a department
• Department4.has-members() returns collection of
  employees

15
Inheritance

• Objects are members of classes which define
  attribute types and operations
• Classes may be arranged in a class hierarchy
  where one class is derived from an existing
  class (super-class)
• A sub-class inherits the attributes and
  operations from its super class and may add new
  methods or attributes of its own

16
A class or type hierarchy
Generalization
Specialization
17
Requirements Activity

• Sources
• Ivar Jacobson, Grady Booch, James Rumbaugh, The
  Unified Software Development Process Addison
  Wesley, 1999, Chapter 6, 7 and some from 3
• Donald C. Gause and Gerald M. Weinberg, Exploring
  Requirements Quality Before Design, New York
  Dorset House, 1989
• Sample requirements documents

18
Requirements Elicitation and Management

• Problem analysis understand true business need
• Identify stakeholders
• Identify scope and its change
• Elicitation discover stakeholder requirements
• Elicitation techniques
• Scope management match scope to resources
• Change management accommodate change

• Interviews
• Questionnaires
• Requirements workshops
• Brainstorming and idea reduction
• Storyboarding

• Role playing
• Use cases
• System scenarios
• Prototyping
• Context-free questions

19
Capturing/discovering requirements

• Far harder than writing code
• Users know what they have, not what they need
• They will better understand what they need after
  they see it, which is often too late
• To go faster, I need a better buggy
• ? never envision a car
• User cannot envision the possibilities enabled by
  technology
• Developer is rarely the user
• Diversity of users
• Support the mission of the user, not just the
  user
• User needs and missions are constantly changing
• The new system will impact the users needs,
  resulting in new system needs (cycle)
• Complex systems are never fully understood
• understanding evolves as the system evolves
• Hard to understand the constraints of legacy
  systems and the system environment

20
Requirements Statements

• Accurate
• Complete
• Consistent
• Clear
• Brief
• Linked to related requirements
• Testable
• Traceable
• To source of requirement
• To design and code that implement requirement
• To test case that demonstrates (verifies) that
  the system meets the requirement

21
Requirements validation

• Concerned with demonstrating that the
  requirements define the system that the customer
  really wants
• Requirements error costs are high so validation
  is very important
• Fixing a requirements error after delivery may
  cost up to 100 times the cost of fixing an
  implementation error
• Prototyping is an important technique of
  requirements validation

22
Example Requirements Documents

• http//cs.ua.edu/600/Other20material/index.htm

23
Purpose of requirements activity

• Aim development toward the right system
• Other activities focus on building the system
  right
• Describe what the system should and should not do
• an agreement between customer (including user)
  and development organization
• in the language of the customer/user
• Tasks
• List candidate requirements
• Understand system context
• Capture functional requirements
• Capture non-functional requirements
• Validate requirements

24
Starting points
Vague
Overly Detailed
Detailed customer requirements document
Vision statement
System Requirements
Domain object model
Similar systems
Business model
25
List candidate requirements? Feature list

• Candidate features that could become requirements
• good ideas added to feature list
• features taken off list when they become formal
  requirements
• Planning values status, cost, priority, risk

26
Understand system context? Business or Domain
model

• Domain model
• Identify and name important concepts and entities
  in the system context
• Identify and name relations between domain
  objects
• Glossary (first cut object classes), possible
  classes
• Analysis and design tasks add
• processes/behaviors
• workers, their responsibilities and operations

27
Capture functional requirements? Use cases

• Capture requirements as use cases
• Use case a users way of using the system
• When an actor (user or external subsystem) uses
  the system, the system performs a use case
• All use cases all the things the system must do
• Capture user interfaces that support the use cases

28
Capture non-functional requirements?
Supplementary requirementsand use cases

• System properties
• environmental or implementation constraints
• e.g. must have remote access or must run on Linux
  or WinNT
• -ilities performance, reliability, security,
  maintainability, extensibility, usability, etc.
• Tie to use cases or domain concepts, where
  possible
• those that cannot be tied (they are general) are
  listed as supplementary requirements

29
Formal Specification

• Techniques for the unambiguous specification of
  software

30
Formal methods

• Formal specification is part of a more general
  collection of techniques that are known as
  formal methods
• These are all based on mathematical
  representation and analysis of software
• Formal methods include
• Formal specification
• Specification analysis and proof
• Transformational development
• Program verification

31
Use of formal methods

• Formal methods have limited practical
  applicability
• Their principal benefits are in reducing the
  number of errors in systems so their main area of
  applicability is critical systems
• In this area, the use of formal methods is most
  likely to be cost-effective

32
Formal specification techniques

• Algebraic approach
• The system is specified in terms of its
  operations and their relationships
• Model-based approach
• The system is specified in terms of a state model
  that is constructed using mathematical constructs
  such as sets and sequences. Operations are
  defined by modifications to the systems state

33
Formal specification languages
34
Use of formal specification

• Formal specification involves investing more
  effort in the early phases of software
  development
• This reduces requirements errors as it forces a
  detailed analysis of the requirements
• Incompleteness and inconsistencies can be
  discovered and resolved
• Hence, savings are made as the amount of rework
  due to requirements problems is reduced

35
Interface specification in critical systems

• Consider an air traffic control system where
  aircraft fly through managed sectors of airspace
• Each sector may include a number of aircraft but,
  for safety reasons, these must be separated
• In this example, a simple vertical separation of
  300m is proposed
• The system should warn the controller if aircraft
  are instructed to move so that the separation
  rule is breached

36
A sector object

• Critical operations on an object representing a
  controlled sector are
• Enter. Add an aircraft to the controlled airspace
• Leave. Remove an aircraft from the controlled
  airspace
• Move. Move an aircraft from one height to another
• Lookup. Given an aircraft identifier, return its
  current height

37
Primitive operations

• It is sometimes necessary to introduce additional
  operations to simplify the specification
• The other operations can then be defined using
  these more primitive operations
• Primitive operations
• Create. Bring an instance of a sector into
  existence
• Put. Add an aircraft without safety checks
• In-space. Determine if a given aircraft is in the
  sector
• Occupied. Given a height, determine if there is
  an aircraft within 300m of that height

38
Sector specification
39
Behavioral specification

• Algebraic specification can be cumbersome when
  the object operations are not independent of the
  object state
• Model-based specification exposes the system
  state and defines the operations in terms of
  changes to that state
• The Z notation is a mature technique for
  model-based specification. It combines formal and
  informal description and uses graphical
  highlighting when presenting specifications

40
Insulin pump schema
I
n
s
u
l
i
n
_
p
u
m
p
r
e
a
d
i
n
g
?



d
o
s
e
,

c
u
m
u
l
a
t
i
v
e
_
d
o
s
e


r
0
,

r
1
,

r
2


/
/

u
s
e
d

t
o

r
e
c
o
r
d

t
h
e

l
a
s
t

3

r
e
a
d
i
n
g
s

t
a
k
e
n
c
a
p
a
c
i
t
y


a
l
a
r
m
!



o
f
f
,

o
n

p
u
m
p
!


d
i
s
p
l
a
y
1
!
,

d
i
s
p
l
a
y
2
!


S
T
R
I
N
G
d
o
s
e



c
a
p
a
c
i
t
y

Ù

d
o
s
e



5

Ù

c
u
m
u
l
a
t
i
v
e
_
d
o
s
e



5
0
c
a
p
a
c
i
t
y



4
0


Þ


d
i
s
p
l
a
y
1
!



"

"
c
a
p
a
c
i
t
y



3
9

Ù

c
a
p
a
c
i
t
y



1
0

Þ


d
i
s
p
l
a
y
1
!



"
I
n
s
u
l
i
n

l
o
w
"
c
a
p
a
c
i
t
y



9

Þ


a
l
a
r
m
!



o
n

Ù

d
i
s
p
l
a
y
1
!



"
I
n
s
u
l
i
n

v
e
r
y

l
o
w
"
r
2



r
e
a
d
i
n
g
?
41
DOSAGE schema
D
O
S
A
G
E
D
I
n
s
u
l
i
n
_
P
u
m
p
(
d
o
s
e



0

Ù



(
(
(

r
1



r
0
)

Ù

(

r
2



r
1
)
)

Ú
(
(

r
1

gt

r
0
)

Ù


(
r
2



r
1
)
)


Ú
(
(

r
1

lt

r
0
)

Ù


(
(
r
1
-
r
2
)

gt

(
r
0
-
r
1
)
)
)




)


Ú

d
o
s
e



4

Ù



(

(
(

r
1



r
0
)

Ù

(
r
2

r
1
)
)


Ú

(
(

r
1

lt

r
0
)

Ù

(
(
r
1
-
r
2
)



(
r
0
-
r
1
)
)
)




)


Ú
d
o
s
e


(
r
2

-
r
1
)



4

Ù




(
(
(

r
1



r
0
)

Ù


(
r
2

gt

r
1
)
)

Ú
(
(

r
1

gt

r
0
)

Ù


(
(
r
2

-

r
1
)



(
r
1

-

r
0
)
)
)





)
)
c
a
p
a
c
i
t
y
'



c
a
p
a
c
i
t
y

-

d
o
s
e
c
u
m
u
l
a
t
i
v
e
_
d
o
s
e
'



c
u
m
u
l
a
t
i
v
e
_
d
o
s
e



d
o
s
e
r
0
'



r
1

Ù


r
1
'



r
2
42
Details on the Requirements Task

• How To Do Requirements Using
• the Rational Unified Process

43
Activity Overview
44
Capturing Requirements as Use Cases

• Use cases
• Offer a systematic and intuitive way to capture
  functional requirements
• complement written documents of the system shall
  which are good for system test/verification
• Focus on the value the system adds to each user
  or external system
• Force analysts to think in terms of who the users
  are and their business or mission needs
• Drive the other development workflows
• Requirements activity description (next set of
  slides)
• artifacts created
• workers participating
• detailed activities

45
Use-Case Model Artifact

• Actors
• Each type of user and each type of external
  system, i.e., parties outside the system that
  interact with the system
• There will be (at least) one system use case for
  each actor role
• Use Case
• Each way the actors use the system is represented
  by a use case
• Chunks of functionality the system offers to add
  a result of value to its actors
• Specifies sequence/alternative sequences of
  actions/events that the system can perform,
  interacting with the actors of the system
• Special requirements specific to the use-case
• Can structure complex or large use case models
• perspectives, packages, ltltusesgtgt, ltltextendsgtgt,etc.

46
Other Artifacts

• Architectural view of use-case model
• shows the architecturally significant use cases
• important and critical functionality
• important requirements to develop early
• input to use case prioritization
• corresponding use case realizations usually
  appear in analysis and design models
• Glossary
• Important and common terms
• Consensus agreement on meaning
• Less formal view of business/domain model
• User-interface prototype
• help understanding of user/system interaction

47
Core Workflow
Find Actors and Use Cases
Structure the Use Case Model
System Analyst
Prioritize Use Cases
Architect
Detail a Use Case
Use-Case Specifier
Prototype User Interface
User-Interface Designer
Repeat and Iterate
48
Activity Find actors and use cases

• Purpose
• System boundary delimit system from environment
• Outline actors and their use cases
• Capture and define common terms (glossary)
• Inputs
• Stakeholders (especially customers, users, other
  analysts)
• Business/domain model, vision document, customer
  requirements specification
• Activity steps
• Find actors
• Find use cases
• Describe each use case
• Describe use case model as a whole (incl.
  glossary)

49
Finding the actors

• Example actors or actor categories
• Business workers, business actors
• The person/system asking the question, making the
  decision
• External systems
• System maintenance and operational support
• Criteria
• Must be at least one real user who can enact the
  candidate actor
• Minimum overlap between roles
• Capture
• Actor name
• What the actor uses the system for actor needs
  and system responsibilities
• What the system uses the actor for role and
  actor responsibilities and system needs

50
Finding the use cases

• Examples deliver an observable result of value
  to a particular actor
• Use case(s) for every role of every worker
• Use case to support users need to create,
  change, track, remove or study business objects
• Use case to allow user to tell system of event or
  for system to tell user of event
• Use cases for system startup, termination or
  maintenance
• Use case name verb phrase describing result of
  interaction
• Use case scope and boundaries are hard to find
• Decouple them in time and data sharing
• Iterate with architecture tasks

51
Briefly describing the use cases and use case
model as a whole

• Description iteration name --gt few words --gt few
  sentences to summarize actions --gt detailed
  step-by-step action/response --gt formal models
• Model as a whole
• Glossary of common terms
• Survey description interaction of actors,
  interaction of use cases
• Use case generalizations and extensions
• Flows between use cases
• Group by business use case, by actor, by
  coupling, etc.
• Review use case list is complete sequences of
  actions are correct, complete and understandable
  all use cases have value

52
Prioritize and detail use cases

• Prioritize based on clarity of system scope,
  architecture impact, and risk
• Detail event flow, use case start/end, actor
  interaction
• Pre-conditions basic flow through states
  post-conditions
• Alternative flows to accommodate
• actor choice
• influence of other actors
• actor error
• system error or failure

53
Use case description

• Start states (preconditions)
• The first action to perform
• Action order
• Basic/normal
• Alternates
• Constraints
• How the use case ends
• Possible end states (postconditions)

• System interaction with actor and what they
  exchange
• Clarify which does what
• Actor initiation, system response
• System initiation, actor response
• If actor is an external system, specify
  protocol
• Usage of system objects, values and resources
• Non-functional requirements

Review understandable, correct, complete,
consistent
54
Formalizing use case descriptions

• State chart diagrams
• States, transitions, actions
• Activity diagrams
• Emphasizes activities between state transitions
• Actor/use-case interaction diagrams
• Sequences of actions, data, and results between
  actor and system

55
Activity prototype user interfaces

• Inputs to activity use-case model, detailed
  use-case descriptions, supplementary
  requirements, glossary (or business/domain model)
• Actor interacts by viewing and manipulating
  elements that represent attributes of use cases
• Assure each use case is accessible to the actors
  through the user interface
• Assure well-integrated, easy-to-use, consistent,
  navigable user interfaces
• Analyze usability dont be fooled by wording of
  use case
• Build physical prototype to validate UI and the
  use cases

56
Activity Structure the use-case model

• General and shared functionality ltltusesgtgt
• Like inheritance specific (real) uses general
  (abstract)
• The generalization captures overlap between use
  cases
• Additional or optional functionality ltltextendsgtgt
• Be careful in structuring use-case model
• Reflect real use cases
• Keep things understandable and manageable
• Decompose functionality in the analysis model,
  not the use-case model
• Object-oriented decomposition, not functional
  decomposition

57
Summary of requirements activities

• Capture requirements as
• Business model, domain model or glossary to
  capture system context
• Use-case model that captures functional
  requirements and use-case-specific nonfunctional
  requirements
• Survey description of model as a whole
• Set of use case and high-level class diagrams
• Detailed description of each use case
• Set of user-interface sketches/prototypes for
  each actor
• Supplementary requirements specification for
  requirements not specific to a use case
• Next steps
• Use cases drive use-case realization in analysis
  and design and test cases in testing
• Analysis reformulate use cases as objects