Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Requirment Elicitation Issues and Techniques for Requirement Elicitation

Requirment Elicitation Issues and Techniques for Requirement Elicitation

Ratings: (0)|Views: 15|Likes:
Published by Faizan Khan

More info:

Published by: Faizan Khan on Apr 24, 2012
Copyright:Attribution Non-commercial


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





Requirements elicitation is the process of seeking, uncovering, acquiring, andelaborating requirements for computerbased systems. It is generally understoodthat requirements are elicited rather than just captured or collected. This impliesthere are discovery, emergence, anddevelopment elements in the elicitationprocess. Requirements elicitation is acomplex process involving many activitieswith a variety of available techniques,approaches, and tools for performing them.The relative strengths and weaknesses of these determine when each is appropriatedepending on the context and situation aswell as, There are many problemsassociated with requirements engineering,including problems in defining the systemscope, problems in fostering understandingamong the different communities affectedby the development of a given system, andproblems in dealing with the volatile natureof requirements. These problems may leadto poor requirements and the Cancellationof system development, or else thedevelopment of a system that is later judged unsatisfactory or unacceptable, hashigh maintenance costs, or undergoesfrequent changes. Most of therequirements techniques and tools todayfocus on specification, i.e., therepresentation of the requirements. Thisreport concentrates on elicitation concerns,important aspects of the techniques,approaches and tools for requirementselicitation.
The importance of requirement engineering(RE) within software systems developmenthas long been established and recognizedby researchers and practitioners.The elicitation of requirements representsan early but continuous and critical stage inthe development of software systems. Therequirements for a software system may bespread across many sources. These includethe problem owners, stakeholders,documentation, and other existing systems.Requirements elicitation is recognized asone of the most critical, knowledge-intensive activities of softwaredevelopment [1]; poor execution of elicitation will almost guarantee that thefinal project is a complete failure. Sinceproject failures are so rampant [2], it isquite likely that improving how the industryperforms elicitation could have a dramaticeffect on the success record of the industry[3].Requirements elicitation itself is a verycomplex process involving many activities,with multiple techniques available toperform these activities and some issue areinvolve in Requirement Elicitation Processas well. These problems and issues arediscussed in this paper in later sections.
A requirement i
s a “function or
characteristic of a system that isnecessary...the quantifiable and verifiablebehaviors that a system must possess andconstraints that a system must work within
to satisfy an organization’s objectives andsolve a set of problems” .Simila
“requirement” has the following definitions
[IEEE 90].(1) A condition or capability needed by auser to solve a problem or achieve anobjective; (2) a condition or capability thatmust be met or possessed by a system orsystem component to satisfy a contract,standard, specification, or other formallyimposed documents; (3) a documentedrepresentation of a condition or capabilityas in (1) or (2).
Rzepka decomposes the requirementsengineering process into three activities[Rzepka 89]:1. Elicit requirements from variousindividual sources;2. Insure that the needs of all users areconsistent and feasible; and3. Validate that the requirements soderived are an accurate reflection of userneeds.This model implies a sequential ordering tothe activities, with elicitation done once atthe very beginning of the process. In reality,though, the process is iterative, with theseactivities revisited many times [Southwell87, p. 195]:...the requirements definition activitycannot be defined by a simple progressionthrough, or relationship between,acquisition, expression, analysis, andspecification. Requirements evolve at anuneven pace and tend to generate furtherrequirements from the definition processes.The construction of the requirementsspecification is inevitably an iterativeprocess which is not, in general, self-terminating. Thus, at each iteration it isnecessary to consider whether the currentversion of the requirements specification
adequately defines the purchaser’s
requirement, and, if not, how it must bechanged or expanded further.A good requirements elicitation processsupports the development of a specificationwith these attributes. Conversely, problemswith requirements elicitation inhibit thedefinition of requirements which areunambiguous, complete, verifiable,consistent, modifiable, traceable, usable,and necessary.
Problems of requirements elicitation can begrouped into three categories:
• Problems of scope, in which the
requirements may address too little or tooMuch information;
• Problems of understanding, within groups
as well as between groups such asusers and developers; and
Problems of volatility, i.e., the changingnature of requirements.The list of ten elicitation problems given inone source [McDermid 89] could beclassified accordingto this framework as follows:
Problems of scope
The boundary of the system is ill-defined
Unnecessary design information may begiven
Problems of understanding
Users have incomplete understanding of their needs
Users have poor understanding of computer capabilities and limitations
Analysts have poor knowledge of problemdomain
User and analyst speak differentlanguages
• ease of omitting “obvious” information
Conflicting views of different users
• requirements are often vague anduntestable, e.g., “user friendly” and
Problems of volatility
Requirements evolve over time
Interviewing and questionnaires
Requirements workshops
Braining Storming and idea reduction
Use Cases
Role Playing
Interviewing and Questionnaires
Simple direct technique, Context-freequestions can help achieve bias-freeinterviews then, it may be appropriate tosearch for undiscovered requirements byexploring solutions. Convergence on some
common needs will initiate a “requirementsrepository” for use during the project. A
questionnaire is no substitute for aninterview.
Requirements workshops
The requirements workshop is perhaps themost powerful technique for elicitingrequirements. It gathers all keystakeholders together for a short butintensely focused period. The use of anoutside facilitator experienced inrequirements management can ensure thesuccess of the workshop. Brainstorming isthe most important part of the workshop.If requirements are collected from a singleviewpoint, they are unlikely to meet other
stakeholders’ requirements. Collecting
requirements from multiple viewpoints is auseful way to prioritize requirements.Identified viewpoints can be used to helporganize requirements elicitation andOrganize the requirements specification,too. Saves money and time. Studies haveshown that similar systems can re-use up to80% of the requirements. Reuse reducesrisk. Reused requirements have a betterchance of being understood by all thestakeholders. Requirements reuse may leadto additional reuse in other lifecycleactivities.
Braining Storming and idea reduction

You're Reading a Free Preview

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