Requirements engineering (RE)

Requirements engineering (RE) is a form of engineering that focuses on the requirements of a new product, such as a piece of computer software. These requirements address the wants, needs, and various expectations of stakeholders in the product, ranging from the people who fund and produce the product to the customers and users who will ultimately buy and utilize the product. Requirements engineering involves a number of steps that may overlap or may be reorganized to better suit the individual project at hand.

Brief History

Engineering refers to the use of scientific principles to design, create, or improve products or ideas. Engineers may work with physical tools and machines ranging in complexity from simple wheels and pulleys to sophisticated digital devices or skyscraping building structures. In its many forms, engineering has been an important part of human life for thousands of years. Traditionally, most engineers focus on the processes by which products and ideas can be formed.

Unlike these other forms of engineering, requirements engineering focuses on the overall vision of the creator and the needs of the end user to determine exactly what the product should be and what it should ideally accomplish. Some of the main concerns of requirements engineering involve questions such as what customers will most likely want from their products, what resources or instructions users will need to use their products, and what effect the product will ultimately have on its users.

Overview

The process of requirements engineering involves a variety of steps. Generally, the first step is inception, a time when engineers broadly define the new product, such as its overall nature, goals, and intended scope. For example, during this step, engineers should explain the problem that the new product is intended to solve and discuss how this will occur.

During inception, planners usually “start from scratch” and answer the most basic questions, such as what kinds of people will likely want the product and what benefits they expect to gain from the product. A thorough plan will address many types of people, ranging from the engineers and managers involved in the design and creation of the product to its ultimate customers and end users, and ensure that all their needs will be met.

After inception comes the stage of elicitation, a more detailed examination of the requirements for the new product. During this stage, requirements engineers often meet with various stakeholders in the product to discuss their visions for the product and process. At this point, engineers should list all the expectations of the stakeholders and the resources that will be necessary to accomplish the task at hand.

In the next stage, elaboration, requirements engineers analyze the requirements data they have gathered during the inception and elicitation stages. This data must be refined and expanded to include more details and clear demonstrations of how the product will ultimately work. During elaboration, engineers often produce models of the product that serve to show its basic functions. This model must satisfy the stakeholders before the project can continue.

A negotiation stage generally follows the elaboration. During this stage, engineers set out the priority requirements and other plans for the project. Stakeholders may analyze these plans and present conflicting views during this time. Requirements engineers are challenged to study any conflicts that arise and negotiate solutions that please all stakeholders. One tried-and-true method of negotiation involves a system of “priority points” that stakeholders may assign to requirements of their choice. Engineers then can focus on the most important priority requirements and potentially deemphasize others.

In the specification stage, engineers gather all the information, revised and improved through negotiation, into a final design for the new product. The product may not be technically produced at this point; however, engineers must at least have a completed model or prototype to show the exact nature of the product to be manufactured.

The next steps, validation and management, occur after the product has been specified. In the validation stage, the product and its various requirements are carefully analyzed. Requirements engineers assess whether the materials are clear, consistent, and accurate, and whether all stakeholders understand their details. Engineers seek to ensure that the requirements and products meet the highest possible level of quality during this stage. In the management stage, engineers set out plans to control any potential future changes in the requirements.

These steps generally go in sequential order, but in many cases they may overlap. For example, the negotiation step does not occur just once through the process, but generally accompanies many, most, or all of the steps. Similarly, management is required through the entire process, not just at the end. There is no one definitive way to perform requirements engineering, and users find that a great deal of customization is usually needed to make the process applicable to a given goal. In many cases, steps will necessarily overlap, or will need to be repeated or reorganized to address problems with the product or its creation.

One of the most important factors in requirements engineering is ensuring that the requirements in question are measurable. General demands such as “make the product better” or “increase product quality” would be difficult to quantify and therefore not useful for requirements engineering. Instead, planners should identify specific requirements and determine ways that these requirements may be tested and the criteria by which they can be judged.

For example, requirements engineers might seek to increase the reliability of a product. In this case, they might measure reliability by how many of the products are likely to fail or how long it would most likely take them to fail. Finding that many products are likely to fail in a short time would strongly suggest a poorly executed product. Engineers might measure the user-friendliness of a product by the length and level of detail of its instructions or training programs, or the overall time likely required by an average user to learn to use the product successfully. Other criteria of requirement that can easily be measured include durability, portability, speed, and size.

Bibliography

Dick, Jeremy, et al. Requirements Engineering, 4th ed., Springer, 2017.

Elgabry, Omar. “Requirements Engineering: Introduction (Part 1).” Medium, 13 Sept. 2016, medium.com/omarelgabrys-blog/requirements-engineering-introduction-part-1-6d49001526d3. Accessed 9 Jan. 2019.

Herlea, Daniela Elena. “Users’ Involvement in the Requirements Engineering Process.” University of Calgary, ksi.cpsc.ucalgary.ca/KAW/KAW96/herlea/FINAL.html. Accessed 9 Jan. 2019.

“Requirements Engineering.” MITRE Corporation, www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering. Accessed 9 Jan. 2019.

"Requirements Engineering Process in Software Engineering." Geeks for Geeks, 24 July 2024, www.geeksforgeeks.org/software-engineering-requirements-engineering-process/. Accessed 20 Nov. 2024.

“Requirements Engineering.” Technopedia, www.techopedia.com/definition/21697/requirements-engineering. Accessed 9 Jan. 2019.

Sommerville, Ian. Requirements Engineering: A Good Practice Guide. John Wiley & Sons, 2009.

“The Steps in Detail.” University of Cape Town, Jan. 2011, www.cs.uct.ac.za/mit‗notes/software/htmls/ch03s04.html. Accessed 9 Jan. 2019.

“What Is Requirements Engineering?” University of Cape Town, Jan. 2011, www.cs.uct.ac.za/mit‗notes/software/htmls/ch03s03.html. Accessed 9 Jan. 2019.