Examining The Importance Of Requirement Elicitation Information Technology Essay

Examining The Importance Of need Elicitation Information Technology EssayRequirements elicitation is a demonstrate during whichanalyst must interact with the stakeholders in many different types of elicitation sessions to draw prohibited the user indispensablenesss for a support (Tagbo, 2011).Hossenlopp and Hass, (2008) defined requirement elication as the operate of gathering business requirements for a new business beginning. According to Hossenlopp and Hass, (2008), activities involved in requirement elicitation process ar intended to draw out and acquire requirements for business soulutions from buisness experts. Unlike Tagbo (2011),Hossenlopp and Hass (2008) definition is specific and confined confined the source information(business requirement) to business expertWhy is requirement elicitation important?Requirement elicitation is a critical activity in the requirement development process. It discovers the requirements of stakeholders. This means it is where analyst id entifies what the users or owners of the system to build want to infer. The success or failure of this process is based on recognizing the relevant stakeholders and detecting and discovering their needs as well as the quality of requirements (SajjadHanif, 2010). A study on requirement engineering conducted byDavis, Fuller, Tremblay, Berndt, in 2006, found accurately capturing system requirements is the major factor in the failure of 90% of large software projects. Their conclusion was in transmission line with earlier work by Lindquist (2005) who concluded poor requirements management can be attributed to 71 percent of software projects that fail greater than bad technology, confounded deadlines, and change management issues. An insight from these two conclusions is that requirement elicitation determines the success or failure of a project and proper requirement elicitation is requisite for project success and therefore, without complete, clear and consistent requirement proje ct is doomed to failure.The cost of a failed project is an enormous expense to firms. A study by Browne and Rogich (2001) found that failed or aban dod systems cost $100 Billion in the USA alone in 2000. The cost of failed project is not throttle to financial cost but has lasting consequences on the system during its lifespan.Fixing mistakes made at requirements elicitation stage accounts for 75 percent of all error removal costs (Urquhart, 2001). In the following depend we show the impact of invalid requirements on software development.Figure 1 Requirement -software failure. Retrieved March 23, 2011, from http//www.scarpedia.com/general/requirement-elicitation/This figure shows the result of a study conducted by the Standish Group in 1995. In the study, 8000 software projects from 352 companies were studied. The study exposed that in more the 50% software project failures the reason lies somewhere in requirements (Requirement Engineering, 2010).Types 0f requirement elicitationRe quirement elicitation is divided into Greenfield engineering, R-engineering and interface engineering (Requirement Engineering, 2010). We first start with the description of Greenfield engineering followed the some other two.Greenfield Engineering is requirement elicitation used when new system is to be built. No Preceding system exists so requirements are pull out from leaf node and End User. This type of engineering is reliant onUser needs (Requirement Engineering, 2010).Re-Engineering unlikeGreenfieldengineering, this type of requirement elicitation is used when a system exists. Existing system is re-design and re-implemented using a newer technology. It is technology oriented type (Requirement Engineering, 2010).Interface Engineering It is a type of requirement elicitation where the system and its functionality remain the same but the environment in which the system operates is modified. It is dependent on new market needs (Requirement Engineering, 2010).Requirement Elicitatio n ChallengesThis section of the paper deals with the underlying challenges to requirement elicitation. Three syndromes have been determine by Leffingwell and Widring, which posses challenge to requirement elicitation. These syndromes are the Yes, But, Undiscovered Ruins, and the User and the Developer syndrome. The earlier part of this section impart be looking at these syndromes and the latter will give details to other challenges found in requirement elicitation.The Yes, But syndromeStated by Leffingwell and Widring that, this kind of problem stems from the natural reaction of users when they get to see the final developed software product. In the initial implementation of the product, users are expected to accept the software as what they where hopping for, or have additional requirements for the product, for pattern when the users have their first interaction with the system they have that yes, but, wouldnt be nice if kind of comments which indicates that the system is not wh at they really expected.Undiscovered Ruins syndromeIn many ways, the appear for requirement is like a search for undiscovered ruins the more you find, the more you know remain (Leffingwell Widring, 2003, p. 64) Thus software developers struggle to determine when they are done with software elicitation. This makes it difficult for developers to determine when they have found all the requirement that are material.User and the Developer syndromeA big gap of communication exist surrounded by users and developers thus theres a user and the developer syndrome. Leffingwell and Widring states that the syndrome arises since the users and the developers might be coming from different worlds, in terms of the languages they are speaking, the differences in their backgrounds, motivations and objectives.Other Challenges to elicitationThe following are the challenges identified by Mat and Silva (2005), in requirement elicitation. These areThe initial scope of the project is not sufficiently def ined and such(prenominal) is ease up to interpretation and assumptions.Stakeholders do not know what their real needs are and are therefore limited in their ability to support the investigation of the solution domainStakeholders do not understand or appreciate the needs of other stakeholders users may only be concerned with those factors that affect them directly.The analyst is unfamiliar with(predicate) with the problem or solution domain and does not understand the needs of the users and the processes to be addressed.Requirements generated from stakeholders can be vague, lacking specifics, and not represented in such a way as can be measured or tested.Only very limited guidelines and tool support exist for the process of equipments elicitation.