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.