An In-Depth Study on Requirement Engineering

Shared by: ijcsis

Stats

views:: 102
posted:: 12/4/2010
language:: English
pages:: 11

Public Domain

Document Sample

(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 8, November 2010

An In-depth Study on Requirement Engineering
Mohammad Shabbir Hasan1, Abdullah Al Mahmood2, Farin Rahman3, Sk. Md. Nahid Hasan 4
1
E-mail: shabbir_cse03@yahoo.com, 2sajibcseofkuet@gmail.com, 3farinrahman.cse@gmail.com, 4auvi_2k5@hotmail.com,
Panacea Research Lab, Dhaka, Bangladesh

Abstract— Software development includes Requirement constrained by a variety of factors outside their control.
Engineering (RE) which is comprised of discovering Based on these characteristics Zave [3] defined RE as:
stakeholders and their need, proper documentation,
communication and subsequent implementation. It can be “Requirements engineering is the branch of
viewed as the most crucial phase as the success of the software
software engineering concerned with the real-
depends largely on it. Requirement Engineering is receiving
increasing attention of the researchers and also people world goals for, functions of, and constraints on
associated with software development. This paper investigates software systems. It is also concerned with the
RE activities in detail followed by some current challenges and relationship of these factors to precise
also proposes some suggestions to overcome these challenging specifications of software behavior, and to their
issues. evolution over time and across software
families.”
Keywords- Software Requirement, Requirement Engineering,
Requirement Elicitation, Requirement Management. This definition is an attractive one as it highlights the
importance of “real world goals” which motivates the
I. INTRODUCTION development of a software system by referring the
Success of a software system is measured by evaluating specifications more precisely. It also refers to the reality of a
how it meets the purpose it was intended and in broad sense, changing world and the need to reuse partial specifications,
Requirement Engineering (RE) is the process of discovering as done by engineers in other branches of engineering.
that purpose through identifying stake holders and their Brooks [4] defined RE as a key problem area in the
needs, refinement of the gathered information, modeling, development of complex, software-intensive systems:
specification and then subsequent implementation. The
system requirements and role allocated to software— “The hardest single part of building a software
initially established by the system engineer—are refined in system is deciding what to build. ...No other
detail. Models of the required data, information and control part of the work so cripples the resulting system
flow, and operational behavior are created. Alternative if done wrong. No other part is more difficult to
solutions are analyzed and a complete analysis model is rectify later.”
created [1]. Donald Reifer [2] describes the software
requirement engineering process in the following way: RE can be characterized as a branch of System
Engineering [5] as it has to encompass a systems level view
“Requirements engineering is the systematic use to deliver some systems behavior to its stakeholders. Again,
of proven principles, techniques, languages, and Zave defined RE as a branch of Software Engineering and
tools for the cost effective analysis, software systems requirements engineering has received
documentation, and on-going evolution of user special consideration possibly due to the abstract and
needs and the specification of the external invisible nature of software with the vast range and variety
behavior of a system to satisfy those user needs. of problems that admit to software solutions.
Notice that like all engineering disciplines, Whether viewed at the systems level or the software
requirements engineering is not conducted in a level, RE is a multi-disciplinary, human-centered process
sporadic, random or otherwise haphazard fashion, and the use of the term Engineering in RE serves as a
but instead is the systematic use of proven reminder that RE is an important part of an engineering
approaches.” process and represents a series of engineering decisions that
lead from recognition of a problem to be solved to a detailed
The Requirement Engineering process may face a specification of that problem followed by anchoring
number of inherent difficulties like: stakeholders may be development activities, so that the appropriateness and cost-
numerous and distributed, their goals may be volatile and effectiveness of the solution can then be analyzed.
conflicting, depending on their perspectives of different The structure of the paper is approximately as follows. In
working environment, goals may be implicit and difficult to sections 2 and 3 we discuss the foundation and some ground
articulate, and, inevitably, satisfaction of these goals may be works needed for requirement engineering respectively.

253 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 8, November 2010

Section 4 discusses about some key issues followed by the requirements elicitation, for instance to analyze
core activities of RE in section 5. Then, in section 6, communication patterns within an organization [13].
challenges of RE activities are analyzed with some Philosophical elements also have an important effect on RE
suggestions. We finish by drawing some broad and as it is concerned with interpreting and understanding of
necessarily speculative and personal conclusions about the terminology, concepts, viewpoints and goals from
future of requirement engineering. stakeholder’s perspective. Such issues become important
while requirement validation, especially where stakeholders
II. FOUNDATION may have divergent goals and incompatible belief systems.
RE activities play a vital role in software and systems They also become important in selecting a requirement
engineering, and there are also many disciplines upon which modeling technique, because the choice of technique affects
it draws. the set of phenomena that can be modeled, and may even
In software development context, an important role is restrict what a requirements engineer is capable of observing
played by Computer Science as theoretical computer science [6].
provide the framework to assess the feasibility of III. GROUNDWORK
requirements while the means of developing software
solution are provided by practical computer science. Here In the software development process, RE is considered
logic provides a vehicle for analyzing software behavior as a front-end activity. Although it is usually the case that
which is acquiescent to formal reasoning to make the requirements change during development and evolve after a
reasoning steps more explicit. Different logics may be used system has been in operation for some time, RE plays an
to express different aspects of a required system. For important role in the management of changes in software
example, temporal logic can be used to describe timing development. Nevertheless, the bulk of the effort of RE does
information, deontic logic to describe permissions and occur early in the lifetime of a project, motivated by the
obligations, and linear logic to describe resources and their evidence that requirements errors, such as misunderstood or
use. A further advantage of specification languages omitted requirements, are more expensive to fix later in
grounded in logic is that they are potentially amenable to project lifecycles [14-15].
automated reasoning and analysis [6]. Before a project can be started, some preparation is
In the systems engineering context, an understanding needed which are categorized as context and groundwork by
and application of systems theory and practice is also Finkelstein [16]. This groundwork includes some
relevant to RE [5]. This includes work on characterizing assessment of project’s feasibility and associated risks needs
systems, identifying their boundaries and managing their to be undertaken, and RE plays a crucial role in making
development life cycle [7-8]. RE also encompasses work on such an assessment. Although it is often possible to estimate
systems analysis, traditionally found in the information project costs, schedules and technical feasibility from
systems world [9]. precise specifications of requirements, risk should be re-
Usually RE activities take place in a human activity evaluated regularly throughout the development lifetime of
system, and people are the problem owner. Therefore, RE a system [17], since changes in the environment can change
needs to be sensitive to how people perceive and understand the associated development risks.
the newly implemented computer-based system, how they Again, RE activities are performed in a variety of
interact, and how the environment of the workplace is contexts, including market-driven product development and
affected by their actions. RE draws on the cognitive and development for a specific customer with the eventual
social sciences to provide both theoretical grounding and intention of developing a broader market. The type of
practical techniques for eliciting and modeling requirements product also affects the choice of method: RE for
[6]. Cognitive psychology provides an understanding of the information systems is very different from RE for embedded
difficulties people may have in describing their needs [10]. control systems, which is different again from RE for generic
Anthropology provides a methodological approach to services such as networking and operating systems [6]. So
observing human activities that helps to develop a richer groundwork is essential for the identification of a suitable
understanding of how computer systems may help or hinder process and also for the selection of suitable methods and
those activities [11]. Sociology provides an understanding of techniques for the various RE activities.
the political and cultural changes caused by computerization.
Introduction of a new computer system changes the nature of IV. KEY ISSUES IN REQUIREMENT ENGINEERING
the work carried out within an organization, may affect the Software development organizations should keep in
structure and communication paths within that organization, mind the following issues when they consider how to
and may even change the original needs that it was built to improve the requirements and communication for their
satisfy [12]. Linguistics is important because RE is largely projects:
about communication. Linguistic analyses have changed the • If teams don’t get requirements right, it doesn’t
way in which the English language is used in specifications, matter how well they execute the rest of the
for instance to avoid ambiguity and to improve project: The goal of every software development
understandability. Tools from linguistics can also be used in project is to build a product that provides value to

254 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 8, November 2010

customers. Effective requirements definition stakeholders. Further teams that can force as much
enables teams to determine the mix of product change at the beginning of a project will have less
capabilities and characteristics that will best deliver change to manage over time [18].
this customer value. An understanding evolves • Teams are never going to have perfect
over time as stakeholders provide feedback on the requirements: Requirements are never finished or
early work and refine their expectations and needs. complete. There is no way to know for certain that
Adequately exploring and crafting requirements teams have not overlooked some requirement, and
into a set of product features and attributes helps to there will always be some requirements that are not
ensure customer needs are being met throughout in the specification. It is also folly to think teams can
the project lifecycle [18]. freeze the requirements and allow no changes after
• Requirements definition is a discovery and some initial elicitation activities. Rather than
declaring requirements “done” at some point,
invention process, not just a collection process:
effective teams define a baseline then follow a
Teams often talk about “gathering requirements.”
sensible change control process to modify
This phrase suggests that requirements are just requirements once a baseline is established [18].
lying around waiting to be picked like flowers or to
be plucked out of users’ brains by an analyst. In V. CORE ACTIVITIES OF REQUIREMENT ENGINEERING
reality, requirements definition is an exploratory
Good RE activities can accelerate software
activity, and requirements elicitation is a more
development. The process of defining business requirements
accurate description than requirements gathering.
aligns the stakeholders with shared vision, goals and
Elicitation includes some discovery and some
expectations. Involvement of substantial user in establishing
invention, as well as recording those bits of
and managing changes to agree upon requirements increases
requirements information that various stakeholders
the accuracy of requirements, ensuring that the functionality
present to an analyst. Elicitation demands iteration.
of the developed system will enable users to perform their
Constant feedback and validation from
essential business tasks.
stakeholders keeps communication flowing.
In a broad sense, Requirement Engineering
Participants in a requirements elicitation discussion
encompasses the two major sub domains of requirement
will not think of everything they will need up front,
definition and requirement management.
and their thinking will change as a project
Requirement Definition is the collaborative process of
progresses. Teams that prepare to iterate most often
collecting, documenting and validating a set of requirements
elicit the most accurate requirements [18].
that constitute an agreement among key project
• Customer involvement is the most critical stakeholders. This phase can be further subdivided into the
contributor to software quality: Various studies critical process areas of elicitation, analysis, specification,
confirm that inadequate customer involvement is a agreeing and validating requirements.
leading cause of failure of software projects. The From a pragmatic perspective, requirement definition
development team will get the customer input it strives for requirements which are validated by user and
needs eventually – even if it is after a project ships. clear enough to the software development team to proceed
However, it is much cheaper – and much less with design, construction and testing at an acceptable level
painful – to get customer input earlier, rather than of risk. It is natural that, risk leads to the threat of doing
after product release. Customer involvement expensive and unnecessary rework.
requires more than a workshop or two early in the Requirement Management involves working with a
project. It involves input from customers early and defined set of requirements throughout the development
often in the requirements process. Ongoing process of the system and its operational life. It also allows
engagement by suitably empowered and managing changes to that set of requirements throughout the
enthusiastic stakeholders is a critical success factor project lifecycle. This phase includes selecting changes to
for software development [18]. be incorporated within a particular release and ensuring
• Change happens; managing change is critical: It effective implementation of changes with no adverse impact
is inevitable that requirements will change as on schedule, scope or quality of the developed system.
business needs evolve, new users or markets are An effective requirement definition and management
identified, business rules and government solution creates an accurate and complete set of system
regulations are revised and operating environments requirements, while helping organizations to improve
change. The objective of a change control process communications is an effort to better align it with business
is not to inhibit change. Rather, the objective is to needs and objectives. The following sub sections discuss the
manage change to ensure that the project core activities of RE.
incorporates the right changes for the right reasons.
Teams that anticipate and accommodate changes
minimize disruption and cost to the project and its

255 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 8, November 2010

A. Requirement Elicitation homogeneous, and hence part of the elicitation
Requirements elicitation is recognized as one of the process is to identify the needs of different user
most critical, knowledge-intensive activities of software classes, such as novice users, expert users,
development [19]; poor execution of elicitation will lead a occasional users, disabled users, and so on [22]. So
complete failure of the project. Since project failures are so initially every software project should identify its
rampant [20], it is quite likely that improving how the key requirement decision makers as well as the
industry performs elicitation could have a dramatic effect on decision-making process to ensure that the right
the success record of the industry [21]. Information people can make important and timely decisions.
collected during this requirement elicitation phase are • Select Elicitation Technique: The choice of
interpreted, analyzed, modeled and validated so that a elicitation technique depends on the time and
requirement engineer can feel confident that a complete resources available to the requirements engineer,
enough set of requirements of a system have been collected. and of course, the kind of information that needs to
Therefore, requirements elicitation is closely related to other be elicited [6]. It also depends on the extent of
RE activities – to a great extent, selection of techniques for stakeholder involvement and how much access the
the next phases largely depends on how requirements were analyst has to the stakeholders. To interact with
elicited. Steps in requirement elicitation phase are described stakeholders, requirement engineer can use
below: techniques like: workshops, questionnaires, and
• Defining System Boundaries: One of the key interviews. Now a day, it is a common practice that
objectives of requirement elicitation is to define teams want to interact with stakeholders in
system boundaries i.e., to find out the problems lightweight, dynamic, frequent way which is
that need to be solved. This definition is necessary completely focused on the problem and thus
to discover where the final delivered system will fit collaboration has taken priority over
into the current operational environment. Without a documentation review. Techniques that leverage
clearly defined system boundary, the project is prototypes, mockups and screenshots are becoming
issuing an open invitation to scope creep. Prior to the norm. However, for the sake of a dynamic
eliciting requirements, teams should have a clear development process, teams should be trained and
understanding of system boundaries as it affects all proficient in a variety of elicitation techniques.
subsequent elicitation efforts. • Exploring user scenarios and simulations: It is
• Defining Goals: Goals denote the objectives that a often the case that users find it difficult to articulate
system should meet. Eliciting high level goals in their requirements. Rather they find it more
convenient to visually describe their business tasks,
the early stage of the development process is
interaction patterns and expected product
crucial. However, goal-oriented requirements
functionality than to define all these textually. So a
elicitation [23] is an activity that continues as requirements engineer can resort to eliciting
development proceeds, as high-level goals (such as information about the tasks currently performed by
business goals) are refined into lower level goals the users and those that they might want to perform
(such as technical goals that are eventually [24]. After that, these tasks can be represented in
operational in a system) [6]. Eliciting goals use cases which can be used to describe the
emphasizes on defining the problem domain and outwardly visible requirements of systems [25].
also the needs of the stakeholders, rather than on More specifically, the requirements engineer may
possible solutions to those problems. choose a particular path through a use case, a
• Identifying Stakeholders: Stakeholders mean scenario, in order to better understand some aspect
individuals or organizations that stand to gain or of using a system [26]. Acceleration in visual
lose from the success or failure of a system. techniques for requirements definition and the
Stakeholders include customers or clients (who pay ability to tie artifacts to more traditional
for the system), developers (who design, construct requirements is changing the way of interactions
and maintain the system), and users (who interact forming between business and development
with the system to get their work done) [6]. It is organizations.
essential to gain commitment from key A-1. Elicitation Techniques:
stakeholders for their participation throughout the Researchers found various classes for requirement
requirements definition and Customer engagement elicitation techniques all of which are apposite in different
is necessary during requirements management, as scenarios. Some of these are briefly discussed below:
well. [18]. Stakeholders’ view is required in
• Traditional Techniques: These techniques are
making change in decisions followed by assessing
useful for gathering generic data. Questionnaires
the impact of proposed changes and adjusting
and surveys, interviews, and analysis of existing
requirement priorities. Users themselves are not
documentation (ex: organizational charts, process

256 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 8, November 2010

models or standards, and manuals of existing engineering and software design. It allows the requirement
systems) belong to this group. engineer to refine the software allocation and build models
• Elicitation through Groups: These techniques are of the data, functional, and behavioral domains that will be
useful for a richer understanding of need through exploited by software. It is also beneficial for the software
exploiting team dynamics with an aim to foster designer as it provides a representation of information,
stakeholders’ need. This class includes techniques function, and behavior that can be translated to data,
like brainstorming and focus groups, as well as architectural, interface, and component-level designs.
RAD/JAD workshops (using consensus-building Finally, requirements specification after successful
workshops with an unbiased facilitator) [27]. requirement analysis provides the developer as well as the
• Prototyping: These techniques are useful in such customer with the means to assess quality once software is
cases where there remains a great deal of built. The subsequent steps should be followed during
uncertainty about the requirements, or where early requirement analysis:
feedback from stakeholders is needed [28]. For • Creation of visual scenarios: The natural language
better requirement elicitation, prototyping can also requirements found in most specifications are
be readily combined with other techniques, for mostly text based, full of ambiguities, redundancies
instance by using a prototype to provoke discussion and gaps. Most of the cases, it is desirable to
in a group elicitation technique or as the basis for represent requirements in multiple ways to give
other traditional techniques. readers a richer, more holistic understanding.
• Model Driven Techniques: Techniques of this class Visual scenarios present requirements information
is helpful in the cases where a specific model of the from a business viewpoint in graphical diagrams
type of information to be gathered is already which allow reviewers to immediately spot missing
provided and this model is used to drive the requirements by examining flows, rather than
elicitation process. Goal-based methods, such as uncovering missing requirements by reading a
KAOS [29] and I* [30], and scenario-based opaque textual specification. Teams may have
methods such as CREWS [31] belong to this class. better results using diagrams that communicate at a
• Cognitive Techniques: This group includes a series higher level of abstraction, so readers can get the
of techniques originally developed for knowledge big picture without getting mired in all of the
acquisition for knowledge-based systems [32]. details.
Such techniques include protocol analysis (in • Creation and Evaluation of Simulations: A
which an expert thinks aloud while performing a simulation is an interactive software experience
task, to provide the observer with insights into the that captures the essential flow and level of detail
cognitive processes used to perform the task), to the requirements. Simulations provide
laddering (using probes to elicit structure and opportunities for everyone to interact with some
content of stakeholder knowledge), card sorting portion of the final system which is more tangible
(asking stakeholders to sort cards in groups, each than written requirements specifications. A
of which has name of some domain entity), simulation may look and behave like a prototype,
repertory grids (constructing an attribute matrix for but the key difference is that a simulation is not
entities, by asking stakeholders for attributes created by the development team. It is created as
applicable to entities and values for cells in each part of the requirements definition phase and is
entity) [6]. typically done without requiring any development
• Contextual Techniques: This class is an alternative skills. Simulations can leverage existing business
to both traditional and cognitive techniques [33]. data, show flow of the data and dynamically
These include the use of ethnographic techniques capture feedback that can quickly be incorporated
like participant observation, ethnomethodogy and into the next revision. Typically, revisions can be
conversation analysis, which result fine grained augmented during the stakeholder review – leading
analysis to identify patterns in conversation and to an “Is this what you had in mind?” high quality
interaction [34]. interaction [18].
Though there is a fundamental methodological disagreement • Requirement Prioritization: The ultimate goal of a
between the proponents of contextual techniques on the one software development team is to create a system
hand, and the traditional and cognitive techniques on the that meets the stakeholders’ demands. Since there
other, recent work has focused on the question of whether are usually more requirements than can be
integration is possible [34-35]. implemented within the limited resource, decision
B. Requirement Analysis makers must face the dilemma of selecting the
right set of requirements for the intended system.
Requirements Analysis is a fundamental activity in RE In order to select the correct set of requirements,
that bridges the gap between system level requirements the decision makers must understand the relative

257 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 8, November 2010

priorities of the requested requirements [36]. By • It decomposes the problem into component parts.
selecting a subset of the requirements that are The simple act of writing down software
valuable for the customers, and can be requirements in a well-designed format organizes
implemented within budget, organizations can information, places borders around the problem,
become more successful on the market. However, solidifies ideas, and helps break down the problem
Prioritization should be a collaborative process that into its constituent parts in an orderly fashion.
involves both a customer and a technical • It serves as an input to the design specification. As
perspective to balance customer value against cost mentioned previously, the SRS serves as the parent
and technical risk. document to subsequent documents, such as the
Analysis techniques that have been investigated in RE software design specification and statement of
include requirements animation [37], automated reasoning work. Therefore, the SRS must contain sufficient
(e.g., analogical and case-based reasoning [38] and detail in the functional system requirements so that
knowledge based critiquing [39]), consistency checking (e.g., a design solution can be devised.
model checking [40]), and a variety of techniques for It serves as a product validation check. The SRS also acts
validation and verification. as the parent document for testing and validation strategies
C. Requirement Specification that will be applied to the requirements for verification and
validation.
Software Requirement Specification (SRS) is basically
an organization's understanding (in writing) of a customer or C-2. What should the SRS address?
potential client's system requirements and dependencies at a IEEE standards suggest that SRS should address the
particular point in time (usually) prior to any actual design or following basic issues:
development work. It's a two-way insurance policy that
• Functionality: What is the software supposed to
assures that both the client and the organization understand
the other's requirements from that perspective at a given do?
point in time. The SRS document itself states in precise and • External interfaces: How does the software interact
explicit language those functions and capabilities a software with people, the system’s hardware, other
system must provide, as well as states any required hardware, and other software?
constraints by which the system must abide. The SRS also • Performance: What is the speed, availability,
officiates as a blueprint for completing a project with as little response time, recovery time of various software
cost growth as possible. The SRS is often referred to as the functions, etc.?
"parent" document because all subsequent project • Attributes: What are the portability, correctness,
management documents, such as design specifications, maintainability, security, etc. considerations?
statements of work, software architecture specifications, • Design constraints imposed on an implementation:
testing and validation plans, and documentation plans, are Are there any required standards in effect,
related to it. It is important to note that an SRS contains implementation language, policies for database
functional (requirements that define a function of a software integrity, resource limits, operating environment(s)
system or its component) and nonfunctional requirements etc.?
(requirements that specify criteria that can be used to judge
the operation of a system, rather than specific behaviors) C-3. Characteristics of a good SRS
only; it doesn't offer design suggestions, possible solutions to A good SRS should contain the following
technology or business issues, or any other information other characteristics:
than what the development team understands the customer's • Complete: SRS should define precisely all the go-
system requirements to be. There are some standard for SRS live situations that will be encountered and the
defined by IEEE e.g. IEEE STD 830-1998 [41] and IEEE
system's capability to successfully address them. It
STD 1233-1998 [42].
should contain everything that is needed by the
C-1. Goals of SRS software designers to develop the software.
A well-designed, well-written SRS accomplishes four • Correct: Of course everyone associated with the
major goals: intended system expects the specification to be
• It provides feedback to the customer. An SRS is correct. No one writes a specification that they
the customer's assurance that the development know is incorrect. Someone may like to say it -
organization understands the issues or problems to "Correct and Ever Correcting." The discipline is
be solved and the software behavior necessary to keeping the specification up to date when someone
address those problems. Therefore, the SRS should finds things that are not correct.
be written in natural language, in an unambiguous • Consistent: The SRS should be consistent within
manner that may also include charts, tables, data itself and consistent to its reference documents. If
flow diagrams, decision tables, and so on. someone calls an input "Start and Stop" in one

258 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 8, November 2010

place, he/she shouldn't call it "Start/Stop" in C-4. Benefits of a good SRS
another.
• Accurate: SRS should precisely define the system's The IEEE 830 standard defines the benefits of a good
capability in a real-world environment, as well as SRS [41]:
how it interfaces and interacts with it. This aspect • Establish the basis for agreement between the
of requirements is a noteworthy problem area for customers and the suppliers on what the software
many SRSs. product is to do: The complete description of the
• Modifiable: The logical, hierarchical structure of functions to be performed by the software specified
the SRS should facilitate any necessary in the SRS will assist the potential users to
modifications; grouping related issues together and determine if the software specified meets their
separating them from unrelated issues makes the needs or how the software must be modified to
SRS easier to modify. meet their needs.
• Ranked: Individual requirements of an SRS should • Reduce the development effort: The preparation of
be hierarchically arranged according to stability, the SRS forces the various concerned groups in the
security, perceived ease/difficulty of customer’s organization to consider rigorously all
implementation, or other parameter that helps in of the requirements before design begins and
the design of that and subsequent documents. reduces later redesign, recoding, and retesting.
• Unambiguous: SRS must contain requirements Careful review of the requirements in the SRS can
statements that can be interpreted in one way only. reveal omissions, misunderstandings, and
This is another area that creates significant inconsistencies early in the development cycle
problems for SRS development because of the use when these problems are easier to correct.
of natural language. • Provide a basis for estimating costs and schedules:
• Testable: SRS must be stated in such a manner that The description of the system to be developed as
unambiguous assessment criteria (pass/fail or some given in the SRS is a realistic basis for estimating
quantitative measure) can be derived from the SRS project costs and can be used to obtain approval for
itself. bids or price estimates.
• Traceable: Requirements traceability (RT) is • Provide a baseline for validation and verification:
another major factor that determines how easy it is Teams can develop their validation and
to read, navigate, query and change requirements Verification plans much more productively from a
documentation [6]. SRS must be able to link each good SRS. As a part of the development contract,
software functional requirement back to its origin, the SRS provides a baseline against which
possibly a use case or business rule. Teams should compliance can be measured.
embrace traceability information that connects • Facilitate transfer: SRS makes it easier to transfer
functional requirements to associated design the software product to new users or new
elements, code segments and tests to accelerate machines. Customers thus find it easier to transfer
debugging and software maintenance. As RT lies at the software to other parts of their organization,
the heart of requirements management practice, and suppliers find it easier to transfer it to new
providing RT in SRS is a means of achieving customers.
integrity and completeness of requirement • Serve as a basis for enhancement: Because the SRS
documentation that has an important role to play in discusses the system but not the project that
managing changes. developed it, the SRS serves as a basis for later
• Valid: A valid SRS is one in which all parties and enhancement of the developed system. The SRS
project participants can understand, analyze, may need to be altered, but it does provide a
accept, or approve it. This is one of the main foundation for continued system evaluation.
reasons SRSs are written using natural language. D. Agreeing and Validating Requirements
• Verifiable: A verifiable SRS is consistent from one
level of abstraction to another. Most attributes of a It is an arduous job to maintain agreement with all
specification are subjective and a conclusive stakeholders as they have divergent goals. Validation is the
assessment of quality requires a technical review by process of establishing that the requirements elicited and
domain experts. Using indicators of strength and specified provide an accurate account of stakeholder
weakness provide some evidence whether preferred requirements. This activity is essential for resolving
attributes are present or not. conflicts between stakeholders.
Techniques such as inspection and formal analysis tend
to concentrate on the consistency and completeness of the
requirements. This approach is illustrated by SCR [43]
which provides an automated checking of the formal model

259 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 8, November 2010

for syntactic consistency and completeness. On the other requirement of stakeholders. Requirement Management
hand, techniques like prototyping, specification animation, should go through the following steps:
and the use of scenarios are geared towards testing a • Manage Requirements Versions: As requirements
correspondence with the real world problem: have all the evolve during the course of a project, it is
aspects of the problem that the stakeholders regard as important to track the different versions of
important been covered? requirements specification documents and even
In some cases, the methods and tools used by the individual requirements [18]. Changes to
requirement engineers dominate the way that they see and requirements documentation need to be managed
describe problems, which, in the extreme case, shifts the properly and minimally, this involves providing
problem of validating requirements statements to a problem techniques and tools for configuration management
of convincing stakeholders that the chosen representation and version control [51], and by exploiting
for requirements models is appropriate. This leads to the traceability, the impact of changes in different parts
realization that observation is not value free, rather it is of the documentation can be monitored and
theory-driven, and is biased by the current paradigm. controlled correctly. Version tracking helps to
Jackson captures this perspective through his identification ensure that all team members are working from the
of problem frames [44]. If stakeholders do not agree with latest requirements baseline.
the choice of problem frame, it is unlikely that they will • Establishing A Change Control Process: Typically,
ever agree with any statement of the requirements. changes to requirement specifications include
Ethnomethodologists attempt to avoid the problem adding or deleting requirements, and also fixing
altogether, by refusing to impose modeling constructs on the errors. Requirements are added in response to
stakeholders [33]. By discarding traditional problem changing stakeholder needs that were missed in the
analysis tools, they seek to apply value-free observations of initial analysis. Requirements are deleted usually in
stakeholder activities, and therefore circumvent the the circumstances to forestall cost and schedule
requirements validation issue altogether. overruns. Again there also remain some
Requirements negotiation attempts to resolve conflicts inconsistencies in requirements which arise both as
on goal among stakeholders without necessarily weakening a result of mistakes and because of conflicts
satisfaction of each stakeholder. Early approaches to between requirements. In any case, managing
requirements negotiation focused on modeling each inconsistency in requirements specifications as
stakeholder’s contribution separately rather than trying to fit they evolve is a major challenge [52]. So once
their contributions into a single consistent model [45] and requirements have been base lined, proposed
on the importance of establishing common ground [46]. modifications in them should follow an established
Boehm introduced the win-win approach [47] in which the change control process which provides consistency
win conditions for each stakeholder are identified, and the in the way requirement changes are proposed,
software process is managed and measured to ensure that all evaluated, approved or rejected, communicated to
the win conditions are satisfied, through negotiation among stakeholders and implemented in affected work
the stakeholders. These negotiation models concentrate on products. Teams should have formal written
the identification of the most important goals of each change control processes in place before eliciting
participant, and ensure that these goals are met. This requirements [18].
approach is also used in other RE techniques for promoting • Perform Requirements Change Impact Analysis:
agreement, without necessarily making the goals explicit Requirement Management not only includes
[48]. For example, in Quality Function Deployment (QFD) process of managing documentation but also
[49], matrices are constructed to compare functional process of recognizing change through continued
requirements with one another and rate their importance requirements elicitation, re-evaluation of risk, and
rather explicitly identifying stakeholder goals. evaluation of systems in their operational
After agreeing of the requirements, teams should begin environment. Thus, each proposed change needs to
“testing” as soon as they have requirements in hand. be evaluated in terms of existing requirements and
Deriving test cases from use cases and scenarios is a valuable architecture so that the trade-off between the cost
way to find problems in the use cases themselves, in and benefit of making a change can be assessed.
functional requirements derived from the use cases and in Finally, the process of identifying core requirements in
analysis models created from the requirements [18]. order to develop architectures that are (a) stable in the
E. Requirement Management presence of change, and (b) flexible enough to be customized
and adapted to changing requirements, is one of the key
Managing change is a fundamental activity in RE [50]
research issues in software engineering [53].
as every successful software system evolves due to change
in the environment it is operating as well as change in the

260 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 8, November 2010

VI. REQUIREMENT ENGINEERING: CHALLENGES AND techniques that swell efficiency and accuracy. By
SUGGESTIONS following these steps, teams can gain better
As mentioned earlier, Requirement Engineering is a estimation and thus, superior predictability for
core process as well as most crucial part in software software delivery.
development life cycle. Bugs in requirements may not be • Specification: Improve Quality through More
identified during development phase rather they remain Effective Communications
concealed until system becomes operational and customer Requirements specification includes adding
requirements are not met. Poor requirements cause not only detail to requirements incrementally to the optimal
modifications in requirement specifications but also require level for validation, design, coding, testing and
re-designing, re-implementing and retesting for entire documentation. To ameliorate quality, teams
software. Therefore, requirement engineers have to struggle should formulate and automate their existing
and conquer uncountable numbers of challenges for requirements specification process by defining a
developing effective and efficient software. standard hierarchy of requirement types and
Anticipating requirement engineering challenges will developing standard templates to ensure
grant opportunities for requirement engineers to enhance completeness. They should also identify various
software success rate. There have been many investigations specification techniques and apply technology for
conducted to explore different challenges in various capturing requirements in a meaningful, easy-to-
domains of requirement engineering. Some suggestions to understand way. Traceability across the lifecycle
overcome these challenges are discussed below: allows teams for better prediction of the impact of
• Elicitation: Reduce Rework by Capturing Better change and proactively communicates those
Information changes to all team members affected. Through
The process of capturing requirements in these steps, software defects can be reduced nicely
context, requirements elicitation includes because in this case development teams have a
identifying key business and technical better understanding of requirements.
stakeholders, getting commitment to stakeholder • Agreeing and Validation: Improve Accuracy and
involvement, selecting appropriate elicitation Completeness of Requirements
techniques and capturing requirements and Requirements validation involves verifying
scenarios in a simple to understand form. For whether the specification is inclusive and clear
reducing rework, teams should mature their enough for the development team to understand
existing requirements elicitation process by helping exactly what it needed. It also includes validating
to define responsibilities and stakeholders, identify whether the requirement of the key stakeholders
appropriate elicitation techniques and train team are consistent with the original need and intent of
members to use the right techniques. They should the business. To improve accuracy, teams should
also take initiative to capture user scenarios in a mature their existing process by automating
simple, visual form that is easy to understand by validation and verification to drive adoption and
the user and accelerate elicitation with interactive enforcement and improving consistency and
simulations. Enhancement in communication and quality through interactive simulations and
collaboration among distributed teams throughout storyboarding of visual scenarios. These steps trim
the project lifecycle is also necessary for better down software defects, increase satisfaction and
requirement elicitation. Teams should also improve alignment with business stakeholders and thus
alignment between business expectations and enhance business value.
project deliverables, which increases end user • Management: Reduce Costs through Improved
satisfaction and reduces rework from incorrect or Change Management
incomplete requirements. The process of gathering and managing change
• Analysis: Reduce Time to Market with More requests during the application lifecycle,
Effective Collaboration requirements management also includes selecting
Requirements analysis involves verifying, changes to be incorporated within a particular
estimating and prioritizing newly captured release and ensuring effective implementation of
requirements for remaining application lifecycle changes with no adverse impact on schedule, scope
steps. To reduce time to market, teams should or quality. To reduce costs, teams should contrive
codify their existing requirements analysis process their existing requirements management process by
by implementing an effective approach to evaluate establishing processes for defining and maintaining
and prioritize requirements for specification, requirements baselines and defining a standard
design, construction and testing. The process is process for requesting changes. They may also
improved through the deployment of tools and establish a systematic approach to evaluate and
approve change requests so that scope changes and

261 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 8, November 2010

affected commitments are managed. By improving [16] Finkelstein, A. (1993). Requirements Engineering: an overview. 2nd
Asia-Pacific Software Engineering Conference (APSEC'93), Tokyo,
ongoing change management, maximizing business Japan, 1993.
impact, while minimizing schedule and scope [17] Nuseibeh, B. (1997). Ariane 5: Who Dunnit? IEEE Software, 14(3):
impact, satisfaction of business stakeholders can be 15-16.
increased. [18] White Paper on “Effective Requirements Definition and
Management: Improves Systems and Communication”, Borland
VII. CONCLUSION Software Corporation, May 2009.
RE is often treated as a time-consuming, bureaucratic and [19] Gottesdeiner, E., Requirements by Collaboration, Addison- Wesley,
2002.
contractual process and due to ineffective RE; customers
[20] Standish Group, "The Chaos Report," www.standishgroup.com, 1995.
may not be satisfied with the developed system. This attitude
is changing as RE is increasingly recognized as a critically [21] Hofmann, H., and F. Lehner, “Requirements Engineering as a
Success Factor in Software Projects,” IEEE Software, 18, 4 (July/Aug
important activity in the field of Software Engineering. The 2001), pp. 58-66.
novelty of many software applications, the speed with which [22] Sharp, H., Finkelstein, A. & Galal, G. (1999). Stakeholder
they need to be developed, and the degree to which they are Identification in the Requirements Engineering Process. Workshop on
expected to change, all play a role in determining how the Requirements Engineering Processes (REP'99) - DEXA'99, Florence,
systems development process should be conducted [6]. In Italy, 1-3 September 1999, pp. 387-391.
future, RE will continue to evolve in order to deal with [23] Dardenne, A., Lamsweerde, A. v. & Fickas, S. (1993). Goal-Directed
different development scenarios for further amelioration. In Requirements Acquisition. Science of Computer Programming, 20: 3-
50.
this paper we discussed RE in detail with challenges and
[24] Johnson, P. (1992). Human-Computer Interaction: psychology, task
some suggestions. We believe that effective RE will continue analysis and software engineering. McGraw-Hill.
to play a key role to ensure success of a project in developing
[25] Schneider, G. & Winters, J. (1998). Applying Use Cases: a practical
quality software. guide. Addison-Wesley.
[26] Jarke, M. & Kurki-Suonio, R. (1998). Guest Editorial - Special issue
REFERENCES on Scenario Management. IEEE Transactions on Software
Engineering, 24(12).
[1] Roger S. Pressman, “Requirements Engineering,” in Software [27] Maiden, N. & Rugg, G. (1996). ACRE: Selecting Methods For
Engineering: A Practitioner’s Approach, McGraw-Hill, Fifth Edition, Requirements Acquisition. Software Engineering Journal, 11(3): 183-
pp. 271-298, 2001. 192.
[2] Reifer, D.J., “Requirements Engineering,” in Encyclopedia of [28] Davis, A. (1992). Operational Prototyping: A New Development
Software Engineering (J.J. Marciniak, ed.), Wiley, 1994, pp. 1043– Approach. Software, 9(5): 70-78.
1054. [29] van Lamsweerde, A., Darimont, R. & Letier, E. (1998). Managing
[3] Zave, P., “Classification of Research Efforts in Requirements conflicts in goal-driven requirements engineering. IEEE Transactions
Engineering”, ACM Computing Surveys, 29(4), pp. 315-321, 1997. on Software Engineering, 24(11): 908-926.
[4] Brooks, F.P. Jr. No Silver Bullet: Essence and Accidents of Software [30] Chung, L., Nixon, B., Yu, E. & Mylopoulos, J. (2000). Non-
Engineering. IEEE Computer, 10-19, April 1987. Functional Requirements in Software Engineering. Boston: Kluwer
[5] Stevens, R., Brook, P., Jackson, K. & Arnold, S. (1998). Systems Academic Publishers.
Engineering: Coping with Complexity. Prentice Hall Europe. [31] Maiden, N. (1998). CREWS-SAVRE: Scenarios for Acquiring and
[6] Bashar Nuseibeh and Steve Easterbrook, Requirements Engineering: Validating Requirements. Automated Software Engineering, 5(4):
A Roadmap, In ICSE '00: Proceedings of the Conference on The 419-446.
Future of Software Engineering (2000), pp. 35-46. [32] Shaw, M. & Gaines, B. (1996). Requirements Acquisition. Software
[7] Carter, R., Martin, J., Mayblin, B. & Munday, M. (1984). Systems, Engineering Journal, 11(3): 149-165.
Management and Change: A Graphic Guide. London: Paul Chapman [33] Goguen, J. & Linde, C. (1993). Techniques for Requirements
Publishing/Harper and Row. Elicitation. 1st IEEE International Symposium on Requirements
[8] Wieringa, R. J. (1996). Requirements Engineering: Frameworks for Engineering (RE'93), San Diego, USA, 4-6th January 1993, pp. 152-
Understanding. Wiley. 164.
[9] Robertson, S. & Robertson, J. (1994). The Complete Systems [34] Viller, S. & Sommerville, I. (1999). Social Analysis in the
Analysis: The Workbook, The Textbook, the Answers. Dorset House. Requirements Engineering Process: from ethnography to method. 4th
International Symposium on Requirements Engineering (RE'99),
[10] Posner, M. I. (Ed.). (1993). Foundations of Cognitive Science. MIT Limerick, Ireland, 7-11th June 1999.
Press.
[35] Potts, C. (1997). Requirements Models in Context. 3rd International
[11] Goguen, J. & Jirotka, M. (Ed.). (1994). Requirements Engineering: Symposium on Requirements Engineering (RE'97), Annapolis, USA,
Social and Technical Issues. London: Academic Press. 6-10 January 1997, pp. 102-104.
[12] Lehman, M. M. (1980). Programs, Life Cycles, and Laws of Software [36] Wiegers, K., Software Requirements, Microsoft Press, 1999.
Evolution. Proceedings of the IEEE, 68(9): 1060-1076.
[37] Gravell, A. & Henderson, P. (1996). Executing Formal Specifications
[13] Burg, J. F. M. (1997). Linguistic Instruments in Requirements Need Not Be Harmful. IEE Software Engineering Journal, 11(2):
Engineering. Amsterdam: IOS Press 104-110.
[14] Boehm, B. W. (1981). Software Engineering Economics. Englewood [38] Maiden, N. A. M. & Sutcliffe, A. G. (1992). Exploiting Reusable
Cliffs, NJ: Prentice-Hall. Specifications Through Analogy. Communications of the ACM,
[15] Nakajo, T. & Kume, H. (1991). A Case History Analysis of Software 34(5): 55-64.
Error Cause-Effect Relationships. Transactions on Software [39] Fickas, S. & Nagarajan, P. (1988). Critiquing Software
Engineering, 17(8): 830-838. Specifications: a knowledge based approach. IEEE Software, 5(6).

262 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 8, November 2010

[40] Holzmann, G. J. (1997). The Model Checker Spin. Transactions on Abdullah Al Mahmood received his
Software Engineering, 23(5): 279-295. B.Sc. (Engg.) in Computer Science and
[41] IEEE 830-1998 Standard, found at Engineering from Khulna University
http://standards.ieee.org/reading/ieee/std_public/description/se/830- of Engineering and Technology
1998_desc.html (KUET), Bangladesh in 2009. His
[42] IEEE 1233-1998 Standard, found at research interest includes Robotics,
http://standards.ieee.org/reading/ieee/std_public/description/se/1233- Artificial Intelligence, Internet
1998_desc.html Security and various areas of Software
Engineering like Requirement
[43] Heitmeyer, C. L., Jeffords, R. D. & Labaw, B. G. (1996). Automated
Gathering, Requirement Prioritization
Consistency Checking of Requirements Specifications. IEEE
and Software Security. He has
Transactions on Software Engineering and Methodology, 5(3): 231-
261. coauthored a good number of research
papers published in International
[44] Jackson, M. (1995). Software Requirements and Specifications: A Journals and Conference Proceedings.
Lexicon of Practice, Principles and Prejudices. Addison Wesley. Currently he is working as a researcher
[45] Easterbrook, S. M. (1991). Resolving Conflicts Between Domain of Panacea Research Lab, Dhaka,
Descriptions with Computer-Supported Negotiation. Knowledge Bangladesh. He is also a lecturer at
Acquisition: An International Journal, 3: 255-289. Institute of Science, Trade and
[46] Robinson, W. N. & Volkov, S. (1998). Supporting the Negotiation Technology, Dhaka, Bangladesh and a
Life-Cycle. Communications of the ACM, 41(5): 95-102. Project Coordinator of Technocrats
[47] Boehm, B., Bose, P., Horowitz, E. & Lee, M. J. (1995). Requirements BD.
Negotiation and Renegotiation Aids: A Theory-W Based Spiral
Approach. 17th International Conference on Software Engineering Farin Rahman received her B. Sc.
(ICSE-17), Seattle, USA, 23-30 April 1995, pp. 243-254. (Engg.) in Computer Science and
[48] Karlsson, J. & Ryan, K. (1997). Prioritizing Requirements Using a Engineering from Khulna University
Cost-Value Approach. IEEE Software: 67-74. of Engineering and Technology
[49] Hauser, J. R. & Clausing, D. (1988). The House of Quality. The (KUET), Bangladesh in 2009. Her
Harvard Business Review(3): 63-73. research interest encompasses with
different sectors of Software
[50] Bohner, S. A. & Arnold, R. S. (Ed.). (1996). Software Change Impact Engineering like Requirement
Analysis. IEEE Computer Society Press. Engineering, Software Security and
[51] Estublier, J. (2000). Software Configuration Management: A Software Maintenance. She is working
Roadmap, In ICSE '00: Proceedings of the Conference on The Future as a researcher in Panacea Research
of Software Engineering (2000), pp. 279-289. Lab and also as a lecturer in Daffodil
[52] Ghezzi, C. & Nuseibeh, B. (1998). Guest Editorial – Managing Institute of Information Technology,
Inconsistency in Software Development. Transactions on Software Dhaka, Bangladesh.
Engineering, 24(11): 906-907.
[53] Garlan, D. (2000). Software Architecture: A Roadmap. In ICSE '00:
Proceedings of the Conference on The Future of Software
Engineering (2000), pp. 91-101. Sk. Md. Nahid Hasan received his
B.Sc. (Engg.) in Computer Science and
Engineering from Khulna University
of Engineering and Technology
AUTHORS’ PROFILE (KUET), Bangladesh in 2010. His
research interest includes different
areas of Software Engineering like
Mohammad Shabbir Hasan received Software Metric, Requirement
his B.Sc. (Engg.) in Computer Science Gathering, Software Security and
and Engineering from Khulna Software Maintenance. Digital Image
University of Engineering and Processing is also one of his research
Technology (KUET), Bangladesh in concerns. Currently he is working as a
2008. His research interest includes researcher of Panacea Research Lab,
different areas of Software Dhaka, Bangladesh. He is also a
Engineering like Requirement lecturer of Department of Computer
Engineering, Software Metric, Science and Engineering in Institute of
Software Security and Software Science, Trade and Technology,
Maintenance. He has coauthored Dhaka, Bangladesh.
numerous research papers published in
International Journals and Conference
Proceedings. Currently he is working
as a researcher of Panacea Research
Lab, Dhaka, Bangladesh. He is also a
lecturer of Department of Computer
Science and Engineering in Institute of
Science, Trade and Technology,
Dhaka, Bangladesh.

263 http://sites.google.com/site/ijcsis/
ISSN 1947-5500