UNIT -II

Software Requirements:
 As per IEEE standards Requirement is a condition or capability needed by a
user to solve a problem or achieve an objective.
 A condition or capability that must be met or possessed by a system or system
component
 Requirements are classified as shown hereunder:

Main types of software requirement can be of 3 types:

 Functional requirements:
These are the requirements that the end user specifically demands as basic
facilities that the system should offer. It can be a calculation, data manipulation,
business process, user interaction, or any other specific functionality which defines
what function a system is likely to perform.

There are many ways of expressing functional requirements e.g., natural language,
a structured or formatted language with no rigorous syntax and formal
specification language with proper syntax. Functional Requirements in Software
Engineering are also called Functional Specifications.
 Examples of Functional requirements:
The user shall be able to search either all databases or specify a subset.
The system shall provide appropriate viewers for the user to read documents.
Every order shall be allocated a unique identifier (ORDER_ID).

 Non-functional requirements:
Non-functional requirements, not related to the system functionality, rather
they define how the system should perform. Basically these non-functional
requirements deal with:
a. Portability
b. Security
c. Maintainability
d. Reliability
e. Scalability
f. Performance
g. Reusability
h. Flexibility

 User requirements:

User requirements are the needs, expectations, and preferences of the people
who will use a system. They are essential for designing and developing a system
that meets the goals and solves the problems of the users. However, defining user
requirements for a system project is not a simple task. It involves several steps and
techniques that require collaboration, communication, and validation.
These are the features and capabilities that the system must provide to enable
the users to perform their tasks and achieve their goals

 System requirements:

System requirements (SRs) refer to the specifications or criteria that describe what
a system is expected to achieve or the attributes it should possess. These
requirements are essential for defining the capabilities and performance
characteristics of a system, and they serve as a foundation for the system design
and development process.
Constraints (Cs) are special kinds of functional requirements. They represent the
limitations or boundaries within which the system must operate.
Interface Specification:

Interface specifications provide the standardized mechanism in which

subsystems can effectively communicate with each other and enable them to
operate as independent modules that, when collectively implemented.

Interface specifications describe what is expected of the element to be

implemented in terms of the services and conditions under which they are
provided. Interfaces can be either external or internal, and they can be of
different types such as mechanical, electrical, pneumatic, physical, or
logical. User-interface specification defects can include invalid assumptions,
missing or superfluous specification items, incorrect or unclear specification
items, and items that are out of order.

User interface is the front-end application view to which user interacts in order
to use the software. User can manipulate and control the software as well as
hardware by means of user interface. Today, user interface is found at almost
every place where digital technology exists, right from computers, mobile
phones, cars, music players, airplanes, ships etc.

UI can be graphical, text-based, audio-video based, depending upon the

underlying hardware and software combination. UI can be hardware or
software or a combination of both.

The software becomes more popular if its user interface is:

 Attractive
 Simple to use
 Responsive in short time
 Clear to understand
 Consistent on all interfacing screens

The interaction of the user to the software program viable through the user
interface design of the software program. There is no software that does not
have a user interface. As it deals with the user interaction with the software, so
it is a very important portion of the development of any software.
The Software Requirements document:
The requirements document is the official statement of what is required by the
system developers. Should include both a definition of user requirements and a
specification of the system requirements. It is NOT a design document. As far
as possible, it should set of WHAT the system should do rather than HOW it
should do it.

The Software Requirements document

There are 6 requirements that requirement document should satisfy. It should

 Specify only external system behaviour

 Specify constraints on the implementation.
 Be easy to change
 Serve as reference tool for system maintainers
 Record forethought about the life cycle of the system.
 Characterize acceptable responses to undesired events
Purpose of SRS:

• Communication between the Customers, Analyst, System developers,

Maintainers.
• Firm foundation for the design phase
• Support system testing activities
• Support project management and control
• controlling the evolution of the system

IEEE requirements standard:

Defines a generic structure for a requirements document that must be
instantiated for each specific system.

a. Introduction.
b. General description.
c. Specific requirements.
d. Appendices.
e. Index.

As per IEEE requirements standard

1. Introduction
– Purpose
– Scope
– Definitions,
– Acronyms
– Abbreviations
– References
– Overview

2. General description
– Product perspective
– Product function summary
– User characteristics
– General constraints
– Assumptions and dependencies
3. Specific Requirements
– Functional requirements
– External interface requirements
– Performance requirements
– Design constraints
– Attributes e.g. security, availability, maintainability,
Transferability/conversion
– Other requirements
– Appendices
– Index

Requirement 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
Spiral Representation of Requirement 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 modelling.

The three level process consists of:

1. Requirements elicitation.
2. Requirements specification.
3. Requirements validation.

FEASIBILITY STUDY:
Starting point of the requirements engineering process

• Input: Set of preliminary business requirements, an outline 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?

REQUIREMENTS ELICITATION ANALYSIS:

Involves a number of people in an organization like Stakeholder or 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 stakeholder’s express requirements differently
4. Influences of some factors Change in requirements due to dynamic
environments.

Elicitation Process activities

1. Requirement Discovery: Interaction with stakeholder to collect the

Requirements including domain and documentation

2. Requirements classification and organization Coherent clustering of

requirements from unstructured collection of requirements

3. Requirements prioritization and negotiation: Assigning priority to

Requirements resolves the conflicting requirements through negotiation

4. Requirements documentation: Requirements be documented and placed in

the
 next round of spiral

1. Viewpoints: 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.

2. Interviewing: It 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
Requirements management planning:

An essential first stage in requirements is management and Planning 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

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 Phase of
System development.