Despite the diverse assortment of artefacts produced to support systems development processes practitioners have survived attempts to overcome the problems they face when developing requirements. These problems arise at almost every stage of systems development and are investigated with varying degrees with success by different research projects. This paper unceremoniously focuses on some of the problematic activities at the front end of systems development, namely: requirements capture and analysis. A multi-layered evaluation process that is composed of several sets (layers) of criteria is outlined. A new method/tool can then be put through these multiple layers. If successful it would be 'ticked' as being a viable option and adopted by practitioners. The argument made is that a move towards regulating the evaluation of methods/tools usefulness can be one way out of the ivory tower.
It is widely accepted that establishing system requirements is considered the most important
stage of systems development. No other stage affords the greatest potential for significant
improvement in time, cost and the quality of the system
This papers aims to highlight the importance of establishing research usefulness. It focuses on the front-end activities within the requirements engineering process and presents an unceremonious discussion of some of these activities, namely: capture and analysis. The importance of these activities lies in the conviction that faults are often introduced in these stages of requirements development- a conviction supported by the findings of other studies (e.g. Ashry and Taylor, 2000).
The following section outlines some of the challenges of capturing requirements and the second focuses on requirements analysis. The paper also presents an outline of a possible evaluation framework to assist researchers develop more effective artefacts.
Research conducted into the field of requirements revealed that the problem often lies in the
initial stages of the requirements development process (Al-Ani, 2001).
Generally requirements sources vary during the elicitation process. They can be derived
gradually from a succession of informal notes, recorded interviews, questionnaires, and/or
through other information gathering techniques and documentation media that collectively
attempt to describe the system (Al -Ani, 2001). Information can be acquired through one or
more elicitation techniques
Studies of systems requirements cite inadequacy of the available representation languages in
addition to inadequacy of communication as one of the main challenges of developing
requirements
Fantechi et al (1994) state that although the process of defining requirements is to some extent systematic, the identification of requirements is usually informal. It is still ad hoc to some extent despite the work conducted in this area (Potts, 1999).
The argument that is made in this paper is that it would still be possible to save the day if the elicited requirements were better understood before attempting to develop the specification document.
At the end of the elicitation process developers are often faced with the challenging task of wading through a bulky document to reach an initial understanding of the proposed system’s general features.
A deeper understanding of system features must be achieved before developers can go any further. There exists a need for an approach to analysing raw requirements and developing an initial understanding. While it is widely accepted that developers rely on this initial understanding to negotiate the tender there is no evidence that there they are not relying primarily on an extemporized approach to reach this understanding. Poorly understood requirements can lead to incorrect interpretation of these statements. Developers can make assumption during these the early stages of requirements capture. These assumptions often become imbedded in the requirements document. While this is unavoidable to some extent it becomes dangerous when they fail to substantiate assumptions. These assumptions are often not detected until the testing phase incurring higher costs to correct.
Practitioners often resist systems that support requirements analysis despite their ability to
reduce cost through automated development e.g.
The purpose of this paper is not to inflict pessimism with regards to work done in the early stages of requirements development but rather to explore a means to provide a more optimistic future for the products of research by making them more useful or ‘marketable’ to practitioners.
Practitioners are the clients that researchers should target. Consequently, research should be based on their ‘clients’ needs and not personal beliefs isolated from client participation. Client participation is essential when evaluating the early drafts of approaches derived from research. This can assist researchers evaluate both method/tool outputs and process. Additional layers of evaluation will ensure that the emerging approach will be feasible. These layers can include the following: • • •
Evaluation through one or more traditional empirical methods like experiments, case
studies amongst others (Yin, 1994. The evaluation through these methods should strictly
follow the guidelines provided in relevant literature
Evaluation through standards developed to measure the effectiveness of derived
approaches
An overview of the proposed evaluation process is presented in figure 1. An artefact that has been subjected to this process would be ‘ticked’ as having the level of quality necessary to make it viable for industry use.
Standards ISO/IEC JTC1/SC7 N2497, 2001 ISO/IEC JTC1/SC7 N2497, 2001 and AS15504.2, 1998 Others
Empirical Evaluation
Experiment Survey Case Study
Interviews Method or Tool
Frameworks DESMET
Others
Despite the great leaps and jumps forward in technology humans have survived attempts to overcome some of the imperfections of the thinking process.
An outline of the early stages of requirements gathering and understanding was presented in this paper. In addition to a run through some of the challenges practitioners still face. While this paper does not propose evaluation criteria it does highlight viable options that are currently available. The multi-layered evaluation process proposed in the previous section includes different sets of criteria that can be used to evaluate different types of methods and tools. The paper also recommends involving the industry in developing at least one layer of evaluation. Collectively these measures could help researchers come a step closer to getting out of their ivory towers. Al-Ani, B., (2001). “A Framework for the Detection and Evalua tion of Partially Complete Requirements Documents”, Submitted Doctor of Philosophy Dissertation in Computer Systems Engineering, Faculty of Engineering University of Technology Sydney. AS15504.2, (1998). Infromation Technology- Software Process Assessment: Part 2: A Reference model for Processes and Process Capability, Interim Australian Standard™, Standards Australia.
Ashry, N,. Taylor, W., (2000). Requirements Analysis as Innovation Diffusion: A Proposed Requirements Analysis Strategy for the Description of an Integrated Hospital Information Support System, Proceedings of the 33 rd Hawaii International Conference on Syste ms Sciences, pp 1-9.