GURU NANAK INSTITUTIONS TECHNICAL CAMPUS

(Autonomous)

SOFTWARE ENGINEERING
(22PC0AM03)
II B.TECH- SEM-1

UNIT-2
SOFTWARE REQUIREMENTS
By
G. Swarnalatha, Asst . Prof

D E P T. O F C S E
SOFTWARE REQUIREMENTS :
Functional and non-functional requirements, User requirements,
System Requirements, Interface specification, the software
requirements document.
REQUIREMENTS ENGINEERING PROCESS :
Feasibility studies, Requirements elicitation and analysis,
Requirements validation, Requirements management .
SYSTEM MODELS :
Context Models, Behavioral models, Data models, Object
models, structured methods.

D E P T. O F C S E
SOFTWARE REQUIREMENTS
IEEE defines Requirement as :
1. A condition or capability needed by a user to
solve a problem or achieve an objective

2. A condition or capability that must be met or

possessed by a system or a system component to
satisfy construct,standard, specification or formally
imposed document

3. A documented representation of a condition or

capability as in 1 or 2

D E P T. O F C S E
 SOFTWARE REQUIREMENTS
Encompasses both the User’s view of the requirements ( the
external view ) and the Developer’s view( inside
characteristics)
User’s Requirements
--Statements in a natural language plus diagram,
describing the services the system is expected to provide
and the constraints
System Requirements
--Describe the system’s function, services and
operational condition

D E P T. O F C S E
SOFTWARE REQUIREMENTS
System Functional Requirements
--Statement of services the system should provide
--Describe the behavior in particular situations
--Defines the system reaction to particular inputs
Nonfunctional Requirements
- Constraints on the services or functions offered by the system
--Include timing constraints, constraints on the development process
and standards
--Apply to system as a whole
Domain Requirements
--Requirements relate to specific application of the system
--Reflect characteristics and constraints of that system

D E P T. O F C S E
FUNCTIONAL REQUIREMENTS
Should be both complete and consistent
Completeness
-- All services required by the user should be defined
Consistent
--Requirements should not have contradictory
definition
Difficult to achieve completeness and consistency for
large system

D E P T. O F C S E
 NON-FUNCTIONAL REQUIREMENTS
Types of Non-functional Requirements

1.Product Requirements
-Specify product behavior
-Include the following
 Usability
 Efficiency
 Reliability
 Portability

D E P T. O F C S E
2.Organisational Requirements
--Derived from policies and procedures
--Include the following:
Delivery
Implementation
Standard

D E P T. O F C S E
3.External Requirements
-- Derived from factors external to the system
and its development process
--Includes the following
 Interoperability
 Ethical
 Legislative

D E P T. O F C S E
DIFFERENT TYPES OF NON-FUNCTIONAL
REQUIREMENTS
Non-functional
requirements

Product Organisational External

requirements requirements requirements

Efficiency Reliability Portability Interoperability Ethical

requirements requirements requirements requirements requirements

Usability Delivery Implementa tion Standards Legislative

requirements requirements requirements requirements requirements

Performance Space Privacy Safety

requirements requirements requirements requirements
D E P T. O F C S E
 PROBLEMS FACED USING THE
NATURAL LANGUAGE
1. Lack of clarity
-- Leads to misunderstanding because of
ambiguity of natural language
2. Confusion
-- Due to over flexibility, sometime difficult
to find whether requirements are same or distinct.
3. Amalgamation problem
-- Difficult to modularize natural language
requirements

D E P T. O F C S E
 STRUCTURED LANGUAGE SPECIFICATION

• Requirements are written in a standard way

• Ensures degree of uniformity
• Provide templates to specify system requirements
• Include control constructs and graphical highlighting
to partition the specification

D E P T. O F C S E
REQUIREMENTS ENGINEERING PROCESS
To create and maintain a system requirement document
The overall process includes four high level requirements
engineering sub-processes:
1.Feasibility study
--Concerned with assessing whether the system is useful
to the business
2.Elicitation and analysis
--Discovering requirements
3.Specifications
--Converting the requirements into a standard form
4.Validation
-- Checking that the requirements actually define the
system that the customer wants

D E P T. O F C S E
 THE REQUIREMENTS ENGINEERING PROCESS

Requirements
F easibility elicitation and
stud y anal ysis
Requir ements
specification
Feasibility Requir ements
r epor t validation

System
models

User and system

requirements

Requir ements
document

D E P T. O F C S E
SPIRAL REPRESENTATION OF REQUIREMENTS ENGINEERING
PROCESS

Process represented as three stage activity

Activities are organized as an iterative process around a spiral.
Early in the process, most effort will be spent on understanding
high-level business and the user requirement.
Later in the outer rings, more effort will be devoted to system
requirements engineering and system modeling
Three level process consists of:
1.Requirements elicitation
2. Requirements specification
3. Requirements validation

D E P T. O F C S E
REQUIREMENTS ENGINEERING

D E P T. O F C S E
 FEASIBILITY STUDIES
Starting point of the requirements engineering process
Input: Set of preliminary business requirements, an outine
description of the system and how the system is intended to
support business processes
Output: Feasibility report that recommends whether or not it is
worth carrying out further
Feasibility report answers a number of questions:
1.Does the system contribute to the overall objective
2.Can the system be implemented using the current
technology and within given cost and schedule
3.Can the system be integrated with other system which are
already in place.

D E P T. O F C S E
 REQUIREMENTS ELICITATION ANALYSIS
Involves a number of people in an organization
Stakeholder definition
-- Refers to any person or group who will be affected
by the system directly or indirectly i.e. End
users,Engineers,business managers, domain experts.
Reasons why eliciting is difficult
1.Stakeholder often don’t know what they want from the
computer system.
2.Stakeholder expression of requirements in natural language is
sometimes difficult to understand.
3.Different stakeholders express requirements differently
4.Influences of political factors
Change in requirements due to dynamic environments.

D E P T. O F C S E
 REQUIREMENTS ELICITATION PROCESS

Proces activities
1.Requirement Discovery
-- Interaction with stakeholder to collect their requirements
including domain and documentation
2.Requirements classification and organisation
-- Coherent clusteing of requirements from unstructured
collection of requirements
3. Requirements prioritization and negotiation
-- Assigning priority to requirements
--Resolves conflicting requirements through negotiation
Requiremnts documentation
-- Requirements be documented and placed in the next round of
spiral
D E P T. O F C S E
REQUIEMENTS DICOVERY TECHNIQUES
1. View points
--Based on the viewpoints expressed by the stake holder
--Recognizes multiple perspectives and provides a framework for
discovering conflicts in the requirements proposed by
different stakeholders
Three Generic types of viewpoints
1.Interactor viewpoint
--Represents people or other system that interact directly with the
system
2.Indirect viewpoint
--Stakeholders who influence the requirements, but don’t use the
system
3.Domain viewpoint
--Requirements domain characteristics and constraints that influence
the requirements.

D E P T. O F C S E
 REQUIREMENTS DISCOVERY TECHNIQUES
2. Interviewing
--Puts questions to stakeholders about the system that they
use and the system to be developed.
--Requirements are derived from the answers
Two types of interview
 Closed interviews where the stakeholders answer a pre-
defined set of questions.
 Open interviews discuss a range of issues with the
stakeholders for better understanding their needs.
Effective interviewers
a) Open-minded: no pre-conceived ideas
b) Prompter: prompt the interviewee to start discussion with a
question or a proposal

D E P T. O F C S E
REQUIREMENTS DISCOVERY TECHNIQUES
3. Scenarios
--Easier to relate to real life examples than to
abstract description
--Starts with an outline of the interaction and during
elicitation, details are added to create a complete
description of that interaction
--Scenario includes:
1. Description at the start of the scenario
2. Description of normal flow of the event
3. Description of what can go wrong and how this is
handled
4.Information about other activities parallel to the
scenario
5.Description of the system state when the scenario
finishes
D E P T. O F C S E
REQUIREMENTS DISCOVERY TECHNIQUES

4. Use case
-- scenario based technique for requirement elicitation
-- A fundamental feature of UML, notation for
describing object-oriented system models
-- Identifies a type of interaction and the actors involved
-- Sequence diagrams are used to add information to a
Use case

D E P T. O F C S E
ARTICLE PRINTING USE-CASE

Ar
ticle printing

D E P T. O F C S E
LIBSYS USE CASES

Ar

Library Ar
User

User administration Library

Staff

Supplier Catalogue services

D E P T. O F C S E
 REQUIREMENTS VALIDATION
Concerned with showing that the requirements define the system that the customer
wants.
Important because errors in requirements can lead to extensive rework cost
Validation checks
1.Validity checks
--Verification that the system performs the intended function by the user
2.Consistency check
--Requirements should not conflict
3. Completeness checks
--Includes requirements which define all functions and constraints
intended by the system user
4. Realism checks
--Ensures that the requirements can be actually implemented
5. Verifiability
-- Testable to avoid disputes between customer and developer.

D E P T. O F C S E
VALIDATION TECHNIQUES
1.REQUIREMENTS REVIEWS
--Reviewers check the following:
(a) Verifiability: Testable
(b) Comprehensibility
(c) Traceability
(d) Adaptability
2.PROTOTYPING

3.TEST-CASE GENERATION

D E P T. O F C S E
 REQUIREMENTS MANAGEMENT
Requirements are likely to change for large software systems and
as such requirements management process is required to
handle changes.
Reasons for requirements changes
(a) Diverse Users community where users have different
requirements and priorities
(b) System customers and end users are different
(c) Change in the business and technical environment after
installation
Two classes of requirements
(a) Enduring requirements: Relatively stable requirements
(b) Volatile requirements: Likely to change during system
development process or during operation

D E P T. O F C S E
REQUIREMENTS EVOLUTION

Initial Changed
understanding understanding
of problem of prob lem

Initial Changed
requirements requirements

Time
D E P T. O F C S E
 REQUIREMENTS MANAGEMENT PLANNING
An essential first stage in requirement management process
Planning process consists of the following
1.Requirements identification
-- Each requirement must have unique tag for cross reference and
traceability
2.Change management process
-- Set of activities that assess the impact and cost of changes
3.Traceability policy
-- A matrix showing links between requirements and other elements of
software development
4.CASE tool support
--Automatic tool to improve efficiency of change management process.
Automated tools are required for requirements storage, change
management and traceability management

D E P T. O F C S E
 TRACEABILITY

Maintains three types of traceability information.

1.Source traceability
--Links the requirements to the stakeholders
2. Requirements traceability
--Links dependent requirements within the requirements
document
3. Design traceability
-- Links from the requirements to the design module

D E P T. O F C S E
A TRACEABILITY MATRIX

D E P T. O F C S E
REQUIREMENTS CHANGE MANAGEMENT
Consists of three principal stages:
1. Problem analysis and change specification
-- Process starts with a specific change proposal
and analysed to verify that it is valid
2.Change analysis and costing
--Impact analysis in terms of cost, time and
risks
3. Change implementation
--Carrying out the changes in requirements
document, system design and its implementation

D E P T. O F C S E
 CHANGE MANAGEMENT

Identified Revised
problem Problem analysis and Change analysis Change requirements
change specification and costing implementation

D E P T. O F C S E