JSPM’s

Rajarshi Shahu College

of Engineering

Department of Electronics and

Telecommunication Engineering

Class : TY. B. Tech. (B)

Subject: Software Engineering and Project
Management

Unit-II : REQUIREMENT ANALYSIS

By
Dr. B. D. Jadhav
1
1
Contents:
 Requirements Capturing:
• Requirements engineering :
elicitation, specification, validation, negotiation, prioritizing
requirements (Kano diagram)
Real life application case study.
• https://youtu.be/uo98gmTYmxg?si=oFOudWKf-hKCnD42
• https://youtu.be/ssmPLss2Vxg?si=4Gv6Iwef0E_qHeK8
• https://youtu.be/hneC9fXy7zU?si=3EJyAHG1_aBV8nLU
 Requirements Analysis:
• Basics, scenario based modeling,
• UML models: use case diagram and class diagram, data modeling,
data and control flow model, behavioral modeling using state
diagrams
• Real life application case study
• Software Requirement Specification.
 Requirement Capturing
Introduction:
 When 38 IT professionals in the UK were asked about which
project stages caused failure, respondents mentioned
“requirements definition” more than any other phase.

 A requirement is a statement about an intended product that

specifies what it should do or how it should perform.

 Goal: To make as specific, unambiguous, and clear as possible.

What requirements should be gathered?
 Functional: What the product should do.

 Data requirements: Capture the type, volatility, size/amount,

persistence, accuracy and the amounts of the required data.

 Environmental requirements:
a) context of use
b)Social environment (e.g. Collaboration and coordination)
c) how good is user support likely to be
d) what technologies will it run on

 User Requirements: Capture the characteristics of the

intended user group.

 Usability Requirement: Usability goals associated measures for

a particular product
 Requirements Capturing
 Definition : The broad spectrum of tasks and techniques
that can understand is called requirements engineering.
 It be begins during communication activity and continues
into the modeling activity.
 It must be adapted to the
• Needs of the process, the project, the product, and the
people doing the work.
• Requirements engineering builds a bridge to design and
construction.
 Requirements engineering provides the idea for
understanding the demands of customer, analyzing need,
assessing feasibility, negotiating a reasonable solution,
specifying the solution clearly, validating the specifications,
managing the requirements.
 Requirements Capturing tasks:
 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Management.
 Inception ( How it starts)
 Some casual discussions to begin a business..
 Most of the projects begin when a business need is
identified or a potential new market or service is
discovered.
 Stakeholders from the business community define a
business case for the idea, try to identify the breadth
and depth of the market, do a rough feasibility
analysis, and identify a working description of the
project’s scope.
 All of this information is subject to change
according to different requirements.
 Elicitation
(Process of extracting information form something)
 It certainly seems not simple enough to deal with requirements of stakeholder.
 A number of problems that are encountered as follows elicitation occurs:
a. Problems of scope.
 The boundary of the system is ill-defined
 customers/users specify unnecessary technical detail that may confuse,
rather than clarify, overall system objectives.
b. Problems of understanding.
 The customers/users are not completely sure of what is needed
 Poor understanding of the capabilities and limitations of their computing
environment
 Don’t have a full understanding of the problem domain
 Omit information that is believed to be “obvious,” specify requirements.
c. Problems of volatility.
 The requirements change over time.
 To overcome these problems, you must approach requirements gathering in an
organized manner.
 Specification

• In the context of computer-based systems (and software), the term

specification means different things to different people.
• A specification can be a written document, a set of graphical models, a
formal mathematical model, a collection of usage scenarios, a prototype,
or any combination of these.
• “standard template” should be developed and used for a specification.
• However, it is sometimes necessary to remain flexible when a specification
is to be developed.
• For large systems, a written document, combining natural language
descriptions and graphical models may be the best approach.
• However, usage scenarios may be all that are required for smaller products
or systems that reside within well-understood technical environments.
 Validation
•The work products produced are assessed for quality during a validation step.

•Requirements validation examines the specification to ensure that all

software requirements have been stated clearly

•Inconsistencies, omissions, and errors have been detected and corrected

• The primary requirements validation mechanism is the technical review.

• The review team that validates requirements includes software engineers,

customers, users, and other stakeholders:
1. Examine the specification looking for errors in content
2. Interpretation, areas where clarification may be required
3. Missing information
4. Inconsistencies
5. Conflicting requirements
6. Unrealistic (unachievable) requirements.
 Negotiation

• It isn’t unusual for customers and users to ask for more than can be achieved,
given limited business resources.
• It’s also relatively common for different customers or users to propose
conflicting requirements
• Arguing that their version is “essential for our special needs.”
• Settlement of these conflicts through a process of negotiation.
• Customers, users, and other stakeholders are asked to rank requirements and
then discuss conflicts in priority.
• Using an iterative approach that prioritizes requirements, assesses their
cost and risk, and addresses internal conflicts, requirements are eliminated,
combined, and/or modified so that each party achieves some measure of
satisfaction.
 (Kano diagram) – Real life application case study

•The Kano Model is an analysis tool to explore and measure customer needs.
• It's a way to identify the basic needs of customers, as well as performance
and excitement requirements.
• The Kano model is a theory for product development and customer
satisfaction developed which classifies customer preferences into five
categories.
The Kano model offers some insight into the product attributes which are
perceived to be important to customers.

The purpose of the tool is to support product specification and discussion

through better development of team understanding.

1. Must-be Quality: Simply stated, these are the requirements that the
customers expect and are taken for granted.
• When done well, customers are just neutral, but when done poorly,
customers are very dissatisfied.
• Kano originally called these “Must-be’s” because they are the
requirements that must be included and are the price of entry into a
market.
Examples: In a hotel, providing a clean room is a basic necessity. In a call
center, greeting customers is a basic necessity.
2. One-dimensional Quality: (MUST) These attributes result in satisfaction
when fulfilled and dissatisfaction when not fulfilled.
These are attributes that are spoken and the ones in which companies
compete.
An example of this would be a milk package that is said to have ten percent
more milk for the same price will result in customer satisfaction, but if it only
contains six percent then the customer will feel dissatisfaction.
Examples: 1. Time taken to resolve a customer's issue in a call center.
2. Waiting service at a hotel.

3. Attractive Quality: These attributes provide satisfaction when achieved fully,

but do not cause dissatisfaction when not fulfilled. These are attributes that
are not normally expected.
For example, a thermometer on a package of milk showing the temperature
of the milk. Since these types of attributes of quality unexpectedly delight
customers, they are often unspoken.
Examples: 1. In a call center, providing special offers and compensations to
customers or the proactive escalation and instant resolution of their issue is
an attractive feature.
2. In a hotel, providing free food is an attractive feature.
4. Indifferent Quality: These attributes refer to aspects that are neither good
nor bad, and they do not result in either customer satisfaction or
customer dissatisfaction.
For example, thickness of the wax coating on a milk carton box. This might
be key to the design and manufacturing of the carton, but consumers are
not even aware of the distinction. It is interesting to identify these
attributes in the product in order to suppress them and therefore diminish
production costs
Examples: In a call-center, highly polite speaking and very prompt
responses might not be necessary to satisfy customers and might not be
appreciated by them. The same applies to hotels.
5. Reverse Quality: These attributes refer to a high degree of achievement
resulting in dissatisfaction and to the fact that not all customers are alike.
For example, some customers prefer high-tech products, while others
prefer the basic model of a product and will be dissatisfied if a product has
too many extra features

Video Link:
https://youtu.be/E_LkqbyZxpg?si=_F9SvknignoZC6MN
https://youtu.be/qAlPJUYByNk?si=mdx-i3ztnM0m0_qe
 Requirements Analysis: Basics

Requirements analysis results in ..

1. the specification of software’s operational characteristics,
2. indicates software’s interface with other system elements, and
3. establishes constraints that software must meet

Requirements analysis allows you to elaborate on basic

requirements established during the inception, elicitation, and
negotiation.

Def: Actors are those individuals or systems that will interact with
the application.

Def: Use cases are series of steps or related interactions that are
performed by an “Actor” on the system in order to complete a goal.
The requirements modeling action results in one or more of the
following types of models:

1. Scenario-based models of requirements from the point of view

of various system “actors”.

2. Data models that depict the information domain for the problem.

3. Class-oriented models that represent object-oriented classes

(attributes and operations) and the manner in which classes
collaborate to achieve system requirements.

4. Flow-oriented models that represent the functional elements of

the system and how they transform data as it moves through the
system.
5. Behavioral models that depict how the software behaves as a
consequence of external “events”.
These models provide a software designer with information that
can be translated to architectural, interface, and component-level
designs.

Finally, the requirements model provides the developer and the

customer with the means to assess quality once software is built.
 SCENARIO BASED MODELING
•Although the success of a computer-based system or product is measured in
many ways, the user satisfaction resides at the top of the list.

•The system is described from the user’s point of view using a scenario-based
approach.
•If you understand how end users want to interact with a system, your software
team will be better able to properly characterize requirements.
•And also will be able to build meaningful analysis and design models.

To illustrate, consider the function access camera surveillance via the Internet—
display camera views (ACS-DCV).

The stakeholder is the homeowner actor might write the following narrative:

Use case: Access camera surveillance via the Internet—display camera views
(ACS-DCV)
Actor: homeowner.

Hence, requirements modeling begins with the creation of scenarios in the form
of use cases……as follows..
 1. Creating a Preliminary Use Case
• The “contract” defines the way in which an actor uses a computer-based
system to accomplish some goal.

• A “use case” describes a specific usage scenario in straightforward language

from the point of view of a defined actor.

• These are the questions that must be answered for designing a faithful
model
• (1) what to write about,
• (2) how much to write about it,
• (3) how detailed to make your description, and
• (4) how to organize the description?
 2. Refining a Preliminary Use Case

•A description of alternative interactions is essential for a complete

understanding of the function that is being described by a use case.

•Therefore, each step in the primary scenario is evaluated by asking the following
questions:
• Can the actor take some other action at this point?
• Is it possible that the actor will encounter some error condition at this
point?
If so, what might it be?
• Is it possible that the actor will encounter some other behavior at this point
(e.g., behavior that is invoked by some event outside the actor’s control)?
If so, what might it be?
Answers to these questions result in the creation of a set of secondary scenarios.
 3. Writing a Formal Use Case

The informal use cases are sometimes sufficient for requirements modeling.

NEED of UML Unified Modeling Language..

However, when a use case describes a complex set of steps with a significant
number of exceptions, a more formal approach may be desirable.

In many cases, there is no need to create a graphical representation of a usage

scenario.
However, diagrammatic representation can facilitate understanding,
particularly when the scenario is complex.

The UML (Unified Modeling Language) provide use-case diagramming

capability.
 Outline
 What is UML and why we use UML?
 How to use UML diagrams to design
software system?
 What UML Modeling tools we use today?

 https://youtu.be/WnMQ8HlmeXc?si=FUBU
wItIiNk_kvsv
What is UML and Why we use UML?
 UML → “Unified Modeling Language”
 Language: express idea, not a methodology

 Modeling: Describing a software system at a high

level of abstraction

 Unified: UML has become a world standard

Object Management Group (OMG): www.omg.org
What is UML and Why we use UML?
 More description about UML:
 It is a industry-standard graphical language for specifying, visualizing,
constructing, and documenting the artifacts of software systems

 The UML uses mostly graphical notations to express the OO analysis

and design of software projects.

 Simplifies the complex process of software design

What is UML and Why we use UML?
 Why we use UML?
 Use graphical notation: more clearly than natural language
(imprecise) and code (too detailed).

 Help acquire an overall view of a system.

 UML is not dependent on any one language or technology.

 UML moves us from fragmentation to standardization.

What is UML and Why we use UML?
Year Version
2003: UML 2.0
2001: UML 1.4
1999: UML 1.3
1997: UML 1.0, 1.1
1996: UML 0.9 & 0.91
1995: Unified Method 0.8

Booch ‘93 OMT - 2

Other methods

Booch ‘91
OMT - 1
How to use UML diagrams to
design software system?
 Types of UML Diagrams:
 Use Case Diagram
 Class Diagram
 Sequence Diagram
 Collaboration Diagram
 State Diagram

This is only a subset of diagrams … but are most widely used

Use-Case Diagrams
 A use-case diagram is a set of use cases
 A use case is a model of the interaction between
 External users of a software product (actors) and
 The software product itself
 More precisely, an actor is a user playing a specific role

 describing a set of user scenarios

 capturing user requirements
 contract between end user and software developers
 Use-Case Diagrams
Boundary Use Case
Actor Library System

Borrow Employee
Client

Order Title

Fine Remittance

Supervisor
 Use-Case Diagrams
 Actors: A role that a user plays with respect to the system, including human
users and other systems. e.g., inanimate physical objects (e.g. robot); an
external system that needs some information from the current system.

 Use case: A set of scenarios that describing an interaction between a user

and a system, including alternatives.

 System boundary: rectangle diagram representing the boundary between

the actors and the system.
Use-Case Diagrams
 Association:
communication between an actor and a use case; Represented by a solid line.

 Generalization: relationship between one general use case and a special use
case (used for defining special alternatives) Represented by a line with a
triangular arrow head toward the parent use case.
Use-Case Diagrams
Include: a dotted line labeled <<include>> beginning at base
use case and ending with an arrows pointing to the include use
case. The include relationship occurs when a chunk of
behavior is similar across more than one use case. Use
“include” in stead of copying the description of that behavior.
<<include>>

Extend: a dotted line labeled <<extend>> with an arrow toward

the base case. The extending use case may add behavior to the
base use case. The base class declares “extension points”.

<<extend>>
Use-Case Diagrams

Figure 16.12
The McGraw-Hill Companies, 2005
Use-Case Diagrams
 Both Make Appointment
and Request Medication
include Check Patient
Record as a subtask
(include)

 The extension point is

written inside the base
case Pay bill; the
extending class Defer
payment adds the
behavior of this extension
point. (extend)

 Pay Bill is a parent use

case and Bill Insurance
is the child use case.
(generalization)

(TogetherSoft, Inc)
Class diagram
 A class diagram depicts classes and their interrelationships

 Used for describing structure and behavior in the use cases

 Provide a conceptual model of the system in terms of

entities and their relationships

 Used for requirement capture, end-user interaction

 Detailed class diagrams are used for developers

Class diagram
 Each class is represented by a rectangle subdivided into three
compartments
 Name
 Attributes
 Operations

 Modifiers are used to indicate visibility of attributes and

operations.
 ‘+’ is used to denote Public visibility (everyone)
 ‘#’ is used to denote Protected visibility (friends and derived)
 ‘-’ is used to denote Private visibility (no one)

 By default, attributes are hidden and operations are visible.

Class diagram
Name
Account_Name
- Customer_Name
Attributes
- Balance
+addFunds( ) Operations
+withDraw( )
+transfer( )
OO Relationships
 There are two kinds of Relationships
 Generalization (parent-child relationship)
 Association (student enrolls in course)

 Associations can be further classified as

 Aggregation
 Composition
 OO Relationships: Generalization

Example:
Supertype Customer

Regular Loyalty
Customer Customer

Subtype1 Subtype2
-Inheritance is a required feature of object orientation
-Generalization expresses a parent/child relationship among related classes.

-Used for abstracting details in several layers

 OO Relationships: Association

 Represent relationship between instances of classes

 Student enrolls in a course
 Courses have students
 Courses have exams
 Etc.

 Association has two ends

 Role names (e.g. enrolls)
 Multiplicity (e.g. One course can have many students)
 Navigability (unidirectional, bidirectional)
 Association: Multiplicity and Roles
student
1 *
University Person

0..1 *
employer teacher

Multiplicity Role
Symbol Meaning
1 One and only one Role
0..1 Zero or one “A given university groups many people;
M..N From M to N (natural some act as students, others as teachers.
language) A given student belongs to a single
* From zero to any positive university; a given teacher may or may not
integer be working for the university at a particular
0..* From zero to any positive time.”
integer
1..* From one to any positive
integer
Class diagram

[from UML Distilled Third Edition]

Association: Model to Implementation

* 4
Student Course
has enrolls

Class Student {
Course enrolls[4];
}

Class Course {
Student have[];
}
 OO Relationships: Composition

Whole Class
Class W Association
Models the part–whole relationship

Composition
Class P1 Class P2 Also models the part–whole relationship but, in
addition, Every part may belong to only one
whole, and If the whole is deleted, so are the
Part Classes parts
[From Dr.David A. Workman]
Example Example:
A number of different chess boards: Each square
belongs to only one board. If a chess board is
thrown away, all 64 squares on that board go as
well.

Figure 16.7
The McGraw-Hill Companies, 2005
 OO Relationships: Aggregation

Container Class
Aggregation:
Class C expresses a relationship among instances of related
classes. It is a specific kind of Container-Containee
AGGREGATION
relationship.

Class E1 Class E2 express a more informal relationship than

composition expresses.

Containee Classes Aggregation is appropriate when Container and

Containees have no special access privileges to
each other.
Example
Bag

Apples Milk

[From Dr.David A. Workman]

Aggregation vs. Composition
 Composition is really a strong form of association
 components have only one owner
 components cannot exist independent of their owner
 components live or die with their owner
 e.g. Each car has an engine that can not be shared with other cars.

 Aggregations
may form "part of" the association, but may not be essential to it. They
may also exist independent of the aggregate. e.g. Apples may exist
independent of the bag.
Good Practice: CRC Card
Class Responsibility Collaborator
 easy to describe how classes work by moving cards around; allows to
quickly consider alternatives.
Interaction Diagrams
 show how objects interact with one another

 UML supports two types of interaction

diagrams
 Sequence diagrams
 Collaboration diagrams
Sequence Diagram(make a phone call)
Caller Phone Recipient

Picks up

Dial tone

Dial

Ring notification Ring

Picks up

Hello
Sequence Diagram:Object interaction
A B
Self-Call: A message that an
Synchronous
Object sends to itself.

Condition: indicates when a Asynchronous

message is sent. The message is
Transmission
sent only if the condition is true. delayed

[condition] remove()
Condition
*[for each] remove()
Iteration

Self-Call
 Sequence Diagrams – Object Life Spans
 Creation
A
 Create message

 Object life starts at that point

Create
 Activation B
 Symbolized by rectangular stripes

 Place on the lifeline where object

is activated.
 Rectangle also denotes when

object is deactivated.
 Deletion Activation bar
X
Return
 Placing an ‘X’ on lifeline Deletion
 Object’s life ends at that point
Lifeline
 Sequence Diagram
Us er
Message Catalog Res ervations

•Sequence diagrams demonstrate the

behavior of objects in a use case by 1: look up ()

describing the objects and the 2: title data ()

messages they pass.
3: [not available] res erve title ()

•The horizontal dimension shows the 4 : title returned ()

objects participating in the interaction. 5: hold title ()

5 : title available ()

•The vertical arrangement of

6 : borrow title ()
messages indicates their order.
6 : rem ove res ervation ()

•The labels may contain the seq. # to

indicate concurrency.
 Interaction Diagrams: Collaboration diagrams

start

6: remove reservation

3 : [not available] reserve title

User Reservations

5: title available
6 : borrow title
1: look up
2: title data

4 : title returned
Catalog

5 : hold title
Collaboration diagrams are equivalent to sequence diagrams. All the features of sequence
diagrams are equally applicable to collaboration diagrams

Use a sequence diagram when the transfer of information is the focus of attention

Use a collaboration diagram when concentrating on the classes

 State Diagrams (Billing Example)

State Diagrams show the sequences of states an object goes through

during its life cycle in response to stimuli, together with its responses and
actions; an abstraction of all possible behaviors.

Start End
Unpaid Paid
Invoice created payin Invoice destroying
g
State Diagrams (Traffic light example)

Traffic Light Start

State
Transition Red

Yellow

Green

Event
What UML Modeling tools we use today?
 List of UML tools http://en.wikipedia.org/wiki/List_of_UML_tools

 ArgoUML: http://argouml.tigris.org/

 Rational Rose (www.rational.com) by IBM

 UML Studio 7.1 ( http://www.pragsoft.com/) by Pragsoft Corporation:

Capable of handling very large models (tens of thousands of classes).
Educational License US$ 125.00; Freeware version.

 TogetherSoft Control Center; TogetherSoft Solo (

http://www.borland.com/together/index.html) by Borland
Conclusion
 UML is a standardized specification language
for object modeling
 Several UML diagrams:
 use-case diagram: a number of use cases (use case models the interaction
between actors and software)
 Class diagram: a model of classes showing the static relationships among them
including association and generalization.
 Sequence diagram: shows the way objects interact with one another as
messages are passed between them. Dynamic model
 State diagram: shows states, events that cause transitions between states.
Another dynamic model reflecting the behavior of objects and how they react to
specific event
 There are several UML tools available
 UML models: use case diagram and class diagram

An object-oriented analysis and design language from the Object Management

Group (OMG). There are twelve diagrams supported under UML. Four are
structural, five are behavioral and three are used for model management,
which include packages, subsystems and models.

The Unified Modeling Language™ (UML®) helps you specify, visualize, and
document models of software systems, including their structure and design, in
a way that meets all of these requirements.

UML MODELS:

If the requirements are not clear and consise then in such cases, you can
choose from a broad array of UML graphical models.

1. Developing an Activity Diagram

The UML activity diagram supplements provides a graphical representation of
the flow of interaction within a specific scenario.
An activity diagram for the ACS-DCV use case is shown in Figure 6.5.
Access camera surveillance via the Internet—display camera views
Activity diagram for Access
camera surveillance via the
Internet display
camera views function.

It should be noted that the

Activity diagram adds
additional detail not
directly mentioned by
the use case.

For example, a user may only

attempt to enter userID and
password a limited number
of times.

This is represented by a
decision diamond below
“Prompt for reentry.”
 2. Swimlane Diagrams
The UML (Unified Modeling Language) swimlane diagram is a useful modification
of the activity diagram.

It allows you to represent the flow of activities described by the use case.
And at the same time, it indicate which actor or analysis class has responsibility
for the action described by an activity rectangle.

Responsibilities are represented as parallel segments that divide the diagram

vertically, like the lanes in a swimming pool.

Three analysis classes—Homeowner, Camera, and Interface—have direct or

indirect.

Referring to Figure 6.6, the activity diagram is rearranged so that activities

associated with a particular analysis class fall inside the swimlane for that class.

The activity diagram notes two prompts that are the responsibility of the
interface—“prompt for reentry” and “prompt for another view.”
Referring to Figure 6.6, the activity Fig 6.6. -Swimlane diagram for Access camera
diagram is rearranged so that activities surveillance via the Internet—display camera
associated with a particular analysis views function
class fall inside the swimlane for that
class.

These prompts and the decisions

associated with them fall within the
Interface swimlane.

However, arrows lead from that

swimlane back to the Homeowner
swimlane, where homeowner actions
occur.
Use cases, along with the activity and
swimlane diagrams, are procedurally
oriented.

They represent the manner in which

various actors invoke specific functions
to meet the requirements of the system.
 Data modeling
•A software engineer or analyst defines all data objects that are processed within
the system, the relationships between the data objects, and other information
that is relevant to the relationships.
1. Data Objects:
A data object is a representation of composite information that must be
understood by software.
Composite information has a number of different properties or attributes.
e.g. the width (a single value) would not be a valid data object, but dimensions
(incorporating height, width, and depth) could be defined as an object.

A data object can be

an external entity (e.g., anything that produces or consumes
information),
a thing (e.g., a report or a display),
an occurrence (e.g., a telephone call) or
an event (e.g., an alarm),
a role (e.g., salesperson),
an organizational unit (e.g., accounting department),
a place (e.g., a warehouse), or
a structure (e.g., a file).
The data in the specifications are of various types.

e.g. In this case, a car is defined in terms of make, model, ID number, body
type, color, and owner.

2. Data Attributes (Quality)

Data attributes define the properties of a data object and take on one of three
different characteristics.

They can be used to

(1) name an instance of the data object,

(2) Describe the instance, or
(3) make reference to another instance in another table.

In addition, one or more of the attributes called “key” must be defined as an

identifier if we want to find an instance of the data object.

In some cases, values for the identifier(s) are unique, although this is not a
requirement.
e.g.

Referring to the data object car, a reasonable identifier might be the ID number.

The set of attributes that is appropriate for a given data object is determined
through an understanding of the problem context.
3 Relationships
Data objects are connected to one another in different ways.
Consider the two data objects, person and car.
These objects can be represented using the simple notation illustrated in Figure
6.8a.

Fig.
Relationships between data
objects
e.g.
•A person owns a car.
• A person is insured to drive a car

A connection is established between person and car because the two objects are
related.
But what are the relationships?
To determine the answer, you should understand the role of people and cars
within the context of the software to be built.
You can establish a set of object/ relationship pairs that define the relevant
relationships.
We have seen 1. scenario based modeling 2. Data modeling….
And now…Class based modeling ..

Class-based elements
•Each usage scenario implies a set of objects that are manipulated as an actor
which interacts with the system.

These objects are categorized into classes—

1. a collection of things that have similar attributes and
2. common behaviors. 5.4 Class diagram for sensor
e.g., a UML class diagram can be used to
depict a sensor class for the
Safe Home security function (Figure 5.4).

Note that the diagram lists the attributes

of sensors (e.g., name, type) and the
operations (e.g., identify, enable) that can
be applied to modify these attributes.
 CLASS-BASED MODELING

•Class-based modeling represents the objects that

1. the system will manipulate,
2. the operations that will be applied to the objects to effect the
manipulation,
3. relationships between the objects, and
4. the collaborations that occur between the classes that are
defined.

• The elements of a class-based model include classes and objects, attributes,

operations, class responsibility-collaborator (CRC) models, collaboration
diagrams, and packages:

• To discuss class based modeling, the following points are considered:

• 1 Identifying Analysis Classes
• 2 Specifying Attributes
• 3 Defining Operations
• 4 Class-Responsibility-Collaborator (CRC) Modeling
• 5 Associations and Dependencies
• 6 Analysis Packages
 1. Identifying Analysis Classes
Analysis classes are expressed in one of the following ways:

• External entities (e.g., other systems, devices, people) that produce or

consume information to be used by a computer-based system.

• Things (e.g., reports, displays, letters, signals) that are part of the information
domain for the problem.

• Occurrences or events (e.g., a property transfer or the completion of a series

of robot movements) that occur within the context of system operation.

• Roles (e.g., manager, engineer, salesperson) played by people who interact

with the system.

• Organizational units (e.g., division, group, team) that are relevant to an

application.
• Places (e.g., manufacturing floor or loading dock) that establish the context of
the problem and the overall function of the system.

• Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a

class of objects or related classes of objects.
 2. Specifying Attributes (Qualities)

Attributes describe a class that has been selected for inclusion in the
requirements model.

For example,

1. if we were to build a system that tracks baseball statistics for professional

baseball players.

Here, the attributes such as name, position, batting average, fielding

percentage, years played, and games played might be relevant

2. But in the context of the professional baseball pension system…

attributes like average salary, credit toward full vesting, pension plan
options chosen, mailing address etc.
 3. Defining Operations

•Operations define the behavior of an object.

•Although many different types of operations exist, they can generally be

divided into four broad categories:

(1) operations that manipulate data in some way (e.g., adding, deleting,
reformatting, selecting),
(2) operations that perform a computation,
(3) operations that inquire about the state of an object, and
(4) operations that monitor an object for the occurrence of a controlling event.

These functions are accomplished by operating on attributes and/or

associations .

Therefore, an operation must have “knowledge” of the nature of the class’

attributes and associations.
 Requirement Specification

A specification can be
• a written document
• a graphical model
• a formal mathematical model
• a collection of usage scenarios
• a prototype
• or any combination of these.
 4. System Modeling

• blue print or 3D design of the system based on

the specification

• by knowing all system specification one can

render a system to get a look and feel of the
system before actual development
 5.Requirement Validation
Requirements validation examines the specification to ensure that
• All system requirements have been stated unambiguously
• Inconsistencies, omissions, and errors have been detected and
corrected
• The primary requirements validation mechanism is the formal
technical review
• The review team includes system engineers, customers, users,
and other stakeholders who examine the system specification

- Looking for errors in content or interpretation

- Areas where clarification may be required, missing information,
inconsistencies
- Conflicting requirements, or unrealistic requirements.
 Software Requirement Specifications [SRS]

• SRS is a formal document , which acts as a

representation of software that enables the customers to
review whether it (SRS) is according to their need

• This document lays a foundation for software

engineering activities.

• SRS documents must be

- Concise
- Structured
- Black box view
Characteristics of good SRS
 Characteristics of good SRS
• Correctness: Accuracy of the requirement

• Completeness: Cover all the parameters that are truly expected by

system e.g functionality, design, figures, tables, interfaces etc.

• Consistency : No conflicts between the subset of requirements, no

frequent changes

• Unambiguous: Only one interpretation

• Prioritization : Can be arranged on priority

• Modifiability : SRS should be made as modifiable as likely and

should be capable of quickly obtain changes to the system to some
extent. Modifications should be perfectly indexed and cross-referenced
 Characteristics of good SRS
• Verifiability: can be verified for its correctness and
effectiveness
• Traceability: The SRS is traceable if the origin of each
of the requirements is clear and if it facilitates the
referencing of each condition in future development or
enhancement documentation
- Forward Traceability
- Backward Traceability
• Testability:
An SRS should be written in such a method that it is
simple to generate test cases and test plans from the report.
• Design Independence: There should be an option to
select from multiple design alternatives for the final
system. More specifically, the SRS should not contain
any implementation details.

• Understandable by the customer: avoid technical

notations and symbols if possible, use simple
language

• The right level of abstraction: Blend of explicit and

implicit
Requirement Analysis
 Steps in the Requirement Analysis
 Draw Context Diagram :
 Development of a Prototype (optional):
 Model the requirements:
 Finalize the requirements:
 Types of Requirements
 Functional Requirements
• Basic facilities that the system should offer
• All functionalities need to be necessarily incorporated into the
system as a part of the contract
• These are represented or stated in the form of input to be given
to the system, the operation performed and the output expected
Examples:
1. Authentication of user whenever he/she logs into the system.
2. System shutdown in case of a cyber attack.
3. A Verification email is sent to user whenever he/she registers
for the first time on some software system.
 Types of Requirements cont.…
 Non Functional Requirements
• These are basically the quality constraints that the system
must satisfy according to the project contract.
• The priority or extent to which these factors are
implemented varies from one project to other.
• They are also called non-behavioral requirements.
• These requirements are often more critical than the
functional requirements

Examples:
Portability, Security, Maintainability, Reliability, Scalability,
Performance, Reusability, Flexibility
 Functional v/s Non -Functional
Sr. No. Functional Requirements Non -Functional Requirements
1. A functional requirement defines A non-functional requirement defines the
a system or its component. quality attribute of a software system.

2. It specifies “What should the It places constraints on “How should the

software system do? software system fulfill the functional
requirements?”

3. It is specified by the User. It is specified by technical peoples e.g.

Architect, Technical leaders and software
developers.

4. It is captured in use case It is captured as a quality attribute.

5. Defined at a component level. Defined to a system as a whole.
6. Functional Testing like System, Non-Functional Testing like Performance,
Integration, End to End, API etc. Stress, Usability, Security testing etc. are
testing are performed performed

7. Easy to define Comparatively difficult to define

Requirement Engineering
End of Unit II
THANK YOU