After completing this experiment you will be able to:
- Identify ambiguities, inconsistencies and incompleteness from a requirements specification
- Identify and state functional requirements
- dentify and state non-functional requirements
What are requirements? Sommerville  defines it as a specification of what should be implemented. It describes how the target system should behave.
Requirements specify what to do, and not how to do. Requirements engineering is the process of understanding the customer expectations from the system to be developed, and to document them in a standard and easily readable and understandable format, which 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 it's requirements. If we don't have a clear vision of what to be developed and what all features are expected, then 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 or anomaly in the requirements collected. 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"? There's an ambiguity.
- Consistenency: To illustrate this, consider the automation of a chemical plant. Suppose one end user says that if the temperature of the system rises above T1, the alarm should be sounded. However, another end user says that if temperature crosses the threshold of T1, the water showers should be turned on. Thus, there is an inconsistency between the expectation of the two end users from the system when it reaches above temperature T1.
- 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: Written in natural language for the benefit of customers and end users
- System requirements: Expressed as a programming or mathematical model meant for the development or testing teams
Based on what the requirements describes, they can be classified into two groups:
- Functional requirements: They describe the functionalities of a system, or how a system should react to a particular set of inputs and what the corresponding output should be.
- Non-functional requirements: They are not directly related to the functionality of the system, but may define how the system may end up behaving. For example, the requirement that the system should work at a minimum of 128MB RAM. As such, non-functional requirements could be more critical than functional requirements.
Non-functional requirements could be further classified into different types like:
- Product requirements: For example, the specification that the web application should use only plain HTML, and no frames
- Performance requirements: For example, the system should remain available 24x7
- Organizational requirements: The development process should comply to SEI CMM level 4
Identifying Functional Requirements
Given a problem statement, the functional requirements could be identified by focusing on the following points:
- Identify the high level functional requirements from the problem description available or conceptual understanding of the problem.
- Such requirements would be characterized by using the system to do some meaningful work by the users. For example, in a digital library a user might use the "Search Book" functionality to obtain information about the book of his interest.
- User would be providing certain inputs and the system in turn would produce some output. For example, to search for a book, user gives title of the book as input and get the book details and location as the output.
- A high level requirement could have sub requirements associated with it