One of the biggest problems facing the IT industry is poor customer service that is mainly rooted in delivering unsatisfactory products. The root cause is the failure to discern exactly what the stakeholder really wants and this turns requirements engineering into a minefield.
Poorly analysed customer requirements have been variously cited as leading to poor or inappropriate products, the inability to perform functions not to mention leading to failure, unreliability, and by no means least, extra cost for the company (Hall et al, 2002). Furthermore, if a requirement is ambiguous, inconsistent, incomplete, or otherwise incorrect, significant development difficulties can arise (Zmud et al. 1993). Memon et al, 2014, also agree that the major cause of failure of software products is the poor fulfilment of requirements engineering activity by software engineers and that requirements engineering is the hardest stage of software development. At the same time, requirements engineering is the most critical stage of the software development.
Requirements engineering is the process of gathering and modelling information about required functionality of a proposed system by a systems analyst and has been widely recognised as the most difficult activity of information systems development (Browne and Rogich, 2001). Broadly speaking requirements determination can be viewed as a three-step process.
- Information gathering
- Representation during which the evoked requirements are modeled
- Verification during which the analyst verifies with users that requirements are modelled correctly (Copeland et al. 2012).
The first phase is called the elicitation phase. Elicitation is to call forth, draw out, or provoke (a response or reaction) (thefreedictionary.com, 2015). Elicitation in business analysis is the categorizing of research tasks that are visual, or written stimuli to encourage participants to talk about their ideas as what they say is useful to exploring topics that may be difficult to discuss informal interviews such as those in sensitive issues or those that involve tacit knowledge (Keith, 2015). Useful techniques are those that involve respondents in arranging stimulus materials, “constructing” materials in response to stimuli and explaining “stimuli materials” (Keith, 2015). However, during user analyst communication in the elicitation process analysts may introduce misinformation in their discussion with users and social techniques such as interview are vulnerable to the misinformation effect than non-social techniques such as surveys (Appan and Browne, 2012). As a solution, in the process of interviews, using ethnographers trained in remaining neutral during requirements elicitation could help reduce misinformation effect as long as users do not regard them as systems development experts (Appan and Browne, 2012). Furthermore, probing using neutral questions and not providing clues to users about how they should respond could also significantly reduce the misinformation effect (Appan and Browne, 2012).
In addition, results indicate that domain knowledge affects elicitation via interviews in two main aspects; communication of customer needs and understanding of their needs (Hada et al. 2014). Having domain knowledge prior to the elicitation process is assured to have a positive effect on requirements engineering process in that it fosters communication and the mutual understanding of needs but also negative effects have been reported (Hada et al. 2014). As a result, the best way to mix teams who are domain literate and illiterate personnel to create a synergy to gain better results (Hada et al. 2014).
Other methods such as the use of graphic elicitation techniques ask research participants to provide visual data representing a personal understanding of concepts, experiences and beliefs or behaviours can be especially useful in helping participants express complex ideas or opinions (Copeland et al, 2012). Results show that using data collection, analysis, data matrices, rational maps facilitate triangulation and help establish internal consistency of data thereby increasing the trustworthiness of interpretation of data and lending support to validity and reliability of claims (Copeland et al 2012). Nevertheless, graphical techniques should not be used in isolation with non-graphical techniques that enable participants to provide contextual explanations such as group interviews or focus groups (Copeland et al, 2012). Some have even tried to use incentives to facilitate the elicitation process but participants provided the same responses in incentivized and non-incentivized situations (Vesley, 2015).
It is important to get elicitation right because as aforementioned, poor requirements engineering leads to terrible products. Conceptually, failure comes from the fact that requirements engineering ignores or presumes a uniform nature of the context in which systems operate (Ali et al. 2010). There is also confusion in the industry about user requirements versus needs and what are their relationships in a business process (Lavaza, 2012). User requirements tend to encompass multiple different aspects of systems, requirements indicate the characteristic of the process that are essential to meet the goals of the business whereas needs are capabilities that a stakeholder deems necessary to achieve objectives and approved by sponsors.
Further difficulties in requirements engineering arise from cognitive issues resulting from constraints on humans as information processors as many forget and can’t recall information (Copeland et al. 2012). There is also a problem structuring issues from the variety and complexity of information requirements and communication issues resulting from complex patterns of interaction among users and analysis in defining requirements (Copeland et al. 2012).
There is no silver bullet method to solve all the shortcomings that arise from requirements engineering, but instead, a whole spectrum of methods must be applied in order to capture the requirements of a project according to the specifics of a system (Memon et al, 2014). According to Svanhberg and Gorsheck 2005, requirement engineering should rest on three pillars. They include;
- Basic skills such as those provided by instructional material
- The state of practice such as how requirements analysis is performed in an industry
- And the state of the art (the current research being carried out in the field of requirements engineering).
Another method calls for a checklist-oriented requirements analysis (CORA) to develop and formalise requirements and to manage complexity by providing carefully structured methods for effective analysis of requirements. (Brace and Cheutet, 2012). This includes abstraction (retaining only relevant information for a particular purpose), decomposition (breaking a problem in manageable parts), and projection (dealing with a particular view) and modularity (finding structures that are stable over time across different contexts).
Appan, Radha, Browne, Glenn J.MIS Quarterly. Mar2012, Vol. 36 Issue 1, p85-106. 22p.
Brace, William, Cheutet, Vincent Journal of Engineering Design. Dec2012, Vol. 23 Issue 12, p873-901. 29p. 20
Browne, Glenn, Rogich, Michael , Journal of Management Information Systems. Spring2001, Vol. 17 Issue 4, p223-249. 27p
Copeland, Andrea J.Agosto, Denise International Journal of Qualitative Methods. 2012, Vol. 11 Issue 5, p513-533. 21p.
Hada, Irit, Soffer, Pnina, Kenzi, Keren, Requirements Engineering. Jun2014, Vol. 19 Issue 2, p143-159. 17p.
Keith Barton, C. Theory and Research in Social Education, v43 n2 p179-205 2015. 27 pp.
Memon, Rafia, Salim, Siti , Ahmad, Rodina Arabian Journal for Science & Engineering (Springer Science & Business Media B.V. ). Mar2014, Vol. 39 Issue 3, p1923-1935. 13p. [Accessed 14 Sep. 2015].
Lavazza, Luigi ,Expert Systems. Jul2013, Vol. 30 Issue 3, p215-232
Svahnberg, M.; Gorschek, TMulti-perspective requirements engineering education with focus on industry relevance. In: International Workshop on Requirements Engineering Education & Training (REET 2005), pp. 88–97 (2005)
Veselý, Štěpán, , Judgment and Decision Making, Vol 10(2), Mar, 2015. pp. 191-197