Requirements Elicitation and Specification
The requirements elicitation and specification phase starts when the feasibility study phase is completed and the project is found to be technically and feasible.
The goal of the requirements analysis and specification phase is to understand client requirements and to systematically organize these requirements in a specification document.
The requirements elicitation and specification phase ends with the production and validation of the requirements specification document that is usually called the Software Requirement Specification (SRS). The engineers who gather and analyze customer requirements and then write the requirements specification document are known as system analysts.
The main activities carried out during requirements elicitation and specification phase are of two types as follows:
- Requirements elicitation and Analysis
- Requirement Specification
Requirements Elicitation and Analysis
It would be unrealistic to expect the client to produce a comprehensive document containing a precise description of what he wants. Therefore, the requirements have to be gathered by the analyst from various sources in bits and pieces. The gathered requirements are then analyzed to remove several types of problems that frequently occur in the requirements gathered from different sources.
The requirement elicitation and analysis activity are divided into two separate tasks as (a) requirement elicitation and (b) requirements analysis.
(a) Requirements Elicitation
Requirements gathering is also popularly known as requirements elicitation. Requirements elicitation typically starts by studying the existing documents to collect all possible information about the system to be developed, even before visiting the customer site. During a visit to a customer site, the analysts normally interview the end-users and customers, carry out a questionnaire survey, task analysis, scenario analysis, and form analysis.
- Interview: There are many different categories of users of the software. Different categories of users typically require different features from the software. All the different categories of users are interviewed to gather the different functionalities required by them. For example, to perform the requirements analysis of a library automation software, the analyst might interview the library members, the librarian, and the accountants.
- Task Analysis: The users usually view software as a black box that provides a set of services. Service is also called task. For each identified task, the analyst tries to formulate the different steps necessary to realize the service in consultation with users.
For example, for the issue book service in a library, the steps may be: authenticate user, check the number of books issued to the member and determine if the maximum number of books that this member can borrow has been reached, check whether the book has been reserved, post the book issue details in the member‟s record, and finally print out a book issue slip that can be presented at the security counter to take out the book. - Scenario Analysis: A task can have many scenarios of operations. The different scenarios of a task can occur when the task is invoked in different situations. For different types of scenarios of a task, the behaviour of the system can be different.
For example, the different scenarios for the book issue task of a library automation software may be:
– Book issue service is satisfactorily performed and the book issue slip is printed.
– The book is reserved and cannot be issued to the member.
– The maximum number of books that can be issued to the member is exceeded, and the book cannot be issued to the member.
For various identified tasks, the different types of scenarios that may occur are identified and the detail of each scenario is identified in consultation with users. - Form Analysis: The different form are analyzed to determine the data input to the system and data output from the system. For the different data input to the system, how these are used by the system to produce the corresponding output data are determined from the users.
(b) Requirements Analysis
The main purpose of the requirements analysis is to analyze the gathered information to get a clear understanding of the product to be developed, with a view to removing all inconsistencies, incompleteness, and ambiguities from the initial customer perception of the problem. After the analyst has understood the exact customer requirements, he proceeds to identify and resolve the various problems that he detects in the gathered requirements.
There are three main types of problems in the requirements analysis that the analyst needs to identify and solve:
- Ambiguity: An anomaly is an ambiguity in the requirement. When a requirement is anomalous, several interpretations of that requirement are possible. Any anomaly in the requirements can lead to the development of incorrect systems since an anomalous requirement can be interpreted in several ways.
The following is an example of anomalous requirements: For an institute office automation system, the office clerks mentioned that during the final grade computation, if any student scores a sufficiently low grade in a semester, then his parents should be informed. But, the clerk could not provide any well-defined criteria of what can be considered as a ‘sufficiently low grade’. - Inconsistency: Two requirements are said to be inconsistent if one of the requirements contradicts the other, or two end-users of the system give inconsistent information of the requirement.
The following is an example of an inconsistent requirement: For an institute automation system, one of the clerks described that a student securing fail grades in three or more subjects should have to repeat the entire semester. Another clerk mentioned that there is no provision for any student to repeat a semester. - Incompleteness: An incomplete set of requirements is one in which some requirements have been ignored. Often, the incompleteness is caused by the inability of the customer to visualize the system that is to be developed and to anticipate all the features that would be required.
The following is an example of an incomplete requirement: For an institute automation system, suppose one of the clerks mentioned that if a student secures a grade point average of less than 6, then the parents of the student must be intimated about the regrettable performance through a postal letter and they should also be intimated by e-mail. However, on an examination of all other requirements, it was found that there is no provision by which either the postal or e-mail address of the parents of the students can be entered into the system. The feature that would allow entering the e-mail and postal address of the parents of the students is missing, making the requirements incomplete.
Read Further: Wikipedia
Other SDLC Model: Classical Waterfall Model | Iterative Waterfall Model | Prototype Model | Spiral Model | Evolutionary Model |
