Instructor: Dr.

Syed Ali Raza

Department of Computer Science
GC University Lahore

Software
Chapter 6: Requirements Modeling: Scenarios,
Information,
and Analysis Classes
Requirements Analysis
• Requirements analysis
• specifies software’s operational characteristics
• indicates software's interface with other system elements
• establishes constraints that software must meet

• Requirements analysis allows the software engineer (called an analyst or modeler in this role)
to:
• elaborate on basic requirements established during earlier requirement engineering tasks
• build models that depict user scenarios, functional activities, problem classes and their relationships,
system and class behavior, and the flow of data as it is transformed.
Rules of Thumb
• The model should focus on requirements that are visible within the
problem or business domain. The level of abstraction should be relatively
high.
• Each element of the analysis model should add to an overall understanding
of software requirements and provide insight into the information domain,
function and behavior of the system.
• Delay consideration of infrastructure and other non-functional models
until design.
• Minimize coupling throughout the system.
• Be certain that the analysis model provides value to all stakeholders.
• Keep the model as simple as it can be.
Elements of Requirements
Analysis
Scenario-Based Modeling
• “[Use-cases] are simply an aid to defining what exists outside the
system (actors) and what should be performed by the system (use-
cases).” Ivar Jacobson
(1) What should we write about?
(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description?
What to Write About?
• Inception and elicitation—provide you with the information you’ll need to begin writing
use cases.
• Requirements gathering meetings, QFD, and other requirements engineering
mechanisms are used to
• identify stakeholders
• define the scope of the problem
• specify overall operational goals
• establish priorities
• outline all known functional requirements, and
• describe the things (objects) that will be manipulated by the system.
• To begin developing a set of use cases, list the functions or activities performed by a
specific actor.
How Much to Write About?
• As further conversations with the stakeholders progress, the
requirements gathering team develops use cases for each of
the functions noted.
• In general, use cases are written first in an informal narrative
fashion.
• If more formality is required, the same use case is rewritten
using a structured format similar to the one proposed.
Use-Cases
• a scenario that describes a “thread of usage” for a system
• A Use-case is defined as a set of sequences of actions a system performs that
yield an observable result of value to a particular actor.
• Actions can involve communicating with number of actors as well as
performing calculations and work inside the system.
• A Use-case
• is always initiated by an actor.
• provides a value to an actor.
• must always be connected to at least one actor.
• must be a complete description.
Developing a Use-Case
• For each actor ask these questions:
• What are the main tasks or functions that are performed by the actor?
• What does the actor need to do?
• Will the actor have to inform the system about changes in the external
environment?
• Does the actor wish to be informed about unexpected changes?
• What are the problems with the existing systems?
• What are the inputs and outputs of the system?
Creating Use Cases
1.Identify actors
2.Define use cases List Actors What is system
response to external
3.Discover reuseable use cases event? What is the
List External Determine
4.Put uses into tables with id, Events expected behavior user’s goal?
name, primary actors etc.
5.Write use case description for Name behaviors as
each use case use cases

• brief description
Add relations
• Basic flow Document use case
(includes, extends,
(basic flow,
• Alternative flow generalization)
alternate, exception)
Actors
• An actor is something or someone that needs to interact with the system.
• Message sent by an actor may result in more messages to actors and to Use-
cases.
• Actors can be ranked: primary and secondary; passive and active.
• The actors of a system can be identified by answering a number of questions:
• Who or what will use the main functionality of the system?
• Who or what will provide input to this system?
• Who or what will use output from this system?
• Who will need support from the system to do their work?
• Are there any other software systems with which this one needs to interact
• Are there any hardware devices used or controlled by this system?
Example
Relationships Between Actors
• Actors can be related by generalization/specialization
• Actors are classifiers (not individual users)

Student e
w is
r
othe
s ..
v iou
y ob t
Graduate ver ip i
Student h en sk
th is w
Do
Identify Reuse In Use Case
Use Case Relationships
Includes

Extends

Generalization
Use-Case Relationships
• Includes Dependency: Defines how one use case can invoke
behavior defined by another use case

Alter Student Grade

<<includes>>

Record Grades for a

Teacher
Section
Use-Case Relationships
• Extends dependency: defines a use-case that is a variation of
another, usually for handling an abnormal situation

Alter Student Grade

<<extends>>

Alter student grade for Authorized

a class taken more Staff Worker
than a year ago
Use-Case Relations
• Generalization: Defines one use case as a generalization of another.
Replaces generic functionality with alternate implementation

Alter Student Grade

Alter Student Grade for

Teacher
a Graduate Course
An Example
Use case Description
• Use Case Number: 1
• Use Case Name: Buyer Places a Bid
• Description: An EBAY buyer has identified an item they wish to buy,
so they will place a bid for an item with the intent of winning the
auction and paying for the item.