Requirements Engineering

Requirements
Analysis and
Model
TOPIC TWO
Software Engineering

Requirements Analysis

It is a technique employed to create the requirements model

that illustrates the requirements of the system.
The purpose of defining the requirements:

To define a basic agreement between customers, stakeholders and

developers on what the system should do

To aid system developers in understanding system requirements

To define the scope and boundaries of the system

To aid in the planning of technical contents of each iteration of

software development

To aid in estimating cost and effort in developing the software system

To present the user-interface of the system while focusing on the

needs and goals of the users
Software Engineering

Requirements Model

Use-Case Model

Use-Case Model

Use-Case Diagram

Use-Case Specifications

Supplementary
Specification (Optional)

Actor

Use Cases

Actor

Supplementary
Specification

Glossary (Optional)
Glossary
Use-Case Specifications

Software Engineering

Use-Case Model

Use to describe what the system will do

Describes a system's functional requirements

Describes a system's intended functionality and its

environment
Serves as a contract between customers, users, and the
system developers
Allows customers and users to validate that the system will
become what is expected
Allows system developers to ensure that what they build is
what is expected

Software Engineering

Use-Case Diagram

consists

Actors

Use Cases

Associations

Software Engineering

Actor

It represents a coherent set

of roles that users of the
system play when
interacting with use cases.
It can be a person, device
or another system.
It is graphically represented
by a stick person.

Software Engineering

Use Case

It describes the functions

that the system performs
when interacting with
actors.
It yields an observable
results to the actors.
It is described using a verbnoun format.

Software Engineering

Associations

It is the relationship or
association between an
actor and use-cases,
and/or between use-cases.

or

It has two special

relationship of association.

Include

Extend

Software Engineering

Include and Extend

Association

Include Association

It is used to show that when

one use case is used, the
other is also used.

<<include>>

Extend Association

It is used to show that a use

case provides additional
functionality that may be
required in another use case.

Software Engineering

<<extend>>

First Iteration of Use Case

Model

Software Engineering

10

Second Iteration of Use Case

Model

Software Engineering

11

Use-Case Specification

It is a document where all of the use-case properties are

documented. For each use-case, there should be a
corresponding use-case specification.
It consists of the following information:

Name

Brief Description

Pre-conditions

Flow of Events

Post-conditions

Relationships

Special Requirements

Other Diagrams

Software Engineering

12

Name

It represents the name of the use-case, which follows the

verb-noun format.
It should match the use-case name found in the Use-Case
diagram.

Software Engineering

13

Description

It describes the role and purpose of the use-case using a

few lines of sentence, preferably 3-5.

Software Engineering

14

Pre-conditions

It defines a constraint on the system for when the use-case

starts.
It specifies the conditions that must exists before the usecase can start.

Software Engineering

15

Flow of Events

These are events that describes what the use case is doing.
There may be multiple flow of events, ie, a basic flow and
alternative flow.
It should present what the system does; NOT how the
system is designed to perform.
Events are also known as scenarios.

Software Engineering

16

Activity Diagrams

It is a graphical representation of the flow of events.

It can be used to capture the activities in the use case.

It is essentially a flow chart, showing flow or control from

activity to activity.

Software Engineering

17

Activity Diagram Elements

Activity States

Transitions

Decisions

Synchronization Bars

Software Engineering

18

Activity States

It represents the
performance of an activity
or step within the work flow.
It represented by a
rectangle with circular
edges.

Software Engineering

Get Application Form

19

Transition

It shows what activity state

follows after another.
It is represented as a line
with an arrow head to
indicate direction of state
change.

Software Engineering

20

Decisions

It is used to evaluate
conditions.
It uses guard conditions
which determines the
alternative transitions that
will be made.
It is used to show
alternative threads in the
work flow.

Software Engineering

21

Synchronization Bars

It is used to show parallel

sub-flows.
It illustrate concurrent
threads in the work flow.

Software Engineering

22

Sample Activity Diagram

Software Engineering

23

Swimlane Diagram

It is an activity diagram where activities are aligned based

on the actors who have responsibility for the specified
activity.

Software Engineering

24

Sample Swimlane Diagrams

Software Engineering

25

Guidelines for Defining the

Flow of Events

To enforce actor responsibility, start the description with

When an actor....
Describe the data exchange between the actor and use
case.
Try not to describe the details of the user interface unless
needed.
Answer ALL what questions. Test designer will use this
text to identify test cases.
Avoid terminologies such as For example,... process and
information
Describe when the use case starts and ends.
Software Engineering

26

Post-condition

It defines a constraint on the system for after the use-case

has terminated.

Software Engineering

27

Special Requirements

It is a textual description that collects all use case

requirements, like non-functional requirements that are not
considered in the Use-Case Model, yet need to be taken
into consideration during design or implementation.

Software Engineering

28

Other Diagrams

It can be used to illustrate the use-case, like hand-drawn

sketches or screen dumps from a user-interface prototype.

Software Engineering

29

Supplementary Specification

It contains requirements that are not specified in the UseCase Model.

It contains non-functional requirements not captured in the
Use-Case Model.

It is an important complement to the Use-Case Model.

It may contain constraints in implementation.

Software Engineering

30

Supplementary Specification

It may include any of the following:

Functionality

Usability

Reliability

Performance

Supportability

Design Constraints

Software Engineering

31

Glossary

It defines important terms used in the system.

It is used to facilitate communication between system
experts and developers.
It is used to agree on common terminology between users
and developers
It consists of:

Introduction

Terms

Software Engineering

32

Requirements Model
Validation Checklist

Use-Case Model

Can we understand the Use Case Model?

Can we form a clear idea of the system's over-all

functionality?

Can we see the relationship among the functions that the

system needs to perform?

Did we address all functional requirements?

Does the Use Case Model contain inconsistent behavior?

Can the Use Case Model be divided into use case

packages? Are they divided appropriately?
Software Engineering

33

Requirements Model
Validation Checklist

Actor

Did we identify all actors?

Are all actors associated with at least one use case?

Does an actor specify a role? Should we merge or split

actors?

Do the actors have intuitive and descriptive names?

Can both users and customers understand the names?

Software Engineering

34

Requirements Model
Validation Checklist

Use cases

Are all use case associated with actors or other use

cases?

Are use cases independent of one another?

Are there any use cases that exhibit similar behavior or

flow of events?

Are use-cases given a unique, intuitive or explanatory

names?

Do customers and users alike understand the names and

descriptions of the use cases?
Software Engineering

35

Requirements Model
Validation Checklist

Use-Case Specifications

Can we clearly see who wishes to perform a use case?

Is the purpose of the use case also clear?

Is the use case description properly and clearly defined?

Can we understand it? Does it encapsulate what the use
case is supposed to do?

Is it clear when the flow of events starts? When it ends?

Is it clear how the flow of events starts? How it ends?

Can we clearly understand the actor interactions and

exchanges of information?

Are there any complex use cases?

Software Engineering

36

Requirements Model
Validation Checklist

Glossary

Is the term clear or concise?

Are the terms used within the use case specifications?

Are the terms used consistently within the system? Are

there any synonyms?

Software Engineering

37

Summary

Requirements Analysis

Requirements Model

Use Case Model

Use Case Specifications

Use Case Diagrams

Activity Diagrams

Supplementary Document

Glossary or Definition of Terms

Requirements Validation Checklist

Software Engineering

38