Identifying the Requirements from Problem Statements
Sommerville defines “requirement”  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 do not have a clear vision of what is to be developed and what all features are expected, wewould be faced with problems down the road leading 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 about what a system to be developed should do. For example, consider that 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 is the “enough number of people”? That could mean 10 to you, but perhaps 100 to the client. This is an example of ambiguity.
- Consistency: To illustrate this, consider the automation of a nuclear plant. Suppose that one of the clients say that if the radiation level inside the plant exceeds R1, all reactors should be shut down. However, another person 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 a 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 customers and analysts can verify that 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 can typically define how the system should behave under certain situations. For example, an NFR can say that the system should work with 128MB RAM. Under such conditions, an NFR can become more critical than an FR.
Non-functional requirements can be further classified into different types, such as:
- Product requirements: For example, a specification that the web application should use only plain HTML and no frames
- Performance requirements: For example, the system should remain available 24×7
- Organizational requirements: The development process should comply to SEI CMM level 4
Identifying Functional Requirements
Given a problem statement, the functional requirements can be identified by focusing on the following points:
- Identify the high level functional requirements from the conceptual understanding of the problem. For example, a Library Management System, apart from anything else, should be able to issue and return books.
- Identify the cases where an end-user gets some meaningful work done by using the system. For example, in a digital library a user might use the “Search Book” functionality to obtain information about the books of his/her interest.
- If we consider the system as a black box, there would be some inputs to it and some output in return. This black box defines the functionalities of the system. For example, to search for a book, user provides the title of the inteded book as an input and gets the book details and location as output.
- Any high level requirement identified could have different sub-requirements. For example, the “Issue Book” module can behave differently for different categories of users or for a particular user who has issued the book thrice consecutively.
Preparing Software Requirements Specifications
Once all possible FRs and non-FRs have been identified, which are complete, consistent, and non-ambiguous, the Software Requirements Specification (SRS) is prepared. IEEE provides a template [iv], also available here, which can be used for this purpose. The SRS is prepared by the service provider and verified by its client. This document serves as a legal agreement between the client and the service provider. Once the concerned system has been developed and deployed, if a proposed feature was not found to be present in the system, the client can point this out from the SRS. Also, if after delivery, the client says a new feature is required, which was not mentioned in the SRS, the service provider can again point to the SRS. The scope of the current experiment, however, does not cover writing a SRS.