The requirements determination stage of an Information System project is one of the “most important phases in designing and developing a new IS for an organisation” (Shi, Specht and Stolen, 1996, page 10). It provides developers with a template to work from; shaping the types of applications, data and information that will be present in the system. This is also a stage, however, that has many inherent difficulties and can seriously affect the effectiveness of a system if it is not conducted in a proper manner.
From a management perspective, a successful requirements analysis determines the most crucial needs by examining existing business information issues and involving users. From the developers’ viewpoint, the challenge is converting user preferences into a set of IS characteristics. This process is made even more complicated by the fact that managers and staff alike traditionally have various problems in specifying exactly what they require from a proposed IS.
The main problems are: Requirements can cross organisational boundaries or have conflicting objectives – a particular need specified by one function of the organisation may have a negative impact on another function, or may require data to be sent from another part of the organisation. These situations demand a certain amount of compromise to ensure the overall success of the proposed IS, although this can sometimes be very problematic due to social and political factors in the workplace.
There are of course various other difficulties that can be encountered during requirements elicitation, and these can be influenced by social, political, psychological, legal and/or financial factors. A number of methods have been developed in the field of information systems with the specific purpose of assisting the determination of requirements. This essay will review six of these, examining their basic approaches and how they can tackle the problems business managers and staff are likely to encounter.
Method One: Interviews One of the most common and more traditional approaches used to elicit requirements is the interview. The foremost manner of conducting these is simply to ask the people who will eventually be using the system about the information they need to do their jobs, and the procedures they follow to complete tasks. There are a number of specific types of interview, structured or open-ended being examples, but this section will simply review interviewing as a whole.
A benefit of this approach is that it allows both interviewee and interviewer to seek clarification on any points that are not clear. This may materialise, for instance, in the interviewee asking exactly what one of the interviewer’s questions means, what he is seeking to discover. The ability to do this will ensure that a much clearer, more useable set of requirements is produced. Another problem of users interpreting essentially the same requirements in different ways can be tackled by the interviewing approach. Once the initial data has been acquired, the developer can then collate and analyse what he/she perceives to be similar requirements and produce a more concise and efficient specification. The success of this operation will be affected by the experience and skill of the developer however.
Although different types of interviews structure the process in different ways, the basic theme of ‘discussion’ should have a positive impact on common problems encountered during the requirements specification stage. As mentioned above, clarification can be sought by both sides and this then extends to the potential pitfall of users not being fully aware of IS capabilities. Developers are given the opportunity through this method to promote the facilities available in IS today to those not knowledgeable in the field.
There are some shortcomings to this approach, however, most notably that the process from start to finish is extremely time consuming. The different components – research, design, the interviews themselves, and then analysis will require a great deal of time and effort in order to obtain useful and effective information. It should be noted also, in relation to the analysis of data collected through the duration of this method, that there are no specific guidelines for that particular process and once again success is likely to be determined by the aptitude of the developer. Obviously, this means that there is the possibility of an improper analysis taking place, and an incorrect requirements specification being produced.
Method Two: Questionnaires This again can be classified as one of the traditional approaches employed for requirements specification. A questionnaire can be generalised as a method for “the elicitation, recording and collecting of information” (Kirakowski, 1998). They are commonly employed to gather information from a number of sources throughout an organisation, where relevant people are widely spread or as exploratory work.
The most prominent generic advantage of employing questionnaires, mentioned above, is that they enable a large amount of information to be obtained from a variety of sources. This may not be an essential function to an IS developer, but this could prove effective in a preliminary study into the information needs of an organisation. The format of questionnaires, with the philosophy of structured questions receiving standardised responses, tends to make this approach one of the least complex when it comes to analysis of data. In contrast to other methods discussed in this essay, for instance interviewing where the analysis stage is time consuming and laborious, questionnaires lend themselves particularly to quantitative and also to qualitative forms of investigation.
Indeed, the drawbacks of questionnaires include the fact that statistical analysis is ‘reductionist’ – data is generalised into trends and unusual figures are ignored, and as a consequence of this, important needs could be missed in an IS context. Other disadvantages are that the response rate towards questionnaires tend not to be particularly high, meaning an unrepresentative sample could be used, and also that they are restricted by their stimulus-response model of interaction which “assumes that a given question always has the same meaning to subjects” (Goguen, 1992, pg 162).
Method Three: Prototyping The next method being examined is known as Prototyping. A prototype is an original type or form serving as a basis or standard for later stages, and this technique involves designing and implementing a key part of the user’s desired system, then allowing him to test it. With the user experimenting with the system in any way he conceives, errors in code or design are quickly detected. The required improvements are incorporated back into the prototype, and once again the user tries out the system. The basic framework is illustrated in Figure 1.
This approach starts by recognising that many users do not in fact have a fixed set of requirements before the beginning of the process. This is a concept that most other methods do not address, taking for granted that users know what they want and how to express these needs. One of the main arguments behind prototyping is that “experimentation with a real system enables users to better define, refine and communicate these requirements to the designers” (Flynn, 1992, page 121).
The problems of users not being able to clearly specify their requirements and not being fully aware of IS capabilities are also tackled by this approach. Working with the prototype system will make the process of users translating their business needs into IS specifications significantly easier as it will have been demonstrated to them how the system has attempted to implement their wishes. The user will then find it a much simpler task to articulate his requirements. The prototype should also help in raising the user’s awareness of the abilities of IS today as they will be experimenting with a new system and actually discovering what it is capable of themselves.
It is doubtful whether prototyping would have an impact on the problem of requirements crossing boundaries/conflicting with one another, as it does not encourage discussion or group meetings, and therefore is unlikely to stimulate compromise or co-operation. There are a number of disadvantages associated with prototyping, however. Previous studies have indicated that it is expensive to produce a prototype, both in terms of cost, time and (programmer) effort. Retuning the system at every minor fault discovered by the user may lead to the project being very difficult to control. Users may also get carried away, meaning too much time is spent making only ‘cosmetic’ changes.
