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.