Definition of Requirement Engineering
The process of defining, documentation, and maintenance of requirements in the design process of engineering is called requirements engineering. It provides an apt mechanism to understand the customer’s desires, analysis of needs of the customer, feasibility assessment, negotiations for a reasonable solution, clarity in the specification of the solution, specifications validation, and requirements management. In contrast, the requirements are being transferred to the working system. Hence, this makes requirements engineering an application that is disciplined, having the principles, methods, tools, and notations that are proved, which can describe the intended behavior of the proposed system and the constraints associated with it.
The process of requirements engineering happens in five steps. The below figure illustrates the five steps of requirements engineering.
Process of Requirements Engineering
The five steps in the process of requirements engineering are:
1. Feasibility Study
The main aim of a feasibility study is to create reasons for the development of the software that the users accept, that is flexible enough and open to changes, and abide by the standards chosen for software development and maintenance.
There are several types of feasibility. They are:
Technical Feasibility: The current technologies are evaluated using technical feasibility, and they are necessary to achieve the requirements of the customer within the given time and budget.
Operational Feasibility: The assessment of the range for software in which the required software performs a series of levels to solve the problems in business and the customer’s requirements.
Economic Feasibility: If the required software can generate profits in the area of finance is decided by economic feasibility.
2. Elicitation of Requirements and Analysis
This process is also called requirements gathering. If there are any existing processes available and with the help of customers, requirements gathering is done. Elicitation of requirements is the starting step of requirements analysis. Inconsistencies, omissions, defects, etc., can be identified by analyzing the requirements. Requirements are described in relationship terms to resolve if there are any conflicts. There are a few challenges with respect to the elicitation of requirements and analysis. They are:
- Involvement of all the right people and only the right people.
- The stakeholders not knowing what they need.
- The requirements are expressed in terms of stakeholders.
- The requirements of the stakeholders may be conflicting.
- The changes in requirements during the process of analysis.
- Several factors influence the requirements of the system in organization and politics.
3. Specification of Software Requirements
A document consisting of requirements that are collected from various sources like the requirements from customers expressed in an ordinary language and created by the software analyst is called a specification document for software requirements. The analyst understands the customers’ requirements in ordinary language and converts them into a technical language that the development team can easily understand. Several models are used during the process of specification of software requirements like Entity-Relationship diagrams (ER diagrams), data flow diagrams (DFD), data dictionaries, function decomposition diagrams (FDD), etc.
- Data Flow Diagrams (DFD): The modeling of requirements can be done using Data Flow Diagrams (DFD). The flow of data within the system can be seen by using data flow diagrams (DFD). The system here can be a company, an organization, a hardware system in a computer, a software system in a computer, a set of procedures or a combination of everything. The data flow diagrams (DFD) are also called bubble charts or data flow graph.
- Data Dictionaries: The data defined using a data flow diagram (DFD) is stored as information in the form of repositories called data dictionaries. The customer’s data items must be defined by the data dictionaries at the stage of requirements gathering to make sure that the customers and developers use the same methodologies and definitions.
- Entity Relationship Diagrams: One of the other tools used for the specification of requirements is entity-relationship diagrams. It is also called as ER diagrams. The detailed representation of logic for the organization is done using entity relationship diagrams (ER diagrams). They make use of three types of constructs: relationships, entities of data, and the attributes associated with them.
4. Validation of Software Requirements
After the development of the specification of requirements, the requirements laid down in the document are validated. There may be requirements from the users that are illegal or which cannot be accomplished, or the experts can misunderstand the needs. The requirements must satisfy the following conditions:
- If the requirements can be implemented practically.
- If the requirements are correct and they are according to the software functionality.
- If there are any confusions.
- If the requirements are full.
- If the requirements can be described.
There are several techniques for the validation of requirements. They are:
- Inspection of requirements or reviews of requirements.
This includes an analysis of the requirements systematically and manually.
The requirements of the model are checked by using a model that is executable.
- Generation of test case
The testability is checked for the requirements by the development of tests.
- Automated consistency analysis
The consistency of the descriptions of requirements is checked.
5. Management of Software Requirements
The process of managing the requirements that keep changing during the process of requirements engineering and development of the system is called management of software requirement. During the process of software management, there are new requirements with the change in the needs of business, and there is the development of a better understanding of the system. During the process of development, the requirements priority changes from different views. During the process of development, the technical and business environment of the system changes.
Advantages of Requirement Engineering
The advantages of using requirements engineering are:
- Lesser chances of process overhead. The required for the analysis and documentation of the requirements will be comparatively less because requirements capture using requirements engineering are quicker and more precise.
- The requirements that are critical can be identified and implemented in the initial stage using requirements engineering. As there is concurrency between requirements engineering activities, communication is more efficient between the stakeholders and the software engineers.
- There is a quick response to the changes in requirements. The identification of requirements and their documentation undergo a series of iteration before they are finalized, so the response to the changes in the requirements can be quicker and can be done at a relatively lower cost.
This is a guide to Requirement Engineering. Here we also discuss the introduction and process of requirements engineering along with advantages. You may also have a look at the following articles to learn more –
- Reverse Engineering
- Data Science vs Software Engineering
- GIS Software
- Process of Reverse Engineering