Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more ➡
Download
Standard view
Full view
of .
Add note
Save to My Library
Sync to mobile
Look up keyword
Like this
1Activity
×
0 of .
Results for:
No results containing your search query
P. 1
An In-Depth Study on Requirement Engineering

An In-Depth Study on Requirement Engineering

Ratings: (0)|Views: 555|Likes:
Published by ijcsis
Software development includes Requirement Engineering (RE) which is comprised of discovering stakeholders and their need, proper documentation, communication and subsequent implementation. It can be viewed as the most crucial phase as the success of the software depends largely on it. Requirement Engineering is receiving increasing attention of the researchers and also people associated with software development. This paper investigates RE activities in detail followed by some current challenges and also proposes some suggestions to overcome these challenging issues.
Software development includes Requirement Engineering (RE) which is comprised of discovering stakeholders and their need, proper documentation, communication and subsequent implementation. It can be viewed as the most crucial phase as the success of the software depends largely on it. Requirement Engineering is receiving increasing attention of the researchers and also people associated with software development. This paper investigates RE activities in detail followed by some current challenges and also proposes some suggestions to overcome these challenging issues.

More info:

Published by: ijcsis on Dec 04, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See More
See less

12/04/2010

pdf

text

original

 
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 8, November 2010
 
 An In-depth Study on Requirement Engineering
Mohammad Shabbir Hasan
1
, Abdullah Al Mahmood
2
, Farin Rahman
3
, Sk. Md. Nahid Hasan
4
 
E-mail:
1
shabbir_cse03@yahoo.com,
2
sajibcseofkuet@gmail.com,
3
 farinrahman.cse@gmail.com,
4
auvi_2k5@hotmail.com,
Panacea Research Lab, Dhaka, Bangladesh
 Abstract
— Software development includes RequirementEngineering (RE) which is comprised of discoveringstakeholders and their need, proper documentation,communication and subsequent implementation. It can beviewed as the most crucial phase as the success of the softwaredepends largely on it. Requirement Engineering is receivingincreasing attention of the researchers and also peopleassociated with software development. This paper investigatesRE activities in detail followed by some current challenges andalso proposes some suggestions to overcome these challengingissues.
 Keywords- Software Requirement, Requirement Engineering, Requirement Elicitation, Requirement Management.
I.
 
I
NTRODUCTION
Success of a software system is measured by evaluatinghow it meets the purpose it was intended and in broad sense,Requirement Engineering (RE) is the process of discoveringthat purpose through identifying stake holders and theirneeds, refinement of the gathered information, modeling,specification and then subsequent implementation. Thesystem requirements and role allocated to software—initially established by the system engineer—are refined indetail. Models of the required data, information and controlflow, and operational behavior are created. Alternativesolutions are analyzed and a complete analysis model iscreated [1]. Donald Reifer [2] describes the softwarerequirement engineering process in the following way:“Requirements engineering is the systematic useof proven principles, techniques, languages, andtools for the cost effective analysis,documentation, and on-going evolution of userneeds and the specification of the externalbehavior of a system to satisfy those user needs.Notice that like all engineering disciplines,requirements engineering is not conducted in asporadic, random or otherwise haphazard fashion,but instead is the systematic use of provenapproaches.”The Requirement Engineering process may face anumber of inherent difficulties like: stakeholders may benumerous and distributed, their goals may be volatile andconflicting, depending on their perspectives of differentworking environment, goals may be implicit and difficult toarticulate, and, inevitably, satisfaction of these goals may beconstrained by a variety of factors outside their control.Based on these characteristics Zave [3] defined RE as:“Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints onsoftware systems. It is also concerned with therelationship of these factors to precisespecifications of software behavior, and to theirevolution over time and across softwarefamilies.”This definition is an attractive one as it highlights theimportance of “real world goals” which motivates thedevelopment of a software system by referring thespecifications more precisely. It also refers to the reality of achanging world and the need to reuse partial specifications,as done by engineers in other branches of engineering.Brooks [4] defined RE as a key problem area in thedevelopment of complex, software-intensive systems:“The hardest single part of building a softwaresystem is deciding what to build. ...No otherpart of the work so cripples the resulting systemif done wrong. No other part is more difficult torectify later.”RE can be characterized as a branch of 
System Engineering
[5] as it has to encompass a systems level viewto deliver some systems behavior to its stakeholders. Again,Zave defined RE as a branch of 
Software Engineering
andsoftware systems requirements engineering has receivedspecial consideration possibly due to the abstract andinvisible nature of software with the vast range and varietyof problems that admit to software solutions.Whether viewed at the systems level or the softwarelevel, RE is a multi-disciplinary, human-centered processand the use of the term
 Engineering
in RE serves as areminder that RE is an important part of an engineeringprocess and represents a series of engineering decisions thatlead from recognition of a problem to be solved to a detailedspecification of that problem followed by anchoringdevelopment activities, so that the appropriateness and cost-effectiveness of the solution can then be analyzed.The structure of the paper is approximately as follows. Insections 2 and 3 we discuss the foundation and some groundworks needed for requirement engineering respectively.
253http://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 thecore activities of RE in section 5. Then, in section 6,challenges of RE activities are analyzed with somesuggestions. We finish by drawing some broad andnecessarily speculative and personal conclusions about thefuture of requirement engineering.II.
 
F
OUNDATION
 RE activities play a vital role in software and systemsengineering, and there are also many disciplines upon whichit draws.In software development context, an important role isplayed by Computer Science as theoretical computer scienceprovide the framework to assess the feasibility of requirements while the means of developing softwaresolution are provided by practical computer science. Here
logic
provides a vehicle for analyzing software behaviorwhich is acquiescent to formal reasoning to make thereasoning steps more explicit. Different logics may be usedto express different aspects of a required system. Forexample,
temporal logic
can be used to describe timinginformation,
deontic logic
to describe permissions andobligations, and
linear logic
to describe resources and theiruse. A further advantage of specification languagesgrounded in logic is that they are potentially amenable toautomated reasoning and analysis [6].In the systems engineering context, an understandingand application of systems theory and practice is alsorelevant to RE [5]. This includes work on characterizingsystems, identifying their boundaries and managing theirdevelopment life cycle [7-8]. RE also encompasses work onsystems analysis, traditionally found in the informationsystems world [9].Usually RE activities take place in a human activitysystem, and people are the problem owner. Therefore, REneeds to be sensitive to how people perceive and understandthe newly implemented computer-based system, how theyinteract, and how the environment of the workplace isaffected by their actions. RE draws on the cognitive andsocial sciences to provide both theoretical grounding andpractical techniques for eliciting and modeling requirements[6].
Cognitive psychology
provides an understanding of thedifficulties people may have in describing their needs [10].
 Anthropology
provides a methodological approach toobserving human activities that helps to develop a richerunderstanding of how computer systems may help or hinderthose activities [11].
Sociology
provides an understanding of the political and cultural changes caused by computerization.Introduction of a new computer system changes the nature of the work carried out within an organization, may affect thestructure and communication paths within that organization,and may even change the original needs that it was built tosatisfy [12].
 
 Linguistics
is important because RE is largelyabout communication. Linguistic analyses have changed theway in which the English language is used in specifications,for instance to avoid ambiguity and to improveunderstandability. Tools from linguistics can also be used inrequirements elicitation, for instance to analyzecommunication patterns within an organization [13].
Philosophical
elements also have an important effect on REas it is concerned with interpreting and understanding of terminology, concepts, viewpoints and goals fromstakeholder’s perspective. Such issues become importantwhile requirement validation, especially where stakeholdersmay have divergent goals and incompatible belief systems.They also become important in selecting a requirementmodeling technique, because the choice of technique affectsthe set of phenomena that can be modeled, and may evenrestrict what a requirements engineer is capable of observing[6].III.
 
G
ROUNDWORK
 In the software development process, RE is consideredas a front-end activity. Although it is usually the case thatrequirements change during development and evolve after asystem has been in operation for some time, RE plays animportant role in the management of changes in softwaredevelopment. Nevertheless, the bulk of the effort of RE doesoccur early in the lifetime of a project, motivated by theevidence that requirements errors, such as misunderstood oromitted requirements, are more expensive to fix later inproject lifecycles [14-15].Before a project can be started, some preparation isneeded which are categorized as
context and groundwork 
byFinkelstein [16]. This groundwork includes someassessment of project’s feasibility and associated risks needsto be undertaken, and RE plays a crucial role in makingsuch an assessment. Although it is often possible to estimateproject costs, schedules and technical feasibility fromprecise specifications of requirements, risk should be re-evaluated regularly throughout the development lifetime of a system [17], since changes in the environment can changethe associated development risks.Again, RE activities are performed in a variety of contexts, including market-driven product development anddevelopment for a specific customer with the eventualintention of developing a broader market. The type of product also affects the choice of method: RE forinformation systems is very different from RE for embeddedcontrol systems, which is different again from RE for genericservices such as networking and operating systems [6]. Sogroundwork is essential for the identification of a suitableprocess and also for the selection of suitable methods andtechniques for the various RE activities.IV.
 
K
EY
I
SSUES IN
R
EQUIREMENT
E
NGINEERING
 Software development organizations should keep inmind the following issues when they consider how toimprove the requirements and communication for theirprojects:
 
If teams don’t get requirements right, it doesn’tmatter how well they execute the rest of theproject:
The goal of every software developmentproject is to build a product that provides value to
254http://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 definitionenables teams to determine the mix of productcapabilities and characteristics that will best deliverthis customer value. An understanding evolvesover time as stakeholders provide feedback on theearly work and refine their expectations and needs.Adequately exploring and crafting requirementsinto a set of product features and attributes helps toensure customer needs are being met throughoutthe project lifecycle [18].
 
Requirements definition is a discovery andinvention process, not just a collection process:
Teams often talk about “gathering requirements.”This phrase suggests that requirements are justlying around waiting to be picked like flowers or tobe plucked out of users’ brains by an analyst. Inreality, requirements definition is an exploratoryactivity, and requirements elicitation is a moreaccurate description than requirements gathering.Elicitation includes some discovery and someinvention, as well as recording those bits of requirements information that various stakeholderspresent to an analyst. Elicitation demands iteration.Constant feedback and validation fromstakeholders keeps communication flowing.Participants in a requirements elicitation discussionwill not think of everything they will need up front,and their thinking will change as a projectprogresses. Teams that prepare to iterate most oftenelicit the most accurate requirements [18].
 
Customer involvement is the most criticalcontributor to software quality:
Various studiesconfirm that inadequate customer involvement is aleading cause of failure of software projects. Thedevelopment team will get the customer input itneeds eventually – even if it is after a project ships.However, it is much cheaper – and much lesspainful – to get customer input earlier, rather thanafter product release. Customer involvementrequires more than a workshop or two early in theproject. It involves input from customers early andoften in the requirements process. Ongoingengagement by suitably empowered andenthusiastic stakeholders is a critical success factorfor software development [18].
 
Change happens; managing change is critical:
Itis inevitable that requirements will change asbusiness needs evolve, new users or markets areidentified, business rules and governmentregulations are revised and operating environmentschange. The objective of a change control processis not to inhibit change. Rather, the objective is tomanage change to ensure that the projectincorporates the right changes for the right reasons.Teams that anticipate and accommodate changesminimize disruption and cost to the project and itsstakeholders. Further teams that can force as muchchange at the beginning of a project will have lesschange to manage over time [18].
 
Teams are never going to have perfectrequirements:
Requirements are never finished orcomplete. There is no way to know for certain thatteams have not overlooked some requirement, andthere will always be some requirements that are notin the specification. It is also folly to think teams canfreeze the requirements and allow no changes aftersome initial elicitation activities. Rather thandeclaring requirements “done” at some point,effective teams define a baseline then follow asensible change control process to modifyrequirements once a baseline is established [18].V.
 
C
ORE
A
CTIVITIES OF
R
EQUIREMENT
E
NGINEERING
 Good RE activities can accelerate softwaredevelopment. The process of defining business requirementsaligns the stakeholders with shared vision, goals andexpectations. Involvement of substantial user in establishingand managing changes to agree upon requirements increasesthe accuracy of requirements, ensuring that the functionalityof the developed system will enable users to perform theiressential business tasks.In a broad sense, Requirement Engineeringencompasses the two major sub domains of requirementdefinition and requirement management.
 Requirement Definition
is the collaborative process of collecting, documenting and validating a set of requirementsthat constitute an agreement among key projectstakeholders. This phase can be further subdivided into thecritical process areas of elicitation, analysis, specification,agreeing and validating requirements.From a pragmatic perspective, requirement definitionstrives for requirements which are validated by user andclear enough to the software development team to proceedwith design, construction and testing at an acceptable levelof risk. It is natural that, risk leads to the threat of doingexpensive and unnecessary rework.
 Requirement Management 
involves working with adefined set of requirements throughout the developmentprocess of the system and its operational life. It also allowsmanaging changes to that set of requirements throughout theproject lifecycle. This phase includes selecting changes tobe incorporated within a particular release and ensuringeffective implementation of changes with no adverse impacton schedule, scope or quality of the developed system.An effective requirement definition and managementsolution creates an accurate and complete set of systemrequirements, while helping organizations to improvecommunications is an effort to better align it with businessneeds and objectives. The following sub sections discuss thecore activities of RE.
255http://sites.google.com/site/ijcsis/ISSN 1947-5500

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->