Requirement Analysis and Specification in Software Engineering

Requirement Analysis in Software Engineering:

The Requirement Analysis and Specification phase starts after the feasibility study stage is complete and the project is financially viable and technically feasible. This phase ends when the requirements specification document has been developed and reviewed. It is usually called the Software Requirements Specification (SRS) Document.

These activities are usually carried out by a few experienced members of the development team and it normally requires them to spend some time at the customer site. The engineers who gather and analyse customer requirements and then write the requirements specification document are known as system analysts in the software industry. System analysts collect data about the product to be developed and analyse the collected data to conceptualize what exactly needs to be done. After understanding the precise user requirements, the analysts analyse the requirements to weed out inconsistencies, anomalies and incompleteness.

We can conceptually divide the requirements gathering and analysis activity into two separate tasks:

Requirements Gathering:

It is also known as Requirements Elicitation. The primary objective of the requirements-gathering task is to collect the requirements from the stakeholders. A stakeholder is a source of the requirements and is usually a person or a group of persons who either directly or indirectly are concerned with the software.
1. Studying existing documentation: The analyst usually studies all the available documents regarding the system to be developed before visiting the customer site. Customers usually provide a statement of purpose (SoP) document to the developers. Typically these documents might discuss issues such as the context in which the software is required.

2. Interview: Typically, there are many different categories of users of the software. Each category of users typically requires a different set of features from the software. Therefore, it is important for the analyst to first identify the different categories of users and then determine the requirements of
each.

3. Task analysis: The users usually have a black-box view of software and consider the software as something that provides a set of services. A service supported by the software is also called a task. We can therefore say that the software performs various tasks for the users. In this context, the analyst tries to identify and understand the different tasks to be performed by the software. For each identified task, the analyst tries to formulate the different steps necessary to realise the required functionality in consultation with the users.

4. Scenario analysis: A task can have many scenarios of operation. The different scenarios of a task may take place when the task is invoked under different situations. For different types of scenarios of a task, the behaviour of the software can be different.

5. Form analysis: Form analysis is an important and effective requirement-gathering activity that is undertaken by the analyst when the project involves automating an existing manual system. During the operation of a manual system, normally several forms are required to be filled up by the stakeholders, and in turn, they receive several notifications. In form analysis, the existing forms and the formats of the notifications produced are analysed to determine the data input to the system and the data that are output from the system.

Requirement Analysis and Specification:

After requirements gathering is complete, the analyst analyses the gathered requirements to form a clear understanding of the exact customer requirements and to weed out any problems in the gathered requirements. It is natural to expect the data collected from various stakeholders to contain several contradictions, ambiguities, and incompleteness.

The main purpose of the requirements analysis activity is to analyse the gathered requirements to remove all ambiguities, incompleteness, and inconsistencies from the gathered customer requirements and to obtain a clear understanding of the software to be developed.

During requirements analysis, the analyst needs to identify and resolve three main types of problems in the requirements:

Anomaly: It is an anomaly is an ambiguity in a requirement. When a requirement is anomalous, several interpretations of that requirement are possible. Any anomaly in any of the requirements can lead to the
development of an incorrect system, since an anomalous requirement can be interpreted in several ways during development.

Inconsistency: Two requirements are said to be inconsistent if one of the requirements contradicts the other.

Incompleteness: An incomplete set of requirements is one in which some requirements have been overlooked. The lack of these features would be felt by the customer much later, possibly while using the software. Often, incompleteness is caused by the inability of the customer to visualise the system that is to be developed and to anticipate all the features that would be required.