Requirements Engineering: A Beginner’s Guide

If we were to give you an analogy for requirements engineering, we’d probably say that in most cases, it’s like a game of Chinese whispers. Omar Elgabry, a software engineer by profession, wonderfully demonstrates the ‘ugly truth’ of software engineering (as he calls it):

In this blog, we’ll look at everything that you need to know about requirements engineering –from what it is to how you can establish a rock-solid requirements management process. Let’s jump right in.

What Is Requirements Engineering?

“The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No part of the work so cripples the resulting systems if done wrong. No other part is more difficult to rectify later.”
Frederick P. Brooks, American Computer Architect

Requirements engineering is one of the most vital steps in the software development lifecycle. It includes identifying, recording, and preserving the specifications of the engineering design process.

It offers an effective platform for identifying the wishes of the client by evaluating their requirements, determining its viability, discussing and defining a fair solution, verifying the criteria, and handling requirements as they are converted into a working system. As such, it can be described as the structured implementation of established principles, procedures, and notations to explain the intended behavior of the suggested system and its relevant constraints.

The requirements engineering process is critical since it emphasizes determining whether the system is beneficial to the organization, determining requirements, translating those requirements into a standardized format, and ensuring that they reflect the system that the client desires. The requirements engineering process takes place across four activities, which are:

• requirements elicitation & analysis
• requirements specification
• requirements verification & validation
• requirements management

Although the process involves phases, requirements engineering is not chronological. It is a frequentative process, wherein activities are conducted iteratively and are interleaved as design proposals are formulated throughout the development lifecycle. All four of them are carried out repeatedly because the needs are often difficult to understand until after a system is built.

Unlike the process of software engineering, requirements engineering consists of a number of operations that link, engage, and direct each other to a full lifecycle of requirements engineering. This cycle starts with a feasibility study that lays out the motives for designing the application/software on the grounds of its acceptability by users, how flexible it is to change, and its compliance with existing standards.

Feasibility Study: Importance and Its Types
The foremost step in the requirements engineering process, the feasibility study, revolves around understanding the need and necessity of the proposed system that is used to evaluate the viability of the proposal, such as ensuring that the concept is judiciously and technically achievable, as well as economically justifiable.

It allows the company to ascertain if the initiative is likely to work in the first place and is usually carried out before any measures to move ahead with the project are taken. The report describes the project’s market, outlines key priorities according to market-based research, points out possible obstacles, proposes viable alternatives, and factors key requirements (time, budget, and workforce) to assess if the project is feasible and valuable, to begin with.

In addition to this, the feasibility study gives the stakeholders a clear picture of the project and:

• Helps identify new prospects
• Narrows down business alternatives
• Defines a compelling reason for pursuing a project
• Improves the rate of success by examining several factors
• Aids the decision-making process
• Outlines reasons not to proceed

The feasibility study is, therefore, a crucial factor in the validity of the research for prospective investors and financial institutions. There are five distinct kinds of feasibility studies — separate domains that are explored in a feasibility study:

Technical Feasibility
A significant part of the estimation of the assets needed for a project is related to the evaluation of technological feasibility. Technical feasibility examines the current technologies that are required to satisfy client needs within the proposed timeline and allocated budget.
It addresses the technical specifications of the proposed project, which are then compared to the technical capability of the organization. The systems project is deemed technically feasible if the inherent technological capability of the company is adequate to meet the requirements of the project.

Operational Feasibility
Operational viability includes conducting a study to evaluate and ascertain if —and how well—the goals of the company can be fulfilled by executing the project. Operational feasibility also assesses how the project plan meets the specifications defined in the requirements review process of system development.

Economic Feasibility
Economic feasibility determines if the required software will produce net profits for the organization or not. This feasibility research division is most commonly used to test the efficacy of a new method. In this division, the method is to assess the expected profits and gains from the candidate system and to equate them with the expenses. If the advantages exceed the expenses, the decision to design the system is taken.

Legal Feasibility
This assessment examines whether some component of the planned project is in dispute with regulatory obligations such as zoning legislation, data security legislation, or social media legislation.

Scheduling Feasibility
This evaluation is, by far, the most crucial for the success of the project. It decides if the project will fail or be completed successfully ahead of time. As part of the scheduling feasibility, the company calculates how long the project will take to finish.
After all these aspects have been explored, the feasibility assessment helps to define any restrictions that the proposed system can face, including:

• Internal Project Constraints: Strategic, Infrastructure, Budget, Capital, etc.
• Internal Corporate Constraints: Economic, Marketing, Export, etc.
• External Constraints: Infrastructure, Environment, Rules, and Regulations, etc.

The Requirements Engineering Process
Whenever an organization decides to enter into an agreement for a software development project, it describes its requirements in a reasonably abstract sense that a solution is not predefined. The specifications are composed in such a way that several vendors can compete for the project, providing various ways of fulfilling the expectations and desires of the client organization.

When the contract is awarded, the contractor formulates a conceptual system definition for the client in a manner that is more circumstantial and elaborate to help the client understand and verify what the software can do. Both of these documents are referred to as the system’s requirements document and consist of:

• User Requirements
• System Requirements

User Requirements
The user requirements define the intended services of the system and the restrictions on achieving them. It is written in a manner that can be understood by people who do not have the requisite technical skills and background knowledge.
These specifications are usually determined by the external actions and behavior of the system and are never determined on the basis of system design and execution. As such, it is normally composed of natural language and is supported by diagrams.

System Requirements
System requirements are fundamental principles that are to be pursued in order to design the system’s architecture. They include a more thorough overview of the system’s services, operational constraints, and constraints with respect to development.
In order to know the exact implementations and provisions of the proposed framework, the software engineer analyzes these criteria and classifies them into further two types, which are:

Functional requirements:
Functional requirements outline fundamental system behavior and system expectations. These specifications depend primarily on the system’s users and the software application that is being created.

When articulated as user requirements, they are typically defined in an abstract sense and describe:

• What the system is supposed to do
• How should it respond to a specific input
• What the system is not expected to do
• Constraints on the execution of the aforementioned specifications

Functional requirements are characteristics that allow the system to work as expected. In other words, the system will not operate in an intended manner if the functional specifications are not met. Functional requirements are product characteristics and concentrate on user requirements.

Non-functional requirements:
Non-functional requirements describe system characteristics such as security, efficiency, reliability, scalability, maintenance, robustness, and usability. They act as limitations or limits of the system’s design across different backlogs.

Although functional requirements determine expectations from the system, non-functional requirementsdefinehowthesystemshouldgoaboutit.Non-functionalrequirementsdon’timpactthe core functionofthesoftware,hencetheirname.Evenifnon-functionalrequirementsaren’tmet,the systemwillstillserveitsintendedobjective.

There as on behind the importance of non-functional specifications is because they describe the features, system behavior, and specific attributes that influence the user experience. How well non – functional criteria are identified and implemented defines how convenient the software is to use. It is thus used as a yardstick to measure the system’s performance. Non-functional specifications are product properties and concentrate on user expectations.

Following a feasibility analysis and assessment of the device and user specifications, the results are registered in a feasibility report. This report advises whether or not to move to the next phase. The following phase consists of four iterative steps, as enumerated above, which we will se e in brief detail.

Step 1: Requirements Elicitation & Analysis
Requirements elicitation and analysis includes assembling the project’s requirements. This step involves a collaboration between the technical resources of the company, such as system engineers and software developers, and the system users (customers).

The aim of this discussion is to identify the domain specifications, the intended services of the system, and other limitations. It examines multiple sources, such as clients, company manuals, current and similar applications, standards, and other project stakeholders, to derive the required domain & specifications knowledge.

The strategies implemented for requirements elicitation involve interviews, discussion groups, facilitated application specification techniques (FAST), quality function deployment, and use case approaches. Elicitation does not generate sophisticated models of the identified specifications. Instead, it broadens the analyst’s domain awareness and allows to provide input for the next phase.

Requirements for elicitation and analysis comprise four main processes. There are:

• Requirements discovery
  It is the procedure of communicating with and gathering the specifications from the stakeholders about the desired system.
• Requirements classification and organization
  This process includes piecing associated requirements together and dividing the structure into sub-components. Once this is done, the interrelation between these components is established.
• Requirements prioritization and negotiation
  This process focuses on prioritizing requirements and identifying and resolving contradictory requirements through negotiations before you enter a situation where certain stakeholders will compromise.
• Requirements specification
  It is the method of writing down user & system requirements and recording them into a document. The requirements must be simple, e asy to understand, detailed, and reliable.

Step 2: Requirements Specification
As described above, the steps involved in requirements engineering steps are interleaved within each other as and when design systems are proposed during the development lifecycle. In the first iteration, one defines user requirements and then moves to specify more specific system requirements.
Once you have defined user and system requirements, you can move to specify them. While there are several ways to do this, the two most popular ones are natural and structured language specification.

Natural Language Specification

It is a method of writing requirements in clear text and doesn’t follow a default or specified format. The method includes following a few guidelines to mitigate any misunderstandings that might happen as a consequence of the ambiguity of the natural language.

• Create a format of your own for writing the specifications.
• Establish the exact systems required to satisfy the requirements.
• Underline the important keywords.
• Don’t utilize abbreviations and acronyms. If you should, add an appendix that lists out the abbreviations and acronyms according to your specifications and their relevant meaning.

Structured Language Specification
A more restricted form of natural language, structured language specification involves a more formal and structured expression of requirements. This eliminates a few issues arising from complexity and versatility and imposes a measure of uniformity on a specification.

It utilizes generic models to define the requirements. These may be organized around the activities or functions performed by a system and may include:

• Defining the entity or the function
• Describing inputs and where they originate from
• Describing outputs and where they must go to
• Indicate the necessity of other required entities
• Pre and post conditions
• The side effects

Step 3: Requirements Verification & Validation
Requirements verification and validation are separate processes that are implemented in unison to ensure that the system, service, or product meets the requirements and fulfills its intended function.

It is a method of ensuring that the prescribed specifications fulfill the expectations of the consumer. It is concerned with determining issues with the requirements since any lapse in this may lead to substantial rework costs when they are found at a later, more critical period or when the system is in operation.

Usually, verification and validation specifications are considered to be one and the same; however, this is not the case. Validation of the requirements is the process of analyzing the adequacy and effectiveness of the requirements and ensuring that they:

• meet specified business goals
• achieve the expectations of the stakeholders
• are transparent and understood by the developers

Validation of requirements is inherently crucial to the success of a project as it helps identify missing requirements and guarantee that the requirements follow specified quality attributes. It tackles each independent requirement to make sure that they are:

• Accurate: describes the customer’s needs precisely
• Clear: has only one reasonable interpretation
• Practical: can be applied within established constraints
• Adjustable: can be modified quickly if necessary
• Necessary: records things that clients really need
• Graded: prioritized according to the value of product inclusion
• Traceable: can be associated with system specifications and designs, codes, and checks
• Verifiable: the appropriate implementation can be decided by evaluation, examination, review, or demonstration

Requirements verification, on the other hand, is the method of ensuring that documented requirements have been completely addressed by the designed and built product. It consists of conducting numerous checks, evaluations, and analyses over the product’s lifecycle to make sure that the iterations, designs, and the completed product comprehensively address all the requirements.

Requirements should be verified and authorized prior to design to avoid redesign. If the specifications are not checked in time, the requirements validation and verification will eventually be carried out simultaneously during the product’s development process activities and will lead to incomplete or defective requirements not being identified in time, thus resulting in revisions and considerable cost overruns.

The expenses of solving a requirement problem by implementing a system change are typically much larger than correcting code or design errors since a rework of the specification generally means that t he formulation and implementation must both be modified and reassessed. During the validation phase of the specifications, various types of tests must be conducted on the requirements. These checks include:

• Validity checks: The roles suggested by stakeholders must be consistent with the expectations from the system so that no new or discrete functions are needed later.
• Consistency checks:The requirements in the document do not clash with or define the same role differently.
• Completion checks: All specifications and limitations should be included in the contract.
• Realism checks:Makes sure that the specifications will actually be enforced using the information of current technologies, budget, timetable, etc.
• Verifiability:The specifications must be constructed in such a way that they can be checked. This means that it should be possible for you to design a series of tests to prove that the system meets the defined specifications.

Step 4: Requirements Management
While it is generally understood in the software industry that the key to producing great products is to get requirements “right,” there is often discord among stakeholders among what “right” really means. This means there is generally lower consensus among them on the best way to get to the “right” requirements.

This is where requirements management comes in. The role of requirements management is to make sure that the objectives of product development are successfully met. This is achieved by offering a collection of strategies for recording, reviewing, prioritizing, and accepting specifications, so that system & software engineers always have updated and approved requirements.

Requirements management provides a way to prevent mistakes by tracking alterations in requirements and facilitating contact with stakeholders from the outset of the project and throughout the software development lifecycle.

A requirements management plan aids you in clarifying how you can obtain, evaluate, record, and handle all of the project’s requirements. The strategy typically encompasses everything, from the preliminary compilation of high-level project details to much more comprehensive product specifications that may be obtained during the project’s lifecycle.

The key things to be identified in the requirements management plan are project description, the process of gathering requirements, roles and responsibilities, resources, and traceability. A traditional requirements management process supplements the engineering model of the system through the following steps:

• Assemble the essential needs of stakeholders
• Evaluate the specifications
• Specify and record requirements
• Rank and prioritize requirements
• Accept and authorize requirements
• Trace authorized requirements to job items
• Interrogate stakeholders following the implementation process on the necessary changes to the requirements
• Use test management to check and confirm device specifications
• Test the effects of the changes
• Alter requirements
• Record the changes

Closing Thoughts
It’s not that difficult to incorporate requirements engineering as part of your software development process. It is, however, necessary to find the right time to set it up properly. It needs careful preparation and gives you new ways to improve the software development process by removing unwa rranted and inefficient activities/inputs. Thus, defining and reviewing the requirements at the beginning of each new project will help you avoid debates about new concepts at its end.

Related Article:
1. Requirements Management Plan