Главная Обратная связь

Дисциплины:






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.

5.1.3.1 Interviews

The interview is a key tool and can be vital in achieving a number of objectives, such as:

  • Making initial contact with key stakeholders and establishing a basis for progress
  • Building and developing rapport with different users and managers
  • Acquiring information about the business situation, including issues and problems.

There are three areas that are considered during interviews:

  • Current business processes that need to be fulfilled in any new business systems and services
  • Problems with the current operations that need to be addressed
  • New features required from the new business system or service and any supporting IT service.

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:

  • Summarizing the points covered and the actions agreed
  • Explaining what happens next, both following the interview and beyond
  • Asking the interviewee how any further contact should be made.

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:

  • Builds a relationship with the users
  • Can yield important information
  • Opportunity to understand different viewpoints and attitudes across the user group
  • Opportunity to investigate new areas that arise
  • Collection of examples of documents and reports
  • Appreciation of political factors
  • Study of the environment in which the new service will operate.

The disadvantages of interviewing are:

  • Expensive in elapsed time
  • No opportunity for conflict resolution.

5.1.3.2 Workshops

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:

  • Gain a broad view of the area under investigation – having a group of stakeholders in one room will allow a more complete understanding of the issues and problems
  • Increase speed and productivity – it is much quicker to have one meeting with a group of people than interviewing them one by one
  • Obtain buy-in and acceptance for the IT service
  • Gain a consensus view – if all the stakeholders are involved, the chance of them taking ownership of the results is improved.

There are some disadvantages, including:

  • Can be time-consuming to organize – for example, it is not always easy to get all the necessary people together at the same time
  • It can be difficult to get all of the participants with the required level of authority
  • It can be difficult to get a mix of business and operational people to understand the different requirements.

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:

  • The objective of the workshop – this has to be an objective that can be achieved within the time constraints of the workshop.
  • Who will be invited to participate in the workshop – it is important that all stakeholders interested in the objective should be invited to attend or be represented.
  • The structure of the workshop and the techniques to be used. These need to be geared towards achieving the defined objective, e.g. requirements gathering or prioritization, and should take the needs of the participants into account.
  • Arranging a suitable venue – this may be within the organization, but it is better to use a ‘neutral’ venue out of the office.

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

5.1.3.3 Observation

Observing the workplace is very useful in obtaining information about the business environment and the work practices. This has two advantages:

  • A much better understanding of the problems and difficulties faced by the business users
  • It will help devise workable solutions that are more likely to be acceptable to the business.

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.

5.1.3.4 Protocol Analysis

Protocol Analysis is simply getting the users to perform a task, and for them to describe each step as they perform it.

5.1.3.5 Shadowing

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.

5.1.3.6 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:

  • They force the user to include every step, so there are no taken-for-granted elements and the problem of tacit knowledge is addressed
  • By helping the user to visualize all contingencies, they help to cope with the uncertainty about future systems and services
  • A workshop group refining a scenario will identify those paths that do not suit the corporate culture
  • They provide a tool for preparing test scripts.

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.

5.1.3.7 Prototyping

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:

  • The throw-away mock-up, which is only used to demonstrate the look and feel
  • The incremental implementation, where the prototype is developed into the final system.

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:

  • Clarify any uncertainty on the part of the service developers and confirm to the user that what they have asked for has been understood
  • Open the user up to new requirements as they understand what the service will be able to do to support them
  • Show users the ‘look and feel’ of the proposed service and elicit usability requirements
  • Validate the requirements and identify any errors.

Potential problems include:

  • Endless iteration
  • A view that if the prototype works, the full service can be ready tomorrow.

5.1.3.8 Other techniques

Other techniques that could be used, include:





sdamzavas.net - 2020 год. Все права принадлежат их авторам! В случае нарушение авторского права, обращайтесь по форме обратной связи...