EXPERIMENT NO-1
Identifying the Requirements from Problem Statements
Introduction
Requirements identification is the first step of any software development project. Until the requirements of a client
have been clearly identified, and verified, no other task (design, coding, testing) could begin. Usually business
analysts having domain knowledge on the subject matter discuss with clients and decide what features are to be
implemented.
In this experiment we will learn how to identify functional and non-functional requirements from a given problem
statement. Functional and non-functional requirements are the primary components of a Software Requirements
Specification.
Objectives
After completing this experiment you will be able to:
1. Identify ambiguities, inconsistencies and incompleteness from a requirements specification
2. Identify and state functional requirements
3. Identify and state non-functional requirements
Time Required
Around 3.00 hours
Requirements
Sommerville defines "requirement" [1] as a specification of what should be implemented. Requirements specify how
the target system should behave. It specifies what to do, but not how to do. Requirements engineering refers to the
process of understanding what a customer expects from the system to be developed, and to document them in a
standard and easily readable and understandable format. This documentation will serve as reference for the
subsequent design, implementation and verification of the system.
It is necessary and important that before we start planning, design and implementation of the software system for our
client, we are clear about its requirements. If we don't have a clear vision of what is to be developed and what all
features are expected, there would be serious problems and customer dissatisfaction as well.
Characteristics of Requirements
Requirements gathered for any new system to be developed should exhibit the following three properties:
Unambiguity: There should not be any ambiguity what a system to be developed should do. For example, consider
you are developing a web application for your client.
The client requires that enough number of people should be able to access the application simultaneously. What's the
"enough number of people"? That could mean 10 to you, but, perhaps, 100 to the client. There's an ambiguity.
Consistency: To illustrate this, consider the automation of a nuclear plant. Suppose one of the clients say that it the
radiation level inside the plant exceeds R1, all reactors should be shut down. However, another person from the client
side suggests that the threshold radiation level should be R2. Thus, there is an inconsistency between the two end
users regarding what they consider as threshold level of radiation.
Completeness: A particular requirement for a system should specify what the system should do and also what it
should not. For example, consider software to be developed for ATM. If a customer enters an amount greater than
the maximum permissible withdrawal amount, the ATM should display an error message, and it should not dispense
any cash.
Categorization of Requirements
Based on the target audience or subject matter, requirements can be classified into different types, as stated below:
User requirements: They are written in natural language so that both customers can verify their requirements have
been correctly identified
System requirements: They are written involving technical terms and/or specifications, and are meant for the
development or testing teams
Requirements can be classified into two groups based on what they describe:
Functional requirements (FRs): These describe the functionality of a system -- how a system should react to a
particular set of inputs and what should be the corresponding output.
Non-functional requirements (NFRs): They are not directly related what functionalities are expected from the
system. However, NFRs could typically define how the system should behave under certain situations. For example,
