Chapter 4

Requirements Elicitation and Analysis

By:
Hailemichael Kefie
Software Engineering Dept.
 Requirements analysis

 The goal of analysis is to discover problems, incompleteness and

inconsistencies in the elicited requirements. These are then fed back to
the stakeholders to resolve them through the negotiation process.

Analysis is inserted with elicitation as problems are discovered when

the requirements are elicited.

2
 C Requirements

 Customer wants and needs;

Expressed in language understood by the customer.

Write c-requirements, review with customer, and update when

necessary.

They are expressed using: -

 Use cases with a use case diagram. A use case specifies a collection of scenarios.

 Data flow diagram explains the flow of data items across various functions.
Useful for explaining system functions.

 State transition diagram explains the change of system state in response to one
or more operations. 3
 D Requirements

 For the developers; may be more formal.

Obtain d-requirements from c-requirements and customer.

Write d-requirements; check to make sure that there is no

inconsistency between the c and the d requirements.
 Organize the d-requirements. As functional, non functional

 Create sequence diagrams for use cases:

 Outline test plans

 Inspect

 Validate with customer & release

4
The Requirements Model

5
6
 What Is System Behavior?

System behavior is how a system acts and reacts.

It is the visible and testable activity of a system

 System behavior is captured by use cases.

The most important aspect is to capture the dynamic behavior.

 Dynamic behavior means the behavior of the system when it is
running/operating.

7
 What Is a Use-Case Model?
 A model that describes a system’s functional requirements in
terms of use cases

Represents

 System’s intended functionality (use cases) and

 Its environment (actors)

8
 Purposes of Use Case Diagrams
Used to gather the requirements of a system.
Used to get an outside view of a system.

Identify the external and internal factors influencing the system.

Show the interaction among the requirements are actors.

When we are planning to draw a use case diagram, we should have the
following items identified.
 Functionalities to be represented as use case

 Actors

 Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system.
9
 What Is an Actor?

Actors are EXTERNAL.

Actors are not part of the system.

Actors represent roles a user of the system can play.

An actor represents anything that interacts with the system

They can represent a human, a machine, or another system.

They can actively interchange information with the system.

They can be a giver of information.

They can be a passive recipient of information.

10
 Useful Questions in Finding Actors?

Actors are EXTERNAL.

Who will supply, use, or remove information?

Who will use this functionality?

Who is interested in a certain requirement?

Where in the organization is the system used?

What are the system’s external resources?

What other systems will need to interact with this one?

11
 What is an Use case.
A use case is

 a sequence of actions a system

performs that yields an observable

result of value to a particular actor.

Use Cases and Actors

A use case model: a dialog between actors and the system.

 A use case is initiated by an actor to invoke a certain functionality in the

system.

12
 How to Find Use Cases

Answer the following questions to find use cases.

 For each actor you have identified, what are the tasks the system would be
involved in?

 Does the actor need to be informed about certain occurrences in the system?

 Will the actor need to inform the system about sudden, external changes?

 What information must be modified or created in the system?

13
Elements of Use Case Diagram

14
 Linking Use Cases
Association relationships

Generalization relationships

 One element (child) "is based on“

another element (parent)

Include relationships
 One use case (base) includes the

functionality of another (inclusion case)

 Supports re-use of functionality

Extend relationships
 One use case (extension) extends the behavior of another (base)
15
 1. Generalization
The child use case inherits the behavior and meaning of the parent
use case.

The child may add to or override the behavior of its parent.

16
Generalization examples…

17
Generalization examples…

18
 2. Include

 The base use case explicitly incorporates the behavior of another use case at a
location specified in the base.

 The included use case never stands alone. It only occurs as a part of some larger
base that includes it.

 Enables us to avoid describing the same flow of events several times by putting the
common behavior in a use case of its own.

19
 Include relationship
Include relationship – a standard case linked to a mandatory use
case.

Example: to Authorize Car Loan (standard use case), a clerk must

run Check Client’s Credit History (Include Use Case)

The standard UC includes the mandatory UC (use the verb to figure

direction arrow).include use case).

Standard use case can NOT execute without the include case ->
tight coupling .

20
Include relationship

21
 3. Extend
 The base use case implicitly incorporates the behavior of another use case at
certain points called extension points.

 The base use case may stand alone, but under certain conditions its behavior may
be extended by the behavior of another use case.

 Enables to model optional behavior or branching under conditions.

 Extend relationship
 linking an optional use case to a standard use case.

 Example: Register Course (standard use case) may have Register for Special Class
(extend use case) – class for non-standard students, in unusual time, with special topics,
requiring extra fees…).

 The optional UC extends the standard UC

22
 Standard use case can execute without the extend case ->loose coupling.
Extend Example #1

23
Extend Example #2

24
Extend Example #2 contd.

25
Brief Overview of Use Case Core Components
and Structure

26
Brief Overview of Use Case Core Components and Structure

27
 Use-Case Specifications

Name

Brief description

Flows of Events

Relationships

Activity diagrams

Use-Case diagrams

Special requirements

Pre-conditions

Post-conditions

Other diagrams
• Brief Overview of 28
 Use Case Core Components and Structure:
Use Case Description
 Basic Structure and Components  Post-Conditions
 Additional Components
 Use Case: Name  Basic Flow
Special Requirements
 Brief Description  Alternate Flows
Data Sources *
 Actors  Exception Flows
Dependencies
 Pre-Conditions Assumptions

Open Issues

29
 Scenarios
Scenario: a set of actions performed to achieve a goal under some
conditions
 Actions specified as a sequence of steps

 A step is a logically complete action performed either by the actor or the

system

Main success scenario: when things go normally and the goal is

achieved

Alternate scenarios: when things go wrong and goals cannot be

achieved

30
 Example 1

 Use Case 1: Buy stocks

 Primary Actor: Purchaser

 Goals of Stakeholders:
 Purchaser: wants to buy stocks

 Company: wants full transaction info Precondition: User already has an account

 Main Success Scenario

 User selects to buy stocks
 System gets name of web site from user for trading
 Establishes connection
 User browses and buys stocks
 System intercepts responses from the site and updates user portfolio
 System shows user new portfolio standing
31
 Alternatives
 2a: System gives error message, asks for

new suggestion for site, gives option to cancel

 3a: Web failure.
1.Sys reports failure to user & backs up to previous step.
2.User exits or tries again

4a: Computer crashes

4b: web site does not acknowledge purchase
5a: web site does not return needed info

32
 Example 2

 Use Case 2: Buy a product

 Primary actor: buyer/customer

 Goal: purchase some product

 Precondition: Customer is already logged in

 Main Scenario
Customer browses and selects items
Customer goes to checkout
Customer fills shipping options
System presents full pricing info
Customer fills credit card info
System authorizes purchase
System confirms sale
System sends confirming email 33
Alternatives
 6a: Credit card authorization fails
 Allows customer to reenter info
 3a: Regular customer
System displays last 4 digits of credit card no
Asks customer to OK it or change it
Moves to step 6

34
 UML Class Diagram
Class diagram is a static diagram. It represents the static view of an
application.

Class diagram is not only used for visualizing, describing, and

documenting different aspects of a system but also for constructing
executable code of the software application.

Class diagram describes the attributes and operations of a class and also
the constraints imposed on the system.

The class diagrams are widely used in the modeling of object oriented
systems because they are the only UML diagrams, which can be mapped
directly with object-oriented languages.
35
 UML Class Diagram components

The main symbols shown in class diagrams are:
Class: A class represents the blueprint (template) of its objects.

Fields (Attributes, Variables or Constants)

A field represents the state of the class and its instances.

Behavior (Operations or Methods)

A behavior represents an operation performed by the class and its instances.

Associations
An association represents a relationship between two classes.

Generalizations
A generalization groups classes into an inheritance hierarchy. 36
 Contd..
The following points should be remembered while drawing a class

diagram :-
 The name of the class diagram should be meaningful to describe the aspect of the system.

 Each element and their relationships should be identified in advance.

 Responsibility (attributes and methods) of each class should be clearly identified

 For each class, minimum number of properties should be specified, as unnecessary

properties will make the diagram complicated.

 Use notes whenever required to describe some aspect of the diagram. At the end of the

drawing it should be understandable to the developer/coder.

 Finally, before making the final version, the diagram should be drawn on plain paper and

reworked as many times as possible to make it correct. 37

 E.g. Order Management
First of all, Order and Customer are identified as the two elements
of the system.

They have a one-to-many relationship because a customer can have

multiple orders.

Order class is an abstract class and it has two concrete classes

(inheritance relationship) SpecialOrder and NormalOrder.

The two inherited classes have all the properties as the Order class.

In addition, they have additional functions like dispatch () and

receive ().
38
E.g. Order Management

39
 UML Representation of Classes
 A class is simply represented as a box with the name of the class
inside.
 The diagram may also show the attributes and/or operations (fields
and behaviour).
 The complete signature of an operation is:
 operationName(parameterName: parameterType …): returnType

 Examples:
Rectangle Rectangle Rectangle Rectangle Rectangle
getAre height height height: int
a width width width: int
reSize getArea getArea(): int
reSize
reSize(int,int
) 40
 Association and Multiplicity
 An association shows how classes are connected to each other:
 Symbols indicating multiplicity are shown at each end of
the association. *
Employee Company

* 1..*
Secretary Manager

Company BoardofDirectors

0..1 *
Office Employee

0, 3..8 *
Person BoardofDirectors

LEGEND
x..* (the range from x to many).
x..y (the range from x to y).

41
 Labelling Associations

 Each association can be labelled, to make explicit the nature of the

association:

Association Association
Role Association Name Role
Class1 Class2

42
 Labelling Associations

* Works for →
Employee Company

Secretary * has 1..* Manager

Company BoardofDirectors

0..1 isAllocated *
Office Employee

0, 3..8 isMember *
Person BoardofDirectors

43
 Contd..

* Works for →
Employee Company

 Many-to-one
 A company has many employees.
 An employee can only work for one company.
 This system is not capable of processing information about
more than one company per employee.

 A company can have zero employees.

 E.g. a ‘shell’ company.

 It is not possible to be an employee unless you work for a company.

44
 Contd..

* 1..*
Secretary Manager

 Many-to-many
 A secretary can work for many managers.
 A manager can have many secretaries.
 Secretaries can work in pools.
 Managers can have a group of secretaries.
 Some managers might have zero secretaries.
 It is not possible for a secretary to have zero managers.

45
 Contd..

Company BoardofDirectors

 One-to-one

 For each company, there is exactly one board of directors.

 A board is the board of only one company.

 A company must always have a board.

 A board must always be of some company.

46
 Contd..

0, 3..8 isBoardMember *
Person BoardofDirectors

 Many-to-many

 There can be zero people on a board of directors.

 There can be three to eight people on a board of directors.

 A person plays the role of a “board member”.

 A person can be a member of more than one board.

 A person can exist without being a member of any board.

47
Thank
ThankYou
You ...
...