James Cadle Business Analysis Techniques: 72 Essential Tools for Success
Подождите немного. Документ загружается.
162
and exceptions). The attendant clears the screen ready for the
next customer who is standing in line, and wishes the customer a
good day.
Scenarios should always be written from the user’s perspective, and should
consider any decision-making undertaken during the task. This often leads to
the description of the scenario in the form of an interaction between the user and
other actors (both people and systems), perhaps even using the storyboarding
technique discussed later.
In order to try and assess whether the set of scenarios that has been developed
has sufficient breadth and coverage, it is useful to develop a model that
describes various properties of the scenarios and compares them with the mix
of circumstances found within the organisation. Where there is a mismatch, this
is likely to highlight the need for additional scenarios to be considered. This
comparison will also help the business analyst to decide when enough scenarios
have been written to cover a particular area.
A scenario coverage model can be used to set targets and review the number of
scenarios that are written in each area, and will help in the clarification of
non-functional requirements and support the estimating process. It is developed
after the first few scenarios have been written and when the important scenario
properties are understood, based on an understanding of what is important to the
various users within the organisation.
Factors to consider when developing a scenario coverage model include:
an appreciation of the major problems in the current situation that will need
to be resolved in the future situation;
the range of users (this is needed to determine how many users there are
within each user role);
frequencies of different types of business events;
a selection of example scenarios;
an appreciation of the properties and coverage of each scenario.
Each scenario has a number of characteristics that can be assessed to evaluate its
coverage. These can vary depending upon what is required. The three main
questions that are considered here are:
How many users does this scenario involve?
Which organisational units are included in this scenario?
How frequently are the tasks that are included in the scenario performed?
The examples in Tables 6.1 to 6.3 show the way a number of scenarios are assessed
under these three headings, and compare the scenario coverage with the expected
percentages in the set of business situations.
BUSINESS ANALYSIS TECHNIQUES
163
DEFINE REQUIREMENTS
Table 6.1 Scenario analysis by user population
User population Garage Garage Customer at Garage
attendant supervisor kiosk manager
Expected use 50% 20% 28% 2%
Scenario 30% 18% 15% 5%
coverage
Evaluation of More Reasonable May need No more
discrepancy scenarios match more scenarios
required scenarios required
Table 6.2 Scenario analysis by environment
Environment Front office Back office Maintenance
Expected use 50% 25% 25%
Scenario 30% 23% 1%
coverage
Evaluation of More scenario More
discrepancy scenarios coverage scenarios
required sufficient required
Table 6.3 Scenario analysis by frequency of use
Frequent tasks Walk-in fuel Sell lottery Issue loyalty
payment ticket card
Expected use 40% 23% 10%
Scenario 90% 0% 0%
coverage
Evaluation of Enough Some Some
discrepancy scenarios scenarios scenarios
covering this area required here required here
164
In the examples shown here, the factors chosen when undertaking the
comparison are:
User population: Is each section of the user population covered by at least
one scenario? Are the roles of users who will be expected to
have a greater involvement in the use of the system
covered by a greater proportion of the scenarios?
Environment: Access will be given to the IT system in various different
locations – do the scenarios defined cover each of these
different locations?
Frequent tasks: There are certain tasks that are key to the business, and the
expectation is that these will be performed most often – do the
scenarios cover these frequent tasks more than the others?
In building the scenario coverage model, the focus should be on developing a
minimum set of scenarios that cover all the areas that are important to users,
and emphasis should be given to ensuring that coverage of these areas is in
proportion to their occurrence within the business environment.
Using scenarios
Scenarios should be written to show what working with the new system is
anticipated to be like. They can be considered as the first prototype of the new
system; this prototype might subsequently be disposed of, or it might form the
basis of an evolutionary development of the solution. Initially they may be
written to abstract out the details of how the system will actually work, but
later versions will be described in sufficient detail to drive the creation of a
more comprehensive prototype if appropriate. Scenarios can also be written to
summarise cases that the current system has to deal with, as a way into
understanding the current system (if this is required).
The key uses of scenarios include:
to help elicit and clarify requirements;
as a validation technique;
to identify and investigate boundaries between tasks;
to identify areas of potential IT support;
as the basis of prototyping and modelling;
as the basis of test criteria and acceptance testing;
for subsequent user training or as inputs to any Model Office (i.e. setting
up a mock-up of the live environment for testing purposes prior to final
implantation).
Scenarios should be considered as concrete examples of specific paths through a
task, which provide a complete story. The additional technique of storyboarding
(described later in this section) can be used to support their development, acting as
BUSINESS ANALYSIS TECHNIQUES
165
a key input to subsequent prototyping. In some extreme cases, alternatively, the
use of ‘hothousing’ (also described later in this section) may even be appropriate.
Once scenarios have been described they should be validated, to assess whether
they represent the actual interactions between actors. The script should be
analysed for possible usability problems, by asking questions such as:
Is this a scenario which people find difficult to complete successfully?
Do errors occur frequently when undertaking this?
To what information does the user need access during this scenario?
Could the task be rationalised or simplified in some way?
What use could be made IT to automate some parts of the scenario?
Technique 51: Storyboarding
Description of the technique
A storyboard, which may be used in conjunction with scenario definition, is a
low-fidelity prototype usually consisting of a series of diagrams or screen sketches
showing navigation routes through a task or a series of screenshots. Storyboards
are often used by designers to illustrate the structure and navigation through
scenarios, but are also particularly useful for discussing requirements with user
groups. An initial demonstration storyboard may be a throwaway or could be used
as input to subsequent evolutionary prototyping, depending on circumstances.
Storyboards are used by both business analysts and solution designers to help
illustrate and organise their ideas and obtain feedback from other interested
parties. They are particularly useful for multimedia presentations and website
designs, or where there is significant interaction between people and systems.
It is part of the business analyst’s role to try to see the bigger picture and to try to
communicate this to others involved. Storyboards can assist in getting this right.
The technique of storyboarding also helps the business analyst to break this bigger
picture into smaller components in order to focus on one at a time. In addition
to enhancing communication and organisation of ideas, this helps the business
analyst to identify specific areas where more analysis or research is needed.
Storyboards therefore provide not only a visual representation of the bigger
picture but also a mechanism for zooming in on the various aspects of the
detail as required.
Storyboarding usually starts as a pencil and paper technique for designing and
testing ideas, particularly those related to user interfaces. Although a storyboard
is not as realistic as a full prototype, it has the advantage that it can be done
quickly without the use of technology. Thus its application does not involve the
need for any particular technical expertise.
A storyboard shows the sequence of events, and specifies the user actions that often
interact with them, for a range of situations. A further possible refinement of
storyboards is to use index cards or Post-it notes to permit rapid changes in the
design. These permit users to evaluate several possible sequences in a single session.
DEFINE REQUIREMENTS
167
The storyboard in Figure 6.1 shows the interaction between a customer and a
travel agent’s representative, and the various screens navigated during the
booking of a holiday. It helps to emphasise the importance of the holiday
brochure, the physical flight tickets and the visual map, as well as showing
the possible screenshots themselves.
Storyboards can change a lot as you are working on them. When you feel you
have a good first attempt, with lots of detail and a reasonable sequence, you can
move to using software to log all the information agreed so far and to support a
very visual way of doing things, while allowing everyone in the team to have a
shared copy for subsequent use. Presentation software such as PowerPoint works
well for this. Each individual slide can be used as a frame in the storyboard, and
it is easy to insert images, text, tables, charts and screenshots as required. Most
presentation software also allows you to add notes at the bottom of the slide,
which can be printed off separately from the slides and will provide additional
support when talking through the storyboard with users.
The main benefits of storyboards are that they:
provide an overview of a system (both the manual and the automated parts);
demonstrate the functionality of the various storyboard elements;
demonstrate the navigation sequence;
check whether the presentation is accurate and complete;
can be evaluated by users early in the requirements gathering process.
Technique 52: Prototyping
Overview
Many industries benefit from the use of mock-ups, models, visual designs and
prototypes to establish requirements, confirm expectations and test the
achievability of objectives. These can range from simple storyboards through
scale models to fully working prototypes. They can be temporary, transient, or
disposable – here called throwaway prototypes. Some, however, may be
evolutionary prototypes, for example working models, which will ultimately
evolve into the eventual solution (usually as part of some Agile or iterative
development lifecycle). For instance, in a software-related project, screens may be
prototyped and refined before the detailed logic is written to make them fully
functional. Once reviewed and agreed, these then become the basis of the design
of the final product.
The benefits of building prototypes are significant. Prototyping is one of the many
techniques that Agile approaches such as DSDM/Atern (DSDM Consortium
2007) and Scrum (Schwaber 2004) adopt to ensure effective communication
between stakeholders, whether from different parts of the business, different
organisations or different cultures. The Agile approach advocates the use of such
models to improve communication and to bring ideas to life by making products
more visible early in the lifecycle. As discussed previously, prototyping may
involve diagrammatic representations such as storyboards, often driven by the
definition of a range of scenarios. The intention is to produce something visible,
DEFINE REQUIREMENTS
168
valuable and in a working state as soon as possible, in order to clarify
understanding and minimise subsequent reworking. Only then is it possible for
users to say whether what has been produced is what they actually need, and
thereby improve the quality both of the definition of requirements and of the
ultimate solution delivered.
Prototyping can help improve the effectiveness of solution development, when it
is used carefully and in appropriate circumstances. It enhances communication
between business users, business analysts and solution developers. It is a
technique which helps all parties involved to understand the relationship
between business process and IT support, and helps to identify additional
requirements and scenarios.
Description of the technique
A prototype is a model which forms an exemplar or pattern, on which a more
detailed design can be based or formed: something that serves to illustrate the
typical qualities and characteristics of the potential solution. It may evolve into
the eventual solution (an evolutionary prototype) or it might always have been
intended to be an experimental model (a disposable prototype).
Throwaway or rapid prototyping refers to the creation of a working model that
will eventually be discarded rather than becoming part of the finally delivered
software. After preliminary requirements gathering is accomplished, a simple
working model of the system is constructed to show the users what their
requirements might look like when they are implemented into a finished
system.
Evolutionary prototyping is quite different from throwaway prototyping. The
main goal when using evolutionary prototyping is to build a very robust prototype
in a structured manner, and then constantly refine it in an iterative way. The
reason for this is that the evolutionary prototype, when built, forms the heart of
the new system, on which any improvements and further enhancements will be
built. Evolutionary prototyping is usually at the core of any Agile development
approach.
There are three key aspects that should be considered when undertaking
prototyping, regardless of whether the prototype is disposable or evolutionary.
They are determined by the following questions:
What is the scope to be covered by the prototypes? This can range from one
specific task to the whole system, or simply be a subset of the scenarios.
Will the prototypes be high or low fidelity? The prototypes may range from
sketches drawn on paper (similar to storyboards) to well-defined real screens
developed using the target technical environment.
How extensive will the functionality of the prototypes be? They may use
simulated data, or they could access fully working system data complete with
business rules and testable functionality.
Early in the requirements elicitation process, it may be useful to produce low
fidelity, limited scope prototypes to demonstrate to the users the result of
BUSINESS ANALYSIS TECHNIQUES
169
their requests. At a later point in the process of eliciting requirements, a
prototype that is more extensive might be more applicable.
Once the prototyping sessions have been completed it is important to ensure
that appropriate documentation is updated to incorporate any new or amended
requirements. In addition, the impact of any agreed changes needs to be assessed,
to check for effects on other requirements and supporting documentation.
It is possible that conflicts with other requirements may have been raised as a
result of the prototyping exercise.
One of the main issues with the whole prototyping process is that of managing
the users’ expectations. This is because:
simple prototypes may create a negative impression within the target
community;
high fidelity prototypes may cause users to expect immediate delivery of the
full solution;
impressive response times of prototypes may raise users’ expectations of the
new system’s performance to an unrealistic level.
Categories of Prototype
Prototypes of the solution are the basis on which tests can be planned and
performed. Prototypes can be designed to test both the functional features and
non-functional aspects of the solution such as usability and the levels of
performance required. Three main categories of prototype cover these very
different purposes and objectives:
business or prototypes – used to elicit requirements and an understanding
requirements of the features or functionality required;
usability prototypes – used to define, refine, and demonstrate user
interface design, usability, accessibility, look and feel, and
perhaps such aspects as security and availability
(non-functional requirements);
performance or prototypes – used to define, demonstrate, predict and test
capacity how systems will perform under peak loads, as well as to
demonstrate and evaluate, for example, volume handling,
response times and availability (i.e. other non-functional
aspects of the system).
One physical prototype could cover more than one of these categories, but it is
often confusing to mix the categories within a single prototyping session with a
user. The greatest benefit of considering these categories is to ensure that no
aspect of demonstration or testing has been missed. For example, a business
prototype may be constructed early in the project, while a performance or
capacity prototype will only be able to allow testing of actual performance during
subsequent stages, once a working product with sufficient volumes of test data is
available. The same components of the prototype are thus tested more than once,
for different reasons each time.
DEFINE REQUIREMENTS
170
Using prototyping
When defining the scope of the individual prototyping sessions it is useful to
distinguish between vertical and horizontal prototyping. Evolutionary
prototyping may evolve vertically, where each feature of the proposed solution
is developed prior to moving on to the next feature. Each feature may be a
complete increment or part of an increment.
A horizontal approach, where the breadth of the solution is developed before the
depth is considered, could be used as an alternative. The benefit of this approach
is to demonstrate clearly to all stakeholders the overall scope of the system, and
to establish areas where conformity to a standard or style is required, for example
in the user interface to an IT system.
It is possible to combine both vertical and horizontal prototyping by adopting a
T-shaped prototype, where the breadth is developed along with a finished slice of
the proposed solution.
Failure to manage the users’ expectations during the application of the
prototyping technique may lead to dissatisfaction within the project and with
the delivered system. It is important to manage these user expectations actively,
and this involves:
setting out the objectives of the prototyping exercise up front, including:
agreeing levels of scope, functionality and fidelity,
deciding whether the prototype being demonstrated is vertical, horizontal
or a combination of these,
categorising the objective of the prototyping session (business, capacity or
usability);
informing the users of the extent of the prototype, and clearly defining any
impact this may have on performance, usability, and so forth;
keeping the users up to date with the progress of the development process;
not promising that the finished system will achieve the performance (and
other non-functional requirements) of the prototype if it is not certain that it
can be achieved.
Advantages of prototyping
There are many advantages to using prototyping as the basis of requirements
definition and demonstration. These include:
Reduced time Prototyping can improve the quality of requirements and
and costs: the specifications provided to solution developers.
Because changes cost exponentially more to implement
the later in development they are detected, the early
determination of what the user really wants can result
in faster and less expensive delivery.
BUSINESS ANALYSIS TECHNIQUES
171
Improved and Prototyping requires active user participation and
increased user allows users to see and interact with a prototype, enabling
involvement: them to provide better and more complete feedback and
input to specifications. User examination of the prototype
prevents many of the misunderstandings and
miscommunications that occur when each side believes
the other understands what they said. Since users know
the problem domain better than anyone in the solution
development team does, increased interaction can result
in a final product that has greater tangible and intangible
quality. The final product is also more likely to satisfy the
user’s desire for functionality, look, feel and performance.
Disadvantages and risks of prototyping
Despite being an excellent technique for requirements clarification and
evolutionary solution development, prototyping carries with it a number of
drawbacks and risks which should be considered carefully before embarking on
its use. These include:
Poor The prototyping replaces any formal analysis and
documentation: documentation, leading to difficulties later, particularly
when the finished system is in a maintenance situation.
Changes Poor prototyping reduces credibility, while good prototypes
to user may raise user expectations to an unachievable level.
expectations:
Unmanageability: Large prototypes may become unmanageable and lead to
‘skeleton’ systems.
Exclusion of Involving insufficient people in the prototyping sessions
some users: may lead either to ‘personalised’ solutions (ones that just
reflect certain people’s ideas) or to ‘historic’ solutions (those
that just perpetuate what has been done in the past).
Poor system Untested or insufficiently tested prototypes may result in
performance: unacceptable performance once the system is in live
operation.
Over-optimistic Optimistic estimates based on prototypes may upset
estimates: overall delivery timescales for the final system.
Technique 53: Hothousing
Description of the technique
Hothousing is an Agile development technique that can be used to clarify and
enhance the quality of requirements and delivered solutions. Hothouses are
intense face-to-face workshops (often held over three days) that bring together
people from the IT development and delivery communities along with their
customers, business partners and key users.
DEFINE REQUIREMENTS