Unit-II

Software Requirements
Software Requirements
 Introduction to Functional and Non-Functional Requirements
 Requirements Engineering Activities
 Eliciting Requirements
 Requirements Modeling
 Requirements Validation
 Software Requirements Specification (SRS) Document
 Requirements Management
 Requirements Modeling
Functional and Non-Functional Requirements
 Functional Requirements:
 * These are statements of services the system should provide
 => how the system should react to particular inputs and
 => how the system should behave in particular situations
 * In some cases, the functional requirements may also explicitly state
 => What the system should not do
 * The functional requirements definition of a system should be both
 => Complete [i.e. It means that all services required by the user should be
 Defined ]
 => Consistent [i.e. it means that requirements should not have
 contradictory definitions ]
Functional and Non-Functional Requirements
 Non – Functional Requirements:
 * These are constraints on the services (Or) functions offered by the
system
 * They include
 => Timing Constraints
 => Constraint on development process
 => Standards and so on…
 (i)Product Requirements:
 * These requirements results from the need for the
delivered product, to behave in a particular way
 Example:
 * Requirements on how fast the system must
execute and how much memory it requires
 * Reliability Requirements [i.e. acceptable failure
rate]
 Portability Requirements
 (ii)
Organizational Requirements:
 * These requirements are consequence of
organizational policies and procedures
 Example:
 * Implementation requirements such as
programming language (Or) design method used
 * Delivery Requirements which specify when the
product and its documentation to be delivered
 (iii) External Requirements:
 * This requirements arise from factors external to
the system and its development process
 Example:
* Interoperability Requirements which specify how
the system interacts with systems in other
organizations
* Legislative Requirements, which ensure that the
system operates within the law
 Requirements engineering processes
 Requirements Elicitation
 Requirements Specification
 Requirements Validation
 System Requirements Document
Requirements elicitation and analysis
 Requirements Discovery
 Requirements classification and organization
 Requirements prioritization and negotiation
 Requirements specification
Requirements elicitation and analysis
 Interviewing is the one of the Method to gather requirements

 Interviews may be of two types:

 1. Closed interviews, where the stakeholder answers a pre-defined set
of questions.
 2. Open interviews, in which there is no pre-defined agenda. The
requirements engineering team explores a range of issues with
Requirements validation
 Verification is to check whether the software conforms to specifications.
 Validation is to check whether software meets the customer expectations
and requirements.
 Requirements validation is the process of checking that requirements
actually define the system that the customer really wants.
 1. Validity checks
 2. Consistency checks
 3. Completeness checks
 4. Realism checks
 5. Verifiability
Requirements management
 Requirements management planning : Planning is an essential first stage
in the requirements management process. The planning stage establishes
the level of requirements management detail that is required.

 1. Requirements identification
 2. A change management process
 3. Traceability policies
 4. Tool support
Software Requirements Specification(SRS)
 Check the Word Document….
Requirements analysis

 Specifies software’s operational characteristics

 Indicates software's interface with other system
elements
 Establishes constraints that software must meet 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.
Analysis Phase: What is it?
Software, system
hardware, description

data, human
elements analysis
model
Software
design application
model
architecture,
user interface,
component-
level structure
Three objectives of requirements:
• To describe what the customer requires
• To establish a basis for the creation of a
software design
• To define a set of requirements that can be
validated once the software is built
Coming up: Elements of the Analysis
Model 15
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 nonfunctional
models until design.
 Be certain that the analysis model provides value to all
stakeholders.
 Keep the model as simple as it can be.
Domain Analysis
Define the domain to be investigated.
Collect a representative sample of
applications in the domain.
Analyze each application in the
sample.
Develop an analysis model for the
objects.
Requirements Analysis
Results in models:
1. Scenario-based models
2. Data models (information domain for the
problem)
3. Class-oriented models
4. Flow-oriented models
5. Behavioral models (how the software
behaves according to external events)
 Elements of the Analysis Model

Scenario-based
elements Flow-oriented
Use-case elements
diagrams
Data-flow
Use cases - text diagrams
Activity Diagrams Control flow
Swim lane diagrams
diagrams Analysis Processing
Model narratives
Class-based
Classelements
diagrams Behavioral
elements
State diagrams
Analysis Packages
Sequence
CRC Models diagrams
Collaboration
Diagrams
ER Diagrams
Coming up: Elements of the Analysis
Model 19
Scenario-Based Modeling

 If you understand how end users (and other actors) want

to interact with a system, your software team will be
better able to properly characterize requirements and
build meaningful analysis and design models.

 (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

stakeholder’s 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
Actors represent roles people or
devices play as the system
functions
Users can play a number of
different roles for a given scenario
Developing a Use-Case
What are the main tasks or functions that
are performed by the actor?
What system information will the actor
acquire, produce or change?
Will the actor have to inform the system
about changes in the external environment?
What information does the actor desire from
the system?
Does the actor wish to be informed about
unexpected changes?
Use-Case Diagram
Class-Based Modeling
 Class-based modeling represents:
 Objects that the system will manipulate
 Operations (also called methods or services) that
will be applied to the objects to effect the
manipulation
 Relationships (some hierarchical) between the
objects
 Collaborations that occur between the classes that
are defined.
 The elements of a class-based model include
classes and objects, attributes, operations, and
collaboration diagrams.
Typical Classes (a reminder)
 External entities - printer, user, sensor
 Things - reports, displays, signals
 Occurrences or events (e.g., interrupt, alarm)
 Roles (e.g., manager, engineer, salesperson)
 Organizational units (e.g., division, team)
 Places (e.g., manufacturing floor or loading dock)
 Structures (e.g., sensors, four-wheeled vehicles, or computers)

But, how do we select classes?

Coming up: Selecting Classes—Criteria 43

 Selecting Classes—Criteria
retained information – information about it must be remembered
needed services – operations that change the attributes
multiple attributes – if it is only one attribute,
probably should be part of another class
common attributes – common things for all instances of a class
common operations – for all instances of the class
essential requirements – appear in the PROBLEM space
(remember we’re doing analysis modeling!)

Coming up: Selecting Classes—

Example 44
Selecting Classes—
Example ATMUse
r
PinNum

retained information Yes

Yes
needed services No
Yes
multiple attributes
No
Yes
common attributes Yes
Yes
common operations Maybe
Yes
essential requirements
Yes
Yes

Coming up: CRC Cards 45

Elements of the Analysis Model
Scenario-based
elements Flow-oriented
Use-case elements
diagrams
Data-flow
Use cases - text diagrams
Activity Diagrams Control flow
Swim lane diagrams
diagrams Analysis Processing
Model narratives

Class-based
Classelements
diagrams Behavioral
State diagrams
elements
Analysis Packages
Sequence
CRC Models diagrams
Collaboration
Diagrams
ER Diagrams

Coming up: The ERD: An Example 48

The ERD: An Example
places request
Customer
for service

standard generates work

task table order
(1,1)
selected work consists
from tasks of

lists
materials

Coming up: Data Modeling 49

Data Modeling
Examines data objects independently
of processing
Focuses attention on the data domain
Creates a model at the
customer’s level of abstraction
Indicates how data objects relate to
one another

Coming up: What is a Data Object? 50

What is a Data Object?

Object —something that is described by a set

of attributes (data items) and that will be
manipulated within the software (system)
each instance of an object (e.g., a book)
can be identified uniquely (e.g., ISBN #)
each plays a necessary role in the system
i.e., the system could not function without
access to instances of the object
each is described by attributes that are
themselves data items

What are some typical data objects?

Coming up: Typical Data Objects 51

Data Objects and Attributes
A data object contains a set of attributes that
act as an aspect, quality, characteristic, or
descriptor of the object
object: automobile
attributes:
make
model
body type
price
options code

How do data objects differ from OO classes or do they?

Coming up: What is a Relationship? 52

 What is a Relationship?
relationship —indicates “connectedness”;
a "fact" that must be "remembered"
by the system and cannot or is not computed
or derived mechanically

 several instances of a relationship can exist

 objects can be related in many different ways

Coming up: Crow’s Foot Style ERD 53

ERD Example: From http://www.b2ttraining.com

Coming up: Elements of the Analysis

Model 54
Elements of the Analysis Model
Scenario-based Onward to data flow
elements diagrams!
Flow-oriented
Use-case elements
diagrams
Data-flow
Use cases - text diagrams
Activity Diagrams Control flow
Swim lane diagrams
diagrams Analysis Processing
Model narratives

Class-based
Classelements
diagrams Behavioral
State diagrams
elements
Analysis Packages
Sequence
CRC Models diagrams
Collaboration
Diagrams

Coming up: Flow-Oriented Modeling 55

Flow-Oriented Modeling
•Represents how data objects are transformed at they
move through the system

•A data flow diagram (DFD) is the diagrammatic form that

is used to show how data is transformed as it moves
through the system

•Considered by many to be an ‘old school’ approach,

flow-oriented modeling continues to provide a view of the
system that is unique—it should be used to supplement
other analysis model elements

Coming up: The Flow Model 56

The Flow Model
Every computer-based system is an
information transform ....

computer
data input based output
system

Coming up: Flow Modeling Notation 57

Flow Modeling Notation

external entity

process

data flow

data store

Coming up: External Entity 58

External Entity
A producer or consumer of data

Examples: a person, a device, a sensor

Data must always originate somewhere

and must always be sent to something

Coming up: Process 59

Process
A data transformer (changes input
to output)

Examples: compute taxes, determine area,

format report, display graph
Data must always be processed in some
way to achieve system function

Coming up: Data Flow 60

Data Flow

Data flows through a system, beginning

as input and be transformed into output.
base
compute
area
triangle
height area

Key thought: In a DFD the DATA is what is moving on the

arrows!

Coming up: Data Stores 61

Data Stores
Data is often stored for later use.

sensor #
sensor #, type,
look-up location, age
sensor
report required data
type,
location, age
sensor number

sensor data

In a real system what things are “Data

Stores”?
Coming up: Data Flow Diagramming:
Guidelines 62
 Data Flow Diagramming:
Guidelines

 All icons must be labeled with

meaningful names
 The DFD evolves through a number of levels of detail
 Always begin with a context level diagram (also called
level 0)
 Always show external entities at level 0
 Always label data flow arrows
 Do not represent procedural logic
 Ensure that you show DATA moving through the system
(not control)

Coming up: Constructing a DFD—I 63

Constructing a DFD—I
review the data model to isolate data
objects and use a grammatical parse to
determine “operations”
determine external entities (producers
and consumers of data)
create a level 0 DFD

Coming up: Level 0 DFD Examples 64

Level 0 DFD Examples
processing
user request requested
video
digital signal
video monitor
processor
video
source NTSC
video signal

Coming up: Constructing a DFD—II 65

The Data Flow Hierarchy

a b
x P y level 0

a c p2
p1
f

d p4 5 b
p3 e g
level 1

Coming up: Example DFD: Level 1 66

Example DFD: Level 1

Coming up: DFD: A practical example 67

DFD Example

 Example from
http://ldtconsultinginc.com/

 Can we add labels to unlabled

data flows?

 Is this a level 0 diagram?

Coming up: Lets Try It 68

 Flow Modeling Notes

 Each bubble is refined until it does just one thing

 The expansion ratio decreases as the number of levels
increase
 Most systems require between 3 and 7 levels for an
adequate flow model
 A single data flow item (arrow) may be expanded as
levels increase (data dictionary provides information)
 The things that move on the arrows

are DATA!

Coming up: Elements of the Analysis

Model 69
Elements of the Analysis Model
Scenario-based
elements Flow-oriented
Use-case elements
diagrams
Data-flow
Use cases - text diagrams
Activity Diagrams Control flow
Swim lane diagrams
diagrams Analysis Processing
Model narratives
Oh behave!
Class-based
Classelements
diagrams Behavioral
State diagrams
elements
Analysis Packages
Sequence
CRC Models diagrams
Collaboration
Diagrams

Coming up: Behavioral Modeling 70

Behavioral Modeling
 The behavioral model indicates how
software will respond to external events.
o create the model, the analyst must perform the
following steps:
 Evaluate all use-cases to fully understand the sequence of
interaction within the system.
 Identify events that drive the interaction sequence and
understand how these events relate to specific objects.
 Create a sequence diagram for each use-case.
 Build a state diagram for the system.
 Review the behavioral model to verify accuracy and
consistency.

Coming up: State Representations 71

Behavioral Modeling
 Make a list of the different states of a system
(How does the system behave?)
 Indicate how the system makes a transition
from one state to another (How does the
system change state?)
 State diagram or Sequence diagram
represents the Behavioral modeling

Coming up: State Diagram - Lets Try It! 72

 State Representations

 Inthe context of behavioral modeling, two different

characterizations of states must be considered:
◦ the state of each class as the system performs its function and
◦ the state of the system as observed from the outside as the system
performs its function
What are some states for an ATM machine?
Washing machine? Cell phone?

Coming up: State Diagram for the

ControlPanel Class 73
The States of a System
 state—a set of observable circumstances
that characterizes the behavior of a
system at a given time
 state transition —the movement from one
state to another
 event —an occurrence that causes the
system to exhibit some predictable form
of behavior
 action —process that occurs as a
consequence of making a transition

Coming up: Behavioral Modeling 74

State Diagram for ATM

Coming up: State Diagram Details 75

Sequence Diagram
The sequence diagram represents the flow
of messages in the system and is also
termed as an event diagram.
It helps in envisioning several dynamic
scenarios.
It portrays the communication between
any two lifelines as a time-ordered
sequence of events, such that these
lifelines took part at the run time.
Lifeline
An individual participant in the sequence diagram is represented by
a lifeline. It is positioned at the top of the diagram.
Activation
It is represented by a thin rectangle on the
lifeline.
It describes that time period in which an
operation is performed by an element,
such that the top and the bottom of the
rectangle is associated with the initiation
and the completion time, each
respectively.
Sequence Diagram