Requirements engineering is a relatively complex science involving elicitation, observation, brainstorming, facilitating focus groups, prototyping, analysis, modelling, and documentation—just a few of them.
Requirements engineering encompasses identifying, modelling, communicating, and documenting a system’s requirements and contexts of use, which are requirements engineers’ responsibilities. Requirements describe what needs to be done but not how. Requirements engineering uses various techniques to ensure accuracy, completeness, consistency, and relevance. Before system development, it specifies what needs to be built to avoid costly rework. To accomplish this objective, there is a significant assumption that the later mistakes are discovered, the more expensive it is to correct them. To begin the design and implementation of a system, it is necessary to establish an initial set of requirements. The requirements engineering process consists of five primary activities: elicitation, analysis, negotiation, documentation, validation, and management. I will briefly discuss each of these and the techniques developed below.
Clients, developers, and users are consulted to elicit requirements. System boundaries define the context. To build a system, you must understand the domain, the business needs, the constraints of the system, the stakeholders, and the problem. Here’s a look at the essential techniques for eliciting requirements. As part of a system development project, prospective users are interviewed. This gives you a chance to spot mistakes and misunderstandings and fix them. There are no distinct boundaries between these two types of interviews. An in-depth interview with a requirements engineer. The study seeks answers to predefined questions. Stakeholders and requirements engineers have open-ended discussions. The interview begins with a few questions, followed by a discussion. By conducting interviews, the requirements engineer can gather a variety of information. However, these methods have limitations, including the difficulty of analysing qualitative data and the possibility of conflicting information from multiple stakeholders.
A use case describes how a user interacts with a system. As a result of variations and extensions to use cases, we can explain how a system interacts with an external actor (e.g., a person, an item of hardware, or another software product). At the outset of the software development process, the software use case represents a functional requirement. Validating each use case requires collaboration between analysts and customers. Scenarios represent simulated interactions between users and computer systems before and after the scenario; it is imperative to describe the system’s state, the simultaneous activities, and, if there are any exceptions, the typical events.
Requirements Engineers observe users at work and note their behaviour. Investigators may observe a task directly or indirectly (for example, by recording a video). It is possible to analyse current processes and tasks. In observations, stakeholders may describe idealised or oversimplified work processes, facilitating stakeholder issue resolution.
It is a free-form discussion among four to nine individuals with diverse backgrounds and skills regarding the features of a system prototype. Focus groups allow users to indicate their needs, wants, and desires regarding the system. Ideas and reactions often flow spontaneously. Since people speak and behave differently, observations are a valuable complement to focus groups. Focus groups are excellent for articulating visions, design proposals, and product concepts. Focus groups can evaluate changes and develop a shared understanding of the system.
Brainstorming can solve problems creatively. Brainstorming consists of two phases: generation and evaluation. During the generation phase, ideas are collected and evaluated. You should not criticise or evaluate ideas during the generation phase. Ideas should be developed quickly and should be broad and unusual. Brainstorming leads to a better understanding of the problem and shared ownership of the outcome.
Prototypes are early versions of a system that are available during its development phase. Prototypes are often used to elicit and validate software system requirements. Throwaway prototypes help understand complex requirements. Evolutionary prototypes often become a part of the final system after delivering a working prototype to the customer. Paper prototypes may be used (where possible). Various prototype tests include paper prototypes (where a person simulates the system’s responses to input from the user) or automated prototypes (where an executable prototype is developed using a rapid development environment).
As part of the requirements analysis process, it is crucial to ensure that requirements are necessary (requirements are needed), consistent (requirements are not contradictory), complete (no services or constraints are lacking), and feasible (requirements are achievable given the budget and schedule available for the system development). Prioritisation negotiations are conducted with stakeholders to resolve conflicts in requirements. Prioritising contested requirements is one method of identifying critical requirements. A compromise set of requirements is reached after identifying solutions to requirement problems. Requirements analysis involves three main techniques: J.A.D sessions, prioritisation, and modelling.
Structured analysis is used to conduct group discussions (or workshops). As part of a Joint Application Development (J.A.D) session, developers and customers can discuss the features they want included in the product. The session leader is responsible for maintaining participants’ attention throughout this type of discussion and preventing them from deviating from the topic. J.A.D allows you to define specific projects at varying levels of detail. It also allows you to develop a solution and monitor progress until the project is completed. Participants can be executives, project managers, users, system experts, and technical staff. J.A.D encourages cooperation, understanding, and teamwork among different groups of participants. This will enable participants with various backgrounds to provide input regarding the other aspects of the proposed system. This will provide a basis for eliciting further requirements.
Whenever possible, it is essential to deliver the most valuable features as early as possible on a project with a tight schedule, limited resources, and high customer expectations. Establishing priorities at the beginning of the project is essential to making time-sensitive decisions. Customers prioritise requirements. Prioritising requirements requires input from both the customer and the developer. To prioritise features, the customer marks those features that will provide the most significant benefit to users. Whenever there’s a technical risk, cost, or difficulty, developers point it out. The customer may change the priority of some features based on this information.
The system model serves as a bridge between the analysis and design phases. Modelling techniques, such as data-flow models, semantic data models, and object-oriented approaches, are available for describing system requirements.
Documenting requirements is a means of communicating requirements between stakeholders and developers. The requirements document is the baseline for evaluating subsequent products and processes (design, testing, verification, and validation activities) and controlling change. A requirements document must be clear, complete, accurate, understandable, consistent, concise, and feasible. Depending on the relationship between the customer and supplier, the requirements specification may form part of the contract.
During the requirements validation process, it is essential to confirm that the requirements accurately describe the system to be implemented. Validation is based on the requirements document, organisational standards, and organisational knowledge. The outputs consist of a list containing the reported issues with the requirements document and the necessary actions to resolve these issues. The two most commonly used techniques for evaluating requirements are requirements reviews and testing. Project stakeholders usually sign off on requirements validation.
Information is captured, stored, disseminated, and managed through requirements management. A significant aspect of requirements management is the management of changes and versions, the tracing of requirements, and the tracking of requirements status. Effective ways to manage system changes are through requirements traceability. This establishes relationships between requirements, system design, and implementation.
