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.
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.
Method Four: QUICKethics
Effective Technical and Human Implementation of Computer-based Systems (ETHICS) is a systems design methodology characterised by a high-level of user involvement at the design stage, the setting of clear job satisfaction objectives, and recognition of organisational factors to ensure compatibility and proper functionality. It encompasses the socio-technical view of systems which states “[in order] for a system to be effective the technology must fit closely with the social and organisational factors” (Avison & Fitzgerald, 1995, pg 353). This method has been further developed and this has led to the creation of an approach specifically for the requirements determination stage of a project, known as QUICKethics (Quality Information from Considered Knowledge).
A useful and correct requirements specification will be greatly aided by a method which “assists the user to think systematically and analytically about his or her information needs” (Mumford, 1995, pg 95). QUICKethics attempts this through enabling users to work both individually and within groups to consider their roles and responsibilities and relate these to their information needs. This process will help users in defining their requirements fully and correctly, and will also address possible conflicts of interest. Discussion groups will facilitate greater understanding for the users of their needs and how the system can satisfy them, and will encourage co-operation between different levels of the organisation in regards to system demands.
Participation of those affected by the proposed system being part of their decision making process, something which is part of many other methodologies, is seen as essential to the QUICKethics approach. The procedure ‘empowers’ users as they see that their interests are respected and that their knowledge is being used. It provides the means for users to get involved in decisions concerning changes to their work processes and allows them to see how the use of technology might improve their job satisfaction. This course of action is much more likely to stimulate an effective requirements analysis. .
The main argument against the QUICKethics method is that it is impractical and that unskilled users will have difficulty completing the design process adequately. This by no means a concrete disadvantage however, as there are those that believe with the proper training and support, the users will produce an effective and useable requirements specification.
Method Five: JAD
Joint Application Design (JAD) is another method that has been found to be effective in the collection of detailed system requirements. The technique revolves around there being a workshop attended by representatives from different departments and different levels of the organisation, at which there is a structured discussion concerning the design of the proposed system. There are stages before and after this, involving firstly preparatory work and lastly collation of data, but the workshop is certainly the main component.
This process is seen as being highly beneficial to the requirements determination stage, indeed Kettlehut, 1993 states that “organisations that have adopted JAD have reported savings of 40% in project design time.” It is an approach that encourages communication between users; it recognises that different viewpoints need to be expressed in order to gain an overall consensus on requirements. This calls for the co-operation of all involved to overcome any conflicts, but success will result in the clarification of requirements and is also likely to mean that decisions will be approved quickly and be supported by management.
Any uncertainty over technical capabilities or staff difficulties in expressing their information needs in a clear manner, or indeed any queries whatsoever, can be addressed during the workshop. This facilitates a better understanding of the system throughout the organisation, may win over unsupportive workers, and of course helps to produce a more effective requirements specification.
There are some problems with this approach, most of which can be seen as disadvantages of workshops themselves. Certain people can dominate discussions whilst others contribute very seldom, which can lead to a biased or unrepresentative conclusions being drawn. Politics are an especially pertinent factor here, as vendettas and alliances can once again lead to prejudiced decisions being made or unresolved conflict.
Method Six: TQM
Total Quality Management (TQM) is a very common method that has been utilised within business organisations for many years. It can be seen as “commitment to the continuous improvement of work processes with the goal of satisfying internal and external customers” (Ward, 1994). Within the specific context of IS requirements specification, this approach involves the elimination of the causes of root problems, and places emphasis on the customer understanding and agreeing upon all requirements. General TQM concepts that are likely to be employed include team building, empowerment, and continuous process improvement.
Due to the fact that managers and staff are liable to be experienced with this method and therefore a common basis is provided for problem definition and solving, traditional communication difficulties between system developers and users should be eased. Users commonly cannot express their needs in a form that is helpful to developers, and they in turn have trouble explaining how IS can assist in reaching business goals – the platform of TQM will help both articulate themselves in a more universal manner.
The importance placed upon gaining acceptance of requirements from customers inherent within this approach will engage the problems of disparate interpretations of business needs occurring and of requirements that cross organisational boundaries or conflict with each other. Everybody affected by the proposed system must be aware of and consent to the specified requirements, thus ensuring a relevant and functional specification endorsed by the customer themselves.
TQM also stresses that the developer must have an in-depth knowledge of their customer(s), to enable a greater understanding of the business situation and to create a system which is capable of fulfilling the needs of all functions of an organisation. Management should become more familiar with IS capabilities and terminology through this process as well, as there must be interaction between both sides to facilitate a high level of comprehension.
Possible drawbacks to the application of this method to an IS project are that TQM is renowned for being a business technique and may be viewed with skepticism by some when it is employed in an IS context. Also, this method is not a structured methodology containing strict guidelines; it is more a philosophy and therefore may be misinterpreted or applied incorrectly by those with little experience.
During the course of this essay, six varying methods that can be used for the collection and clarification of user requirements have been examined. Traditional approaches – interviews, questionnaires and prototypes – have been looked at, along with methodologies designed specifically for the purpose of obtaining requirements in an IS environment – JAD and QUICKethics. A common business technique that has only recently started being employed within this context – TQM – has also been evaluated.
A conclusion that can be drawn from the study of these very different approaches is that there is no ‘best’ method for requirements elicitation in any IS project. There may be certain methods that are more appropriate than others in particular situations, but it would be incorrect to suggest just one technique would produce a fully complete and relevant specification.
There are benefits and drawbacks associated with all of the six approaches, with emphasis placed upon different factors by each one of them. QUICKethics, for example, is very interested in the social factors affecting organisations. This diversity leads to the conclusion that a combination of methods is the paramount means for obtaining a correct user requirements specification.
This is not to say choosing a random list of current available methods will lead to success, choices must be carefully made based upon the characteristics of the organisation involved and the type of system desired, amongst other things. A in-depth knowledge of these methods and experience of IS projects will be the biggest advantage a developer can have during the requirements determination stage.
