Abstract—Requirement engineering; requirement verification and validation I. Introduction

Abstract—Requirement Engineering
Process is very important in software development. It is a base for designing,
creation and finalization of any purposed software. Process of Requirement
Engineering is not only collecting Requirements, but also a complete systematic
way of organizing, analyzing, negotiating, capturing, restructuring, managing,
controlling, redesigning, writing and finalizing all information and
requirements which are needed in any phase of the software development. Because
of multidimensional nature of requirement engineering, there may be lot of
areas needs to be improved and resulting into more effective and accurate
results in software engineering. In this presented article, an over view of
software requirement engineering process and its related problematic areas are
highlighted for software development professional, information seekers and

Keywords—requirement engineering; requirements; requirement
elicittion; requirement engineering process; problems in requirement
engineering; software development process; problem areas in software
requirement engineering; requirement verification and validation

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!

order now

I.      Introduction

Software Engineering is a process of software development
life cycle and a systematic way of designing software with its all targeted
requirements and goals. Providing a big scope of collecting, analyzing, arranging
all the information by means of negotiation, domain study of problem area,
observations, and methodology of information gathering. It is not a process of
getting some information about software requirements, but a systematic way of
collecting desired required information which leads to a strong foundation for
a comprehensive software design and all related task completions. There are
several stages in software requirement engineering process and various research
areas like Reuse Engineering, Object Oriented Software Engineering, Empirical
Software Engineering, etc. Because of the nature of Software Engineering
Process it depends on several tasks and stages, and there are many of them
needs to be improved to get better results of software engineering process.

This process involve main seven stages starting from
Inception, Elicitation, Elaboration, Negotiation, Specification, Validation and
end with Requirement Management fig(). To produce quality software it is
important to implement software requirement engineering process carefully, it
is observed that most of software problems are actually related to requirement
engineering process. Main factors identified in requirement engineering process
are incomplete requirement and specification, changing requirement and
specification and lack of user inputs. Requirement engineering is an iterative
process and many activities are performed not up to mark resulting into poor
requirements gathering, these issues must be identified and must be reduced to
produce more accurate requirements. This paper provides an overall picture of
requirement process and issues/risks attached with each activity in requirement
engineering process.




II.    preconditions
for effective requirement engineering

Before devoting extensive efforts and resources in requirement engineering, it
is important to satisfy some essential precondition to protect final results
from disorganized requirements. In other words, developer must walk before
running. For effective requirement engineering process, it is clear that
documented development process and rigorous cost management is essential
factor. There is no simple and straight method available for these activities,
all these activities require complex, focused, iterative, systematic, organized
and well managed.

Assessment. This
area has been brought to general attention
in the literature on software process maturity (Humphrey,
1988). We learn from research that most important area in requirement
engineering is interlocking.

III.   components
of requiremen engineering process

A.    Role
of Modeling in Requirement Engineering Process

There is several process models are used in Software
Engineering process, a simplified description of a process presented from a
perspective. There is some advantages and disadvantages attached to each
process model, to improve overall results from requirement engineering process
first understand and highlight some main factors related to each model used in

Waterfall Model

Coarse-grain Activity Model

Spiral Model

Fine-grain Activity Model

Role-action Model

Entity-relation Model


By the use of appropriate model of process according to
given scenario and problem domain area, we can get a complete overview of the
ongoing process activities related to problem.

Waterfall Model
provides a complete picture of the requirement engineering process as steps of
down flow of activities. By the use of this model one can capture the stages of
overall process and their respective importance in complete process with incoming
flow to outgoing flow at any activity stage. It is very risky to use this model
in a changing problem domain study, because of the nature of model because it
is difficult to come back to previous activity in model.



Activity Model provides complete detailed activity diagram for requirement
engineering process and its related sub activities resulting into a complete
structural view of the process. It is helpful in problem domain where detailed
study of the problem is required, one can capture requirement activities chart.



          Spiral Model is one of the most
important models of requirement engineering process. Because of its iterative
and spiral nature it plays an important role in Requirement Engineering
process. One can use it in problem domain study where requirements are changing
with time to time and needs to be updated according to required intervals of
time. by using this model we can redesign and rearrange our required
information and may reduce the conflicting and unacceptable thins.



Fine-grain Activity
Model is a detailed model of a specific process used to understand and
improve existing processes. In depth study of problem and related tasks are
done using this type of model. To remove internal micro factors of mistakes in
requirement engineering one can use this model.

Role-action Model
is very important to understand the role of different peoples involved in the
process and associated action they may take. Providing stake holders view of
the problem domain study and related requirement engineering activities.

Entity-relation Model provides process inputs, outputs,
and all intermediate results with all associated relationships between them.
This type of model is very useful in quality management systems.


B.    Requirements
Engineering Activities

Requirement Engineering is a complete systematic way of
organizing, analyzing, negotiating, capturing, restructuring, managing,
controlling, redesigning, writing and finalizing all information and
requirements which are needed in any phase of the software development.

C.    Organisational

Requirement engineering process may take place in many organizational settings.
The development process may be: internal to an organization, where the system
is being produced by that organization for its own use; bespoke, where a client
requests another organization to produce a system specific to its requirements;
customization in which some generic product or framework is tailored to meet a
set of requirements set down by an external client; cooperative in which
knowledge of the application, the requirements, and the eventual use of the
system is distributed among different organizations who are partners in a
development process; product oriented in which an organization develops a
product to be placed in a perceived market. Each of these settings confers
slightly different responsibilities and in each case suggest different
technical priorities.

      Assessment. The issue of organizational
context and its
ramifications for the organization of system development
has, until recently (Jones & Brooks, 1994), been neglected
in software engineering. The information systems
community has, by contrast, recognized this issue (Yadav,
1983) and has attempted to make the assumptions about
organizational context, on which methods and techniques
depend, explicit. Broadly the dominant view from within
software engineering has been fixed on bespoke
development. This is largely because this type of
development is characteristic of the defense organizations
and contractors who have been most articulate about their
difficulties and who have funded software engineering

Issues. There is a growing recognition of the importance of
system customization and extension (Lubars et al, 1993)
cynics might suggest that this reflects the tougher stance of
defense procurement agencies. There is virtually no work on
the support for developing products for markets though this
concern is surfacing within general debate, in particular
through large telecommunications organizations who, since
deregulation, now deliver services into a global competitive

D.    Fesibility
and Risk

Orientation. In requirement engineering process there is a
chance of many infeasible requirements. Mostly these are the requirements where
benefit is less the cost to establish the requirements or where the satisfying
the requirements is prima facie, unethical or contrary to the lay of science.
It is very important to assess the associated risk with each part of the
development in order to provide required or sensible allocation of effort to
the all aspects of development.


E.    Stakeholders

Orientation. Stakeholder’s
analysis is a process of identifying the roles or individuals which are
involved in requirement engineering process or contribute to overall outcomes
or concerned with proposed system under development. The analysis of
stakeholders involves understanding their responsibilities, capacities and the
organizational relations between them.



Oversee the procurement
of the system or product


Oversee the system’s
conformance to standards and legal regulation


Explain the system to
other stakeholders via its documentation and training materials


Construct and deploy
the system from specifications (or lead the teams that do this)


Manage the evolution of
the system once it is operational

Production Engineers

Design, deploy, and
manage the hardware and software environments in which the system will be
built, tested, and run


Build and/or supply the
hardware, software, or infrastructure on which the system will run

Support Staff

Provide support to
users for the product or system when it is running

System Administrators

Run the system once it
has been deployed


Test the system to
ensure that it is suitable for use


Define the system’s
functionality and ultimately make use of it


F.    Information

Orientation. One
of the most difficult and complicated task in requirement engineering process
is information gathering. Information needs and wants according to the related
environment and domain of the problem under study. Gathered information may document,
or held by some expert or buried into in the work practices. There are now several requirement engineering techniques
available for information retrieval in this process.

text and document analysis. Techniques suc as repertory grids have been drawn
from area of knowledge acquisition. An interesting emergent area is the use of ethnographic
and associated “observational” methods.


G.    Domain

It is important
to understand the environment in which the projected system will reside. Model of
the environment must be constructed according to the domain. Model must be in
form that the interaction between system and environment can be defined.


          Use of domain modeling is multiple in
many aspects, in common use it is the modeling of application domain in which a
class of related system will be built.
I am employing a less conventional use of the term,
that of modeling the “domain” objects with which a
targeted system will interact. Clearly there is an
overlay between these usages. The main charities to this area are the
object-oriented analysis methods for example Rumbaugh et al. (1991).


          A practical problem in this area is
deciding among
the various approaches and associated modeling schemes that have been proposed.
As yet no clear means of assessing these proposals has developed. A number of
interesting approaches to the identification of domain objects have been proposed
mostly based on the use of events and scenarios (Jacobsen et al, 1992). This
seems an important and fascinating area for further research.


H.    Analysis
of Task

Orientation. Most systems interact with
humans. It is
important therefore to identify these people and understand
the tasks that they perform using the system. This model can be used to forecast
the problems they might encounter and to suggest ways in which the interface to
the system can be organized to have a better fit with their tasks and the way
in which they recognize the system and its properties.


Assessment. In some sense much of the
work carried on under the heading of task analysis mirrors other modeling
carried out in requirements engineering. The difference is in the modeling
focus and in the type of analysis to which these models are subject (to determine
user based notions of consistency, complexity, and so on). A reasonable review
is given in Johnson (1992).

Issues. Task analysis has largely
been of concern to the user interface design community and the techniques which
have arisen from it have, with some notable exceptions (Lim et al, 1990), not
been treated as part of a larger systems engineering process. Work on method
integration is required and may yield substantial economies as information collected
in task models is obtainable elsewhere in the requirements engineering process.
Further work on identifying relevant aspects of human task performance that can
be derived from task models is also required.


I.      Reuse
in Requirement Engineering

Orientation. It might be assumed
from the discussion above that requirements engineering is always done de novo.
This is, of course far from the case. There is always a scope for reusing both the
products and process of requirements engineering from previous exercises on
requirement engineering and for organizing the process of requirements
engineering so as to enhance the opportunities for successive reuse.

Assessment. Obviously the use of modeling
employing inheritance or the like, which are capable of
supporting reuse have attracted attention within requirements engineering. The
most significant application of these schemes has been in the specification of
“families of systems”, where rather than setting down the
requirements for a single system, the system is seen as an member of a family
or class of related systems which share goals, services, domain models, and so
on (Garlan, 1989). There is some evidence that for narrow domains with small
variants, this approach may yield dividends, at the higher level however
(Reubenstein & Waters, 1989) it is unproven. An interesting development in
this area is the use of case-based techniques for example Maiden &
Sutcliffe (1992).

Issues. I must confess to skepticism
about reuse in
requirements engineering. This stems from a basic
discomfort about the overall idea of reuse in the context of
requirements (as distinct from design) and broader research strategy worries
about treating with reuse before we have established practice for use. I feel
effort is better spent in the weak link of reuse – giving developers the
ability to rapidly integrate and understand the documents and models produced by
others. Given that my doubt is unlikely to turn the tide of work on reuse the
research issues are the construction of significant case bases and generic
domain models for genuine domains.

J.     Validation
in Analisis

Assuming that the acquisition and modeling
processes are imperfect, it is important for some validation of the products of
the requirements engineering process is required. That is, they must be analyzed
in order to establishing the extent to which they accurately embody the
requirements. Where there is a incompatibility between the idea of the
stakeholders and the requirements as documented this must be ironed out.

Assessment. The bulk of the work on validation has
concentrated on exploration and inspection which are
discussed separately below. Much of the remainder has
concentrated on providing modelling schemes which are, in some sense, easy to
validate (graphical languages and so on). Other work relevant to validation
includes the use of
scenarios (Benner et al, 1992) and specification animation (Finkelstein &
Kramer, 1991). Work on tools which allow multiple views and browsing of complex
document and model structures are also significant (see information management below).
Alternative directions are suggested by work on specification critiquing (Fickas
& Nagarajan, 1988) and on annotation schemes for marking errors in
specifications (Finkelstein, 1992).

Issues. Ideally validation should be as tightly tied to and
interleaved with requirements production as possible.
However organisational factors can intervene to prevent
this. In such cases the validator may be faced with large
amounts of information and no guidance on how to proceed or what questions to
ask. Research on methods for providing such guidance and on developing
interesting or relevant questions to ask of the products of requirements
engineering would be valuable.