Unit-II
o Software Requirements: Functional and non-functional requirements, user
requirements, system requirements, interface specification, the software
requirements document.
o Requirements engineering process: Feasibility studies, requirements elicitation and
analysis, requirements validation, requirements management.
Software Requirements
o Introduction
o Functional and Non Functional Requirements
o User Requirements
o System requirements
o Interface Specification
o The software Requirement document
Introduction
Requirement Engineering:
The process to gather the requirements from client, analyze and
document them is known as “Requirement Engineering”.
The goal of requirement engineering is to develop and maintain
sophisticated and descriptive ‘Software Requirements Specification’
document.
Requirements
• Requirements are descriptions of services that a software system must
provide and the constraints under which it must operate.
• Requirements help to describe what the software should do.
Types of requirements
• User Requirements:
– It is a collection of statements in natural language plus description of the
services the system provides and its operational constraints. It is written for
customers.
• System Requirements:
– It is a structured documents that gives the detailed description of the system
services. It is written as a contract between client and contractor.
• Software specification:
– It is a detailed software description that can serve as basis for design or
implementation. Typically it is written for software developers.
Software requirements
• The software requirements are description of features and
functionalities of the target system. Requirements convey the
expectation of users from the software product.
• The requirements can be obvious/hidden, known (or) unknown,
expected (or) unexpected from clients point of view.
• Software system requirements can be classified as functional and non
functional requirements.
Functional requirements
• It describes the functionality of the system. i.e. features provided by system to
satisfy customers.
• Functional requirements should be complete and consistent.
• The customer should provide statement of service. It should be clear how the
system should react to particular inputs and how a particular system should
behave in particular situation.
• Functional requirements are heavily dependent upon the type of software,
expected users and the type of system where the software is used.
• Functional requirements specify product features.
– Determine what the system has to do
– What are the expectations from the software
– What the software should do
Problems associated with requirements
• Requirements Imprecision:
– Problems arise when requirements are not precisely stated.
– Ambiguous requirements may be interpreted in different ways by developers and users.
• User intention:
– Special purpose viewer for each different document type.
• Developer interpretation:
– Provide a text viewer that shows the content of the document.
• Requirements completeness and consistency:
– The requirements should be both complete and consistent.
– Complete means they should include descriptions of all facilities required.
– Consistent means there should be no conflicts in the descriptions of the system facilities.
Actually in practice, it is impossible to produce a complete and consistent
requirements document.
Non functional requirements
• It is not directly related to functionality of system.
• It describes about how features are provided.
• Non functional requirements are more critical than functional
requirements. If the non functional requirements do not meet
then the complete system is of no use.
• Non functional requirements are 3 types
– Product Requirements
– Organizational Requirements
– External Requirements
Three classes of non-functional requirements:
Product requirements
These Requirements specify how a delivered product should
behave in a particular way.
e.g. execution speed, reliability, etc.
Organizational requirements
These requirements specifies the organizational policies and
procedures.
e.g. process standards used, implementation
requirements, etc.
External requirements
Requirements that arise from external process of system and
its development process
e.g. interoperability requirements, safety.
• In short , non functional requirements arise through
– User needs
– Because of budget constraints
– Organizational policies
– The need for interoperability with other software or hardware systems.
– Because of external factors such as safety regulations.
Difference between functional & nonfunctional
requirements
Functional Requirements Non functional Requirements
The functional requirements specify the features of It specify the properties of the software system
the software system
It describe what the product must do. It describe how the product should perform.
It specify the actions with which the work is It specify the experience of the user while using the
concerned. system.
Eg: for a library management system, allowing user to Eg: For a library management system, for a user who
read the article online is a functional requirement. wishes to read the article online must be
authenticated first.
User requirements
• The user requirements should describe functional and non
functional requirements in such away that they are
understandable by system users who don’t have detailed
technical knowledge.
• User requirements are define using natural language, tables
and diagrams because these are the representations that can be
understood by all users.
Problems
• Lack of clarity:
• Sometimes requirements are given in ambiguous manner. It is expected that
text should help in clear and precise understanding of the requirements.
• Requirement confusion:
• There may be confusion in functional requirements and non functional
requirements, system goals and design information.
• Requirement mixture:
• There may be a chance of specifying several requirements together as a single
requirement.
Guidelines for writing user requirements
• Prepare a standard format and use it for all requirements.
• Apply consistency in the language. Use
– ‘shall’ for mandatory requirements
– And ‘should’ for desirable requirements
• The text which is mentioning the key requirements should be
highlighted.
• Avoid the use of computer jargon. It should be written in
simple language.
System requirements
• System requirements are more detailed specifications of system functions, services
and constraints than user requirements.
• System requirements are the minimum and/or maximum hardware and software
specifications that a system or application must meet in order to function properly.
– They are intended to be a basis for designing the system.
– The system requirements can be expressed using system models.
– The requirements specify what the system does and design specifies how it does.
– It should simply describes the external behavior of the system and its operational
constraints.
– For a complex software system design it is necessary to give all the requirements in detail.
– Usually natural language is used to write system requirements specifications and user
requirements.
System requirements
• The advantage of specifying requirements using this method is
that requirements become understandable & expressive.
• The information can be represented using tables(or) graphical
models.
• one way of using graphical models is use of sequence diagram
• The sequence diagram represent the sequence of actions that
user performs while interacting the system.
Sequence diagram of ATM withdrawal
Interface specification
• Sometimes there is already existing system which can be used
with newly created software system. This conjunction of old
system with new system is called system interface. In such
situation the interfaces of already existing systems must be
specified clearly.
• There are 3 types of interfaces that can be defined
– Procedural interface
– Date structures
– Representation of data
Types of interfaces
Procedural Interface:
These are popularly known as Application Programming Interfaces(API) such
procedures are intended to offer services that may be used by calling procedures.
Data Structures:
Data structures are the descriptors of data. They play an important role in
organization of data for given algorithm. The data structures can be passed from one
sub system to another.
Representation of data:
This level of specification is used in certain programming language like ADA
for real time applications these kind of interfaces are often useful sometime to
describe this interface diagrams can be used.
Software requirement documents
• The software requirement document is the specification of the
system. It should include both a definition and specification of
requirements.
• It should set of what the system should do rather than how it should
do it.
• Software requirement specification
– The software requirement provide a basis for creating the software
requirement specifications(SRS).
– The SRS is useful in estimating cost, planning team activities, performing
tasks and tracking the teams progress throughout the development activity.
• The standard template for writing SRS is as given below.
Document Title
Author(S)
Affiliation
Address
Date
Document Version
1. Introduction
1. Purpose of this document
2. Scope of this document
3. Overview
2. General description
3. Functional Requirements
4. Interface requirement
5. Performance requirement
6. Design constraints
7. Other Non functional requirements
1. Security, reliability
2. Portability, reusability
8. Operational scenarios
9. Preliminary schedule
10. Budget
11. Appendices
SRS
1. Introduction
1. Purpose of this Document Describes the purpose of the document
2. Scope of this Document Describes the scope of this requirements definition effort this
section also details any constraints that were placed upon the requirements elicitation
process, such as schedules, costs.
3. Overview Provides a brief overview of the product defined as a result of the
requirements elicitation process.
2. General Description
– Describes the general functionality of the product such as similar system information, user
characteristics, user objective, general constraints placed on design team.
3. Functional Requirements
This section lists the functional requirements in ranked order.
Description A full description of the requirement.
Criticality Describes how essential this requirement is to the overall
system.
Technical Issues Describes any design (or) implementation issues
involved in satisfying this requirement.
Cost & Schedule Describe the relative (or) absolute costs of the
system.
Risks Describes the circumstances under which this requirement
might not able to be satisfied.
Dependencies with other requirements describes interactions with
other requirements.
4. Interface requirements:
This section describes how the software interfaces with other software
products (or) users for input (or) output.
User Interface describes how this product interfaces with the user.
GUI describes the graphical user interface of present.
CLI describes the command line interface if present
API describes the application programming interface if present.
Hardware interface describes interfaces to hardware devices.
Communications interface describes network interfaces.
Software Interface describes speed and memory requirements.
5. Performance Requirements specifies speed and memory
requirements.
6. Other Non functional requirements
7. Design constraints
Specifies any other particular non functional attributes required by the
system. Such as security, reliability, reusability, maintainability, portability,
extensibility, serviceability.
8. Operational scenarios
This section should describes a set of scenarios that illustrate, from the
users perspective, what will be experienced when utilizing the system under
various situations.
9. Preliminary schedule
This section provides an initial version of the project plan, including the
major tasks to be accomplished, their interdependencies and their tentative
start/stop dates.
10. Preliminary Budget
This section provides an initial budget for the project.
11. Appendices
Definitions, acronyms, abbreviations
Provides definitions terms, and acronyms can be provided.
References provides complete situations to all documents and meetings
referenced.
Characteristics of good SRS
• Correct:
– The SRS must be correct. That means all the requirements must be
correctly mentioned
• Complete:
– The SRS is said to be complete only in following situations.
1. When SRS consists of all the requirements related to functionality,
performance, attributes, design constraints (or) external interfaces.
2. When expected responses to the input data is mentioned by
considering validity and invalidity of an input.
• Unambiguous:
– When requirements are understand correctly then only unambiguous SRS can be
written.
– Unambiguous specification means only one interpretation can be made from the
specified requirements.
– If for particular term there are multiple meanings then, those terms should be
mentioned in glossary with proper meaning.
– If there are no conflicts in the specified requirements then SRS is said to be
consistent.
• Stability:
– In SRS, it is not possible to specify all the requirements. The SRS must contain all
the essential requirements. Each requirement must be clear and explicit.
• Verifiable:
– The SRS should be written in such a manner that the requirements that are
specified with in it must be satisfied by the software.
• Traceable:
– References of the requirements are correctly mentioned then such
a requirement is called as traceable requirements.
– Various types of traceability's are
1. Forward traceability Each requirement is referred in the SRS
document by its unique name.
2. Backward traceability If the reference to the requirement is
mentioned in ealier document, then it is backward traceability.
