Requirements investigation techniques
There is a range of techniques that may be used to investigate business situations and elicit service requirements. Sometimes the customers and the business are not completely sure of what their requirements actually are and will need some assistance and prompting from the designer or requirements gatherer. This must be completed in a sensitive way to ensure that it is not seen as IT dictating business requirements again. The two most commonly used techniques are interviewing and workshops, but these are usually supplemented by other techniques, such as observation and scenarios.
The interview is a key tool and can be vital in achieving a number of objectives, such as:
There are three areas that are considered during interviews:
The interviewing process is improved when the interviewer has prepared thoroughly as this saves time by avoiding unnecessary explanations and demonstrates interest and professionalism. The classic questioning structure of ‘Why, What, Who, When, Where, How’ provides an excellent framework for preparing for interviews.
It is equally important to formally close the interview by:
It is always a good idea to write up the notes of the interview as soon as possible – ideally straight away and usually by the next day.
The advantages of interviewing are:
The disadvantages of interviewing are:
Workshops provide a forum in which issues can be discussed, conflicts resolved and requirements elicited. Workshops are especially valuable when time and budgets are tightly constrained, several viewpoints need to be canvassed and an iterative and incremental view of service development is being taken.
The advantages of the workshop are:
There are some disadvantages, including:
The success or failure of a workshop session depends, in large part, on the preparatory work by the facilitator and the business sponsor for the workshop. They should spend time before the event planning the following areas:
During the workshop, a facilitator needs to ensure that the issues are discussed, views are aired and progress is made towards achieving the stated objective. A record needs to be kept of the key points emerging from the discussion. At the end of the workshop, the facilitator needs to summarize the key points and actions. Each action should be assigned to an owner.
There are two main categories of technique required for a requirements workshop – techniques for discovery and techniques for documentation, as shown in Figure 5.1.
Figure 5.1 Requirements workshop techniques
Observing the workplace is very useful in obtaining information about the business environment and the work practices. This has two advantages:
Conversely, being observed can be rather unnerving, and the old saying ‘you change when being observed’ needs to be factored into your approach and findings.
Formal observation involves watching a specific task being performed. There is a danger of being shown just the ‘front-story’ without any of the everyday variances, but it is still a useful tool.
188.8.131.52 Protocol Analysis
Protocol Analysis is simply getting the users to perform a task, and for them to describe each step as they perform it.
Shadowing involves following a user for a period such as a day to find out about a particular job. It is a powerful way to understand a particular user role. Asking for explanations of how the work is done, or the workflow, clarifies some of the already assumed aspects.
184.108.40.206 Scenario Analysis
Scenario Analysis is essentially telling the story of a task or transaction. Its value is that it helps a user who is uncertain what is needed from a new service to realize it more clearly. Scenarios are also useful when analysing or redesigning business processes. A scenario will trace the course of a transaction from an initial business trigger through each of the steps needed to achieve a successful outcome.
Scenarios provide a framework for discovering alternative paths that may be followed to complete the transaction. This is extremely useful in requirements elicitation and analysis because real-life situations, including the exceptional circumstances, are debated.
Scenarios offer significant advantages:
The disadvantages of scenarios are that they can be time-consuming to develop, and some scenarios can become very complex. Where this is the case, it is easier to analyse if each of the main alternative paths is considered as a separate scenario.
A popular approach to documenting scenario descriptions is to develop use case descriptions to support use case diagrams. However, there are also a number of graphical methods of documenting a scenario, such as storyboards, activity diagrams, task models and decision tree diagrams.
Prototyping is an important technique for eliciting, analysing, demonstrating and validating requirements. It is difficult for users to envisage the new service before it is actually built. Prototypes offer a way of showing the user how the new service might work and the ways in which it can be used. If a user is unclear what they need the service to do for them, utilizing a prototype often releases blocks to thinking and can produce a new wave of requirements. Incremental and iterative approaches to service development, such as the Dynamic Systems Development Method (DSDM), use evolutionary prototyping as an integral part of their development lifecycle.
There is a range of approaches to building prototypes. They may be built using an application development environment so that they mirror the service; images of the screens and navigations may be built using presentation software; or they may simply be ‘mock-ups’ on paper.
There are two basic methods of prototyping:
It is important to select consciously which is to be used, otherwise there is a danger that a poor-quality mock-up becomes the basis for the real system, causing problems later on.
There is a strong link between scenarios and prototyping because scenarios can be used as the basis for developing prototypes. In addition to confirming the users’ requirements, prototyping can often help the users to identify new requirements.
Prototypes are successfully used to:
Potential problems include:
220.127.116.11 Other techniques
Other techniques that could be used, include: