Requirements Analysis

and the Unified Process

1
Contents
 Requirements Analysis: What and
what?
 Unified Process
 OO Analysis and Design
 Basics
 UML
 Actors, Use cases

2
 Requirements Analysis [1]
 What is it?
 The process by which customer needs
are understood and documented.
 Expresses “what” is to be built and NOT
“how” it is to be built.
 Example 1:
 The system shall allow users to withdraw cash.

[What?]
 Example 2:
 A sale item’s name and other attributes will be

stored in a hash table and updated each time

any attribute changes. [How?]
3
Requirements Analysis [2]
 C- and D-Requirements
 C-: Customer wants and needs;
expressed in language understood by the
customer.
 D-: For the developers; may be more
formal.

4
 Requirements Analysis [2]
Why document requirements?

Serves as a contract between the customer and the

developer.

Serves as a source of test plans.

Serves to specify project goals and plan development

cycles and increments.

5
Requirements Analysis [3]
 Roadmap:
 Identify the customer.
 Interview customer representatives.
 Write C-requirements, review with
customer, and update when necessary.
 Write D-requirements; check to make
sure that there is no inconsistency
between the C- and the D-requirements.

6
Requirements Analysis [4]
 C-requirements:
 Use cases expressed individually and with a use
case diagram. A use case specifies a collection of
scenarios.

Sample use case: Process sale.
 Data flow diagram:

Explains the flow of data items across various
functions. Useful for explaining system functions.
[Example on the next slide.]
 State transition diagram:

Explains the change of system state in response to
one or more operations. [Example two slides later.]
 User interface: Generally not a part of requirements
analysis though may be included. [Read section 3.5
from Braude.] 7
Data Flow Diagram
Employee Record
Overtime
rate
Get employee
file Pay rate Company records
*
Weekly Pay
ID * Overtime
pay
pay
Regular Overtime
*
hours hours Total pay
Worker Deduct
taxes

Tax rates Net pay

Check Issue
paycheck
8
State Transition Diagram
(STD)
Elevator example (partial):
EBP(e,f)
EBOFF (e,f) EBON (e,f)
EBP(e,f)

EBOFF (e,f): Elevator e button OFF at floor f.

EBON (e,f): Elevator e button ON at floor f.

EBP(e,f): Elevator e button f is pressed.

EAF(e,f): Elevator e arrives at floor f.

9
Requirements Analysis [5]
 D-requirements:
1. Organize the D-requirements.
2. Create sequence diagrams for use
cases:

Obtain D-requirements from C-requirements
and customer.

Outline test plans

Inspect
3. Validate with customer.
4. Release:

10
Requirements Analysis [6]

1. Organize the D-requirements.

(a) Functional requirements
The blood pressure monitor will measure the
blood pressure and display it on the in-built
screen
(b) Non-functional requirements
(i) Performance
The blood pressure monitor will complete a
reading within 10 seconds.
(ii) Reliability
The blood pressure monitor must have a failure
probability of less than 0.01 during the first
500 readings.
11
Requirements Analysis [7]

(c) Interface requirements: interaction

with the users and other applications
The blood pressure monitor will have a display
screen and push buttons. The display screen
will….
(d) Constraints: timing, accuracy
The blood pressure monitor will take readings
with an error less than 2%.

12
Requirements Analysis [7]
Properties of D-requirements:
1. Traceability:Functional requirements
D-requirement  inspection report  design
segment  code segment  code inspection
report  test plan  test report

2. Traceability:Non-Functional
requirements
(a) Isolate each non-functional requirement.
(b) Document each class/function with the
related non-functional requirement.

13
Requirements Analysis [8]
Properties of D-requirements:
3. Testability
It must be possible to test each requirement.
Example ?
4. Categorization and prioritization

14
Categorizing
Requirements
 How to categorize system functions?
Function Category Meaning

Evident Should perform, user is aware

Hidden Should perform but not visible

to users

Frill Optional; Nice to have

15
Prioritizing (Ranking) Use
Cases
 Strategy :
 pick the use cases that significantly
influence the core architecture
 pick the use cases that are critical to
the success of the business
 a useful rule of thumb - pick the use
cases that are the highest risk!!!

16
Requirements Analysis [9]
Properties of D-requirements:
5. Completeness
Self contained, no omissions.
6. Error conditions
State what happens in case of an error. How
should the implementation react in case of an
error condition?

17
Requirements Analysis
[10]
Properties of D-requirements:
7. Consistency
Different requirements must be consistent.
Example:
R1.2: The speed of the vehicle will never
exceed 250 mph.
R5.4: When the vehicle is cruising at a speed
greater than 300 mph, a special “watchdog”
safety mechanism will be automatically
activated.

18
The Unified Process
 Why a Process?
 Software projects are large, complex,
sophisticated
 time to market is key
 many facets involved in getting to the
end
 Common process should
 integrate the many facets
 provide guidance to the order of
activities
 specify what artifacts need to be 19
The Unified Process
 Component based - meaning the software
system is built as a set of software
components interconnected via interfaces
 Uses the Unified Modeling Language
This is what(UML)
makes
 Use case driven the Unified process
Unique
 Architecture-centric
 Iterative and incremental
Component: A physical and replaceable part of a system that conforms to
and provides realization of a set of interfaces.
Interface: A collection of operations that are used to specify a service of a
class or a component

20
The Unified Process

Software
User’s Software
Development
requirements System
Process

21
The Unified Process
 Use Case driven
 A use case is a piece of
functionality in the system that
gives a user a result of value
 Use cases capture functional
requirements
 Use case answers the
question: What is the system
supposed to do for the user?

22
The Unified Process
 Architecture centric
 similar to architecture for building a
house
 Embodies the most significant static
and dynamic aspects of the system
 Influenced by platform, OS, DBMS
etc.
 Primarily serves the realization of
use cases

23
The Unified Process
 Iterative and Incremental
 commercial projects continue many
months and years
 to be most effective - break the project
into iterations
 Every iteration - identify use
cases,create a design, implement
the design
 Every iteration is a complete
development process

24
The Unified Process
 Look at the whole
process
 Life cycle
 Artifacts
 Workflows
 Phases
 Iterations

25
The Life of the Unified
Process
 Unified process repeats over a
series of cycles
 Each cycle concludes with a
product release
 Each cycle consists of four
phases:
 inception
 elaboration
 construction
 transition

26
The Life of the Unified
Process
Time

Inception Elaboration Construction Transition

Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration

1 1 1 1

Release 1
A cycle with its phases and its iterations
27
OO Analysis and Design
 Compare and Contrast analysis and design
 Define object-oriented analysis and design
 Relate, by analogy, OO analysis and design to
business organization.

28
What is Analysis and
Design?
 Analysis - investigation of the problem (what)
 Design - logical solution to fulfill the
requirements (how)

29
What is OO analysis and
design?
 Essence of OO analysis - consider a problem
domain from the perspective of objects (real
world things, concepts)
 Essence of OO design - define the solution as a
collection of software objects (allocating
responsibilities to objects)

30
Examples
 OO Analysis - in the case of the library
information systems, one would find concepts
like book, library, patron
 OO Design - emphasis on defining the software
objects; ultimately these objects are
implemented in some programming language;
Book may have a method named print.

31
Example - contd.
Representation in
Domain concept analysis of
concepts

Book
______
title
print()

Public class Book

Representation in OO {
public void print();
programming language private string title;
}

32
What are the business
processes?
 First step - consider what the business must
do; in the case of a library - lending books,
keeping track of due dates, buying new books.
 In OO terms - requirements analysis; represent
the business processes in textual narration
(Use Cases).

33
Business processes -
contd.
 Identifying and recording the business
processes as use cases is not actually an
object oriented activity; though a necessary
first step.

34
Roles in the organization
 Identify the roles of people who will be
involved in the business processes
 In OO terms - domain analysis
 Examples - customer, library assistant,
programmer, navigator, sensor, etc.

35
Who does what?
Collaboration
 Business processes and people identified;
time to determine how to fulfill the
processes and who does these processes
 in OO terms - object oriented design;
assigning responsibilities to the various
software objects
 often expressed in class diagrams

36
In Summary...
Business OO Analysis Associated
Analogy and Design Documents
What are the Requirements Use cases
business analysis
processes?
What are Domain analysis Conceptual
employee roles? model
Who is Responsibility Design class
responsible for assignment; diagrams
what?

37
Simple example to see big
picture
 Define use cases
 Define conceptual model
 Define collaboration diagrams
 Define design class diagrams
Example: Dice game a player rolls two die.
If the total is 7 they win; otherwise they lose

38
Define use cases
 Use cases - narrative descriptions of
domain processes in a structured
prose format
Use case: Play a game
Actors: Player

Description: This use case begins when

the player picks up and rolls the die….

39
Define conceptual model
 OO Analysis concerns
 specification of the problem domain
 identification of concepts (objects)
 Decomposition of the problem
domain includes
 identification of objects, attributes,
associations
 results can be expressed in
conceptual model
40
Conceptual model - dice
game

Player Die
_____
1 Rolls 2 ____
name facevalue

1 2

Plays DiceGame Includes

1 1

Conceptual model is not a description of the software components;

it represents concepts in the real world problem domain

41
Defining collaboration
diagram
 OO Design is concerned with
 defining logical software specification
that fulfills the requirements
 Essential step - allocating
responsibility to objects and
illustrating how they interact with
other objects
Expressed
 Collaboration as express
diagrams Collaboration diagrams
the flow of messages between
Objects.

42
Example - collaboration
diagram
1:r1:=roll()
:Player d1:D ie

2:r2:= roll()
d2:D ie

43
Defining class diagrams
 Key questions to ask
 How do objects connect to other objects?
 What are the behaviors (methods) of
these objects?
 Collaboration diagrams suggests
connections; to support these
connections methods are needed
 Expressed as class diagrams

44
Example - Class diagram
Player R olls D ie
nam e faceValue
1 2
play() roll()
1 2

Plays D iceG am e includes

1 initialize() 1

A line with an arrow at the end may suggest an attribute.

For example, DiceGame has an attribute that points to an
instance of a Player

45
Defining Models and
Artifacts
 Objectives
 analysis and design models
 familiarize UML notations and
diagrams
 real world software systems are
inherently complex
 Models provide a mechanism for
decomposition and expressing
specifications

46
Analysis and Design
models
 Analysis model - models related to an
investigation of the domain and problem space
(Use case model qualifies as an example)
 Design model - models related to the solution
(class diagrams qualifies as an example)

47
Introduction to UML[1]
 UML is NOT a methodology
 UML is NOT a process
 UML is NOT proprietary (Now under the OMG)
 UML is strictly Notations

48
Introduction to UML[2]
 Goals of UML notation
 Simple : requires only a few concepts and
symbols
 Expressive : applicable to a wide spectrum of
systems and life cycle methods
 Useful : focuses only upon those necessary
elements to software engineering
 Consistent : the same concept and symbol should
be applied in the same fashion throughout

49
Introduction to UML[3]

 Goals of UML notation:

 Printable
 Extensible : users and tool builders should have
some freedom to extend the notation
 UML has different parts
 Views - shows different aspects of the system that
are modeled, links the modeling language to the
method/process chosen for development
 Diagrams - graphs that describe the contents in a
view
 Model elements - concepts used in a diagram

50
Introduction to UML[4]

Component Logical
View View
Use
Case
View
Concurrenc
Deployment
y
View
View

51
 Introduction to UML[5]
 Use-case view : A view showing the
functionality of the system as perceived by the
external actors
 Logical view: A view showing how the
functionality is designed inside the system, in
terms of the static structure and dynamic
behavior
 Component view: A view showing the
organization of the code components

52
Introduction to UML[6]
 Concurrency view: A view showing the
concurrency of the system
 Deployment view: A view showing the
deployment of the system in terms of the
physical architecture

53
Introduction to UML[9]
 Model elements
 Class
 Object
 State
 Use case
 Interface
 Association
 Link

Package ….

54
Introduction to UML[10]

 Use Case diagram: External interaction with

actors
 Class/Object Diagram : captures static
structural aspects, objects and relationships
 State Diagram: Dynamic state behavior
 Sequence diagram: models object interaction
over time
 Collaboration diagram: models component
interaction and structural dependencies

55
 Introduction to UML[11]
 Activity diagram : models object activities
 Deployment diagram : models physical
architecture
 Component diagram : models software
architecture

56
Case study - Point of Sale
 POS terminal should support the
following
 record sales
 handle payments
 many architectural layers
 presentation
 application logic (problem domain, service
support)
 persistence
 Emphasis - problem domain
application objects
57
Understanding
requirements
Ref# Function Category

R1.1 Record the current Evident

sale
R1.2 Calculate current Evident
sale total
R1.3 Reduce inventory Hidden

58
Analysis
 Objectives
 Identification of Use cases
 Draw use case diagrams
 Ranking Use cases
 Contrast essential and real use cases

59
Use cases [1]
 Excellent technique for improving the
understanding of requirements
 Narrative in nature
 Use cases are dependent on having some
understanding of the requirements
(expressed in functional specifications
document).

60
Use Cases [2]
 Use case - narration of the
sequence of events of an actor
using a system
 UML icon for use case

61
Actors [1]
 Actor - an entity external to the
system that in some way
participates in the use case
 An actor typically stimulates the
system with input events or
receives outputs from the
system or does both.
 UML notation for actor:
C ustom er

62
Actors [2]
 Primary Actor - an entity external to
the system that uses system services
in a direct manner.
 Supporting Actor- an actor that
provides services to the system
being built.
 Hardware, software applications,
individual processes, can all be
actors.
63
Identification of Use Cases
 Method 1 - Actor based
 Identify the actors related to the system
 Identify the processes these actors initiate or
participate in
 Method 2 - Event based
 Identify the external events that a system must
respond to
 Relate the events to actors and use cases
 Method 3 – Goal based
 [Actors have goals.]
 Find user goals. [Prepare actor-goal list.]
 Define a use case for each goal.
64
Identification of Use
Cases[2]

 To identify use cases, focus on elementary

business processes (EBP).
 An EBP is a task performed by one person
in one place at one time, in response to a
business event. This task adds measurable
business value and leaves data in a
consistent state..

65
Point of Sale - Actors
 Actors:
 Cashier
 Customer
 Supervisor
 Choosing actors:
 Identify system boundary
 Identify entities, human or otherwise, that will
interact with the system, from outside the
boundary.
 Example: A temperature sensing device is an
actor for a temperature monitoring application.

66
Point of Sale - Use Cases
 Cashier
 Log In
 Cash out
 Customer
 Buy items
 Return items

67
Common mistake
 Common error -
representing
individual steps as
use cases
 Example: printing a
receipt (Why?)

68
High level vs. Low Level Use
cases[1]
 Consider the following use cases:
 Log out
 Handle payment
 Negotiate contract with a supplier
 These use cases are at different levels.
Are they all valid? To check, use the EBP
definition.
 Log out: a secondary goal; it is necessary
to do something but not useful in itself.
 Handle payment: A necessary EBP. Hence
a primary goal.
69
High level vs. Low Level Use
cases [2]
 Log out: a secondary goal; it is necessary
to do something but not useful in itself.
 Handle payment: A necessary EBP. Hence
a primary goal.
 Negotiate contract: Most likely this is too
high a level. It is composed of several
EBPs and hence must be broken down.

70
 Use Case Diagram -
Example
Process sale

Payment
Authorization
Cashier Handle returns
service

Process rental <<actor>>

Tax calculator

Manage
System administrator <<actor>>
security
Accounting
Manage users
system

Use Case Diagram: illustrates a set of use cases for a system.

71
More on Use Cases
 Try to describe use cases independent of
implementation
 Be as narrative as possible
 State success scenarios (how do you measure
the success of an use case)
 A use case can have many scenarios (threads
of execution)
 Agree on a “format style” for use case
description
 Name a use case starting with a verb in order
to emphasize that it is a process (Buy Items,
Enter an order, Reduce inventory) 72
More on Use Cases
 Document exception handling or branching
 when a “Buy Item” fails, what is expected of the
system
 when a “credit card” approval fails, what is expected
of the system

73
A sample Use Case
Use case: Buy Items
Actors: Customer, Cashier
Type: Primary, Essential
Description: A customer arrives at a checkout with
items to purchase. The cashier records
the purchase items and collects payment.

74
Ranking Use Cases
 Use some ordering that is customary to your
environment
 Example: High, Medium, Low
 Example: Must have, Essential, Nice to have

 Useful while deciding what goes into an

increment

 Point of sale example:

 Buy Items - High
 Refund Items - Medium (Why?)
 Shut Down POS terminal - Low
75