primary measure of success of a software system is the degree to which it meets
the purpose for which it was intended. Broadly speaking, software systems
requirements engineering (RE) is the process of discovering that
purpose, by identifying stakeholders and their needs, and documenting these in
a form that is amenable to analysis, communication, and subsequent implementation.
There are a number of inherent difficulties in this process. Stakeholders
(including paying customers, users and developers) may be numerous and
distributed. Their goals may vary and conflict, depending on their perspectives
of the environment in which they work and the tasks they wish to accomplish.
are two major types of requirements:-
are statements of services the system should provide, how the system should
react to particular inputs, and how the system should behave in particular
are constraints on the services or functions offered by the system. They
include timing constraints, constraints on the development process, and
constraints imposed by standards
requirements engineering process includes:-
a) A feasibility study.
It is the practical extent to which a
project can be performed successfully it is performed to determine whether the
solution considered to accomplish the requirements is practical and workable in
the software. Information such as resource availability, cost estimation for
software development, benefits of the software to the organization after it is
developed and cost to be incurred on its maintenance are considered during the
feasibility study. The objective of the feasibility study is to establish the
reasons for developing the software that is acceptable to users, adaptable to
change and conformable to established standards (Dinesh Thakur, 2018).
b) Requirements elicitation and analysis.
process comes immediately after the feasibility study is complete.
It’s a process of interacting with customers and end-users to find out about
the domain requirements, what services the system should provide, and the other
constrains. It starts by gathering the requirements, this could be done through a
general discussion or interviews with your stakeholders, and also it may
involve some graphical notation. Then you organize the related requirements
into sub components and prioritize them, and finally, you refine them by
removing any ambiguous requirements that may raise from some conflicts (Omar El Gabry, 2016).
software requirements specification (SRS) is a comprehensive description of the
intended purpose and environment for software under development. The SRS fully
describes what the software will do and how it will be expected to perform. An SRS minimizes the time and effort required by
developers to achieve desired goals and also minimizes the development cost. A
good SRS defines how an application will interact with
system hardware, other programs and human users in a wide variety of
real-world situations. Parameters such as operating speed, response
time, availability, portability, maintainability, footprint,
security and speed of recovery from adverse events are evaluated.
(Margaret Rouse, 2018).
products produced from design and the SRS are examined for consistency,
omissions, and ambiguity. The basic objective is to ensure that the SRS
reflects the actual requirements accurately and clearly (Dinesh Thakur, 2018).
It is defined as a process of
eliciting, documenting, organizing, and controlling changes to the
requirements. (Dinesh Thakur,
Objectives of the study
The objectives of conducting writing this paper
Ø To identify the importance
of requirements engineering in the software development lifecycle.
Ø Types of requirements and
their relevance in Software Engineering.
Ø Understand the principal
requirements engineering activities of elicitation, analysis and validation,
and the relationships between them.
Ø The challenges faced during
Research methodology is the
systematic, theoretical analysis of the procedures applied to a field of study
(Kothari, 2004). Methodology involves procedures of describing, explaining and
predicting phenomena so as to solve a problem; it is the ‘how’; the process, or
techniques of conducting research. A Methodology does not set out to provide
solutions but offers the theoretical underpinning for understanding which
procedure, set of procedures can be applied to a specific case (KENPRO, 2012).
Data Collection techniques and Participants
involves the tools that will be used to conduct research pertaining the
requirements engineering. The following methods will be used to collect data;
oral questions was used to obtain data about the process of requirements
engineering. The developers were asked questions concerning importance of
requirements engineering in the software lifecycle, types of requirements and
their relevance in system development, and the challenges they faced during the
requirements engineering process.
development activities was observed keenly to identify the possible reasons why
requirements engineering is important.This procees aimed at understanding all
processes stated at the beginning of this research paper.
are a lot of journals, books and articles discussing requirements engineering.
This involved obtaining data from already existing sources on the information
about requirements engineering process.
to new research, success in 68% of technology projects is not likely to happen.
Poor requirements analysis causes many of these failures, meaning projects are
doomed right from the start. (Michael Krigsman, 2016)
Requirements has been used
in software engineering society since 1960. Poor
requirements are a well-known key root-cause for challenged and failed software
projects (Matsugu B, 2012).
Examples of related work
There has been lots of research done in requirements
Frauke Paetsch, Dr. Armin
Eberlein, Dr. Frank Maurer in their research paper Requirements Engineering and
Agile Software Development, their paper compared traditional requirements
engineering approaches and agile software development. They also analyzed commonalities and differences of both approaches and
determined possible ways how agile software development can benefit from
requirements engineering methods.
Jarke and Pohl (1994)
identified three phases in the Requirements Engineering process – elicitation,
expression, and validation. Davis (1995) described two distinct Requirements
Engineering phases, referred to as problem analysis
and product description. Similarly, Sawyer et al (1996) proposed a four-phased
generic model, consisting of discovery, analysis, negotiation, and
specification. Nuseibeh and Easterbrook (2000) have defined a five-phase
process consisting of Requirements Elicitation, Modeling and Analysis,
Requirements Communication, Agreement and Evolution. Other classifications of
the Requirement Engineering activities were given by Krasner (1989) and Leite
(1998). Thayer (1997) divided Requirements Engineering into five phases, namely,
Elicitation, Analysis, Specification, Verification, and Management. The
five-phase model, is perhaps the most widely-accepted. In this model, the
requirements generation process starts by eliciting user goals and needs.
Elicited information is then analyzed and modeled to describe the requirements,
which is then formally documented. Management is a continuous process to
maintain the integrity and consistency throughout all requirements generation
phases. Pohl’s (1994) innovative perspective on the Requirements Engineering
process, helps understanding the complexity of the process and its boundaries.
Pohl visualized the Requirements Engineering process as a journey in a
three-dimensional space in which the three axes are Specification,
Representation and Agreement
RE is an essential process in
software development lifecycle. It ensures that both the developer and the
stakeholder/user are on the same page that is the developer develops the exact
same thing that the user really expected. For any system to be developed, the
developers and users have to work closely together in order to ensure the
success of the project, failure to do so results in project failure.
According to (Ian Sommerville,
2011) there are only two types of requirements:
User requirements are statements, in a natural language plus
diagrams, of what services the system is expected to provide to system users
and the constraints under which it must operate.
requirements are detailed description of a software system functions. They
can be categorized as:-
Ø Functional requirements
Product requirements are requirements specify or constrain the behavior
of the software.ie performance, availability, and security.
Organizational requirements are requirements are broad system
requirements derived from policies and procedures in the customer’s and
External requirements are all requirements that are derived from factors
external to the system and its development process. These may include
regulatory requirements that set out what must be done for the system to be approved
for use by a regulator.
From the interviews conducted, RE
is mainly composed of four processes that are already stated in the
introduction of this paper. The processes are done systematically one after the
other. Based on the system methodology used for software development, RE comes
at different stages for example in the waterfall model it’s the first process.
The challenges faced by developers
when doing RE are very many. They include:-
Requirements keep on changing.
Stakeholders often don’t
know what they want from a computer system except in the most general terms;
Stakeholders in a system naturally express
requirements in their own terms and with implicit knowledge of their own work.
Different stakeholders have different
Conflicting requirements are sometimes provided
by the users.
The importance of RE are:-
RE process ensures the users of get a system
they really expected from the development team.
It also ensure that the developers develop a
system that will be usable by the users.