James Cadle Business Analysis Techniques: 72 Essential Tools for Success
Подождите немного. Документ загружается.
182
Once this high-level clustering has been completed it is usual to regroup the
requirements in each set further, into lower-level groupings. In this case the actual
groupings chosen will depend not only on local standards, but also on considerations
such as the type of project and the volume of requirements of each type.
Typical lower-levels groupings that could be considered include:
Functional
requirements:
by business area;
by business process;
by use case;
by access type;
Non-functional
requirements: by non-functional type, such as:
performance;
access;
availability;
backup;
security;
General
requirements:
project constraints;
legal matters;
look and feel, and style;
cultural aspects;
Technical
requirements:
hardware;
software;
telecommunications.
In addition to providing clear partitioning of the requirements specification,
grouping into this standard set of types also provides a prompt to the business
analyst to ensure that each type has been fully considered and analysed during
the requirements engineering process. When this is not done it is easy to miss
requirements, particularly non-functional and technical ones. Their omission will
almost always lead to subsequent problems during testing or delivery, and
ultimately when the final solution is implemented.
BUSINESS ANALYSIS TECHNIQUES
183
Links and dependencies between requirements
As well as clustering the set of requirements into groups, it is also useful to
document the links, relationships and dependencies between individual ones.
These links can support planning (at both the project and the timebox levels),
prioritisation, traceability, and allocation into discrete work packages and
implementation phases. The links may be between one functional requirement
and other functional requirements, between functional requirements and a set of
non-functional requirements, or between requirements and related supporting
models (such as use cases and use case specifications, Technique 62) or even
supporting prototypes (Technique 52). In addition to identifying the links of the
requirements themselves, it is often useful to document these relationships
separately, for example in a requirements traceability matrix (Technique 61).
Levels and hierarchical decomposition
When looking at the individual requirements within the set (particularly the
functional ones), it is important to identify at what level it is appropriate to define
each requirement. Is a high-level or coarse-grained definition sufficient, or is this
too vague? This decision will depend on a number of considerations, including
which models, more detailed supporting specifications and prototypes are being
employed. However, it is usually necessary to decompose most high-level
requirements hierarchically into more granular levels of detail in order to
support clear communication, to facilitate scenario analysis and to allow for
additional prioritisation at these lower levels.
Requirements negotiation and conflict analysis
It is often the case that, when analysing requirements, we find that some of them
are mutually exclusive or represent opposing views as to what should be done.
Sometimes this conflict relates to a disagreement regarding the priority of the
requirement, where one stakeholder believes that it should be higher than that
suggested by another. The process of requirements analysis cannot be completed
successfully until such conflicts have been resolved and there is a clear, agreed
way forward. In these cases the ideal way of resolving any conflict is via some
form of negotiation. This may be carried out in a workshop or perhaps with a
closed discussion between the relevant stakeholders. In both cases the analyst
can perform the role of facilitator in order to gain consensus, while maintaining
an awareness of the overall business objectives, priorities and dependencies
between requirements.
When seeking to undertake requirements negotiation, it is useful to employ the
following three-step approach.
1. Requirements discussion. All stakeholders involved should be alerted to
the situation, and open discussions should be held to resolve the problem.
In order to move interested parties towards an agreed position, this will
normally involve a discussion as to the impact and contribution of each
requirement in question.
2. Requirements prioritisation. When agreeing the priorities of requirements
the use of a well-defined standard approach to prioritisation such as MoSCoW
(must have, should have, could have, want to have but won’t get this time
DEFINE REQUIREMENTS
184
round – see Technique 55) is strongly recommended. It is particularly helpful
at this point to investigate not just which requirements are critical for a
particular stakeholder, but why. A workshop environment may enable
stakeholders to appreciate other stakeholders’ points of view.
3. Requirements agreement. This allows for the negotiation to move forward
in a constructive way, gaining consensus without the need for a confrontation.
Only when it turns out to be unsuccessful should the analyst revert to
escalation or to seeking an imposed decision from the sponsor or executive
committee.
Once this agreement has been achieved, it will be possible to complete the
organisation and structuring of the set of requirements, ready to move on to more
formal validation.
REQUIREMENTS DEVELOPMENT
Technique 57: Requirements documentation
Description of the technique
Requirements come in a number of forms from a wide range of sources. For
consistency, communication and change-control purposes, it is important to
document and store them in a standard way across the organisation. The level of
detail and specific content of this standard documentation set will depend on a
number of factors, including:
local policy and standards;
the lifecycle being used for solution delivery;
the structure and roles of the development team;
the level to which the requirements apply – they may be for part of a contract,
as in the case of outsourcing or sending work offshore;
the relationship between the requirements themselves and any related
models and supporting documents.
In addition to these characteristics, it is also worth noting that the names of the
various requirements documents produced within a given organisation will vary,
as will the scope of what is covered within them. This is true both of the document
containing the full set of requirements and supporting documentation (names
include ‘requirements specification’, ‘business requirements specification’ and
‘requirement document’) and the document containing the detail of individual
requirements (which might be called a ‘requirements catalogue’, ‘requirements log’
or ‘prioritised requirements list’). For reasons of clarity, this chapter will use the
terms ‘requirements specification’ and ‘requirements catalogue’ when referring to
these and their possible content. A core set of requirements documentation is
emerging, and is achieving overall consensus across the discipline of requirements
engineering. It is this common core that is described here, although all
organisations are likely to use a subset, adaptation or extension of it. There are
also a number of proprietary approaches available, some of which are driven by
the facilities and features available in requirements management software
BUSINESS ANALYSIS TECHNIQUES
185
support tools such as RequisitePro and Doors. Whatever approach is adopted, all
requirements need to be thoroughly and consistently documented, and this should
include, ultimately, an agreed resolution of every requirement defined.
Using requirements documentation
First, let us consider the typical content of the requirements specification,
which acts as an overall document for the full set of detailed requirements and
any supporting material. Its structure is shown in Table 6.4.
DEFINE REQUIREMENTS
Table 6.4 Content of a typical requirements specification
Introduction and Business context This section is used to explain the
background Business objectives background to the analysis project,
Project context and documents any constraints or
Definition of scope assumptions on which it is based.
Drivers and constraints It is useful, too, to identify the
Assumptions stakeholders in the project and
Stakeholder list explain what their interests are.
Functional model Context diagram This illustrates what system
Use case diagram processes are likely to be required.
Use case descriptions Use cases are ideal for this, but
Requirements there are other similar techniques
traceability matrix that may be used.
Data model Class diagram An understanding of the data in a
Entity relationship system helps enormously in
diagram understanding the system itself.
Data dictionary We suggest using an object class
model for this, as it fits with the
UML approach, which is becoming
very widespread, but a conventional
relational data model (for example,
an entity-relationship diagram)
would serve the same purpose.
(Continued)
186
While the requirement specification provides a mechanism for documenting much
of the information needed to support the requirements definition process, it is the
detail that is provided for each individual requirement within the requirements
catalogue that is most significant in ensuring an effective description of
requirements, and therefore, ultimately, the delivery of a solution of the highest
possible quality.
It is in the contents of the requirements catalogue that there is the most variation
across organisations. While not all of the items listed below are always needed, it
is difficult to see which ones could be sensibly omitted without causing subsequent
problems during design, testing and implementation. The requirements catalogue
establishes a common understanding between users and business analysts
throughout the project, and supports the controlled management of any proposed
change to requirements.
The descriptions listed below identify the key items needed within the
requirements catalogue to document requirements adequately. In some cases
these items will cross reference to other documents, models or specifications
that provide more detailed definitions of specific aspects of the requirement,
for example to supporting use cases, use case descriptions and the definitions of
data items and elements.
Requirement This is a unique identifier for the requirement, usually
identifier: structured in such a way as to show the type of requirement,
with a number to show the decomposition of requirements,
if applicable.
BUSINESS ANALYSIS TECHNIQUES
Table 6.4 (Continued)
Requirements Functional requirements This is the core of the document,
catalogue Non-functional and is explained in more detail later
requirements in this chapter.
General requirements
Technical requirements
Glossary of terms Glossary Any terms used within the
Naming conventions document, and also any
terminology specific to the
organisation that might otherwise
confuse or mislead readers, should
be explained.
187
Requirement This gives a one-line shorthand title for the requirement.
name:
Business This can be used to indicate to which area(s) of the organisation
area/ domain: the requirement relates.
Requirement This is a fuller description of the requirement, written in
description: business terms.
Source: The source of the requirement is usually the person or
department who requested it, or, in some cases, the legislation,
policy or other document that gave rise to it. This enables the
business analyst to identify where to refer back for further
clarification of the requirement.
Owner: The owner is the person who can provide expertise and
detailed advice about the requirement. The owner should also
decide whether the requirement is complete and correct, and,
later in the system development lifecycle, whether it has been
satisfied by the solution or not. The owner is usually the
senior business person or sponsor for a particular area of the
business, and may also be the source of the requirement.
Priority: This gives the degree of importance of the requirement in
relation to others, usually by using some formal approach to
prioritisation such as MoSCoW (Technique 55).
Stakeholders: This names the person or persons who have an interest in the
successful resolution of the requirement, along with details of
their interest. Identifying stakeholders and their interests for
each requirement provides a useful reminder to the business
analyst to ensure that all relevant stakeholders’ interests
have been covered, and later, satisfied (see Technique 30).
Type of Categorising each requirement by standard type provides one
requirement: way of partitioning the catalogue, and assists with
completeness checking.
Associated This defines any non-functional requirements associated with
non-functional a particular functional requirement. Alternatively it can be
requirements: to create a separate entry in the requirements catalogue, used
where a non-functional requirement applies to a number of
functional requirements.
Acceptance These are the measures (or benchmarks) that will determine
criteria: whether this requirement has been met by the system. They
specify how the system may be tested by the end users to
prove that the requirement has been met. They are sometimes
referred to as ‘fit criteria’. This is an absolutely fundamental
entry in the catalogue, and must be developed with great care.
DEFINE REQUIREMENTS
188
Justification This gives the business reason why the requirement has been
and benefits: included, and/or the way its prioritisation has been determined.
Related Cross references to source documents, or to documents where
documents and further information about the requirement may be obtained,
supporting are found here. An example would be documentary evidence of
material: the requirement for audit purposes. It is very common to use
this item to refer to any use cases related to the requirement
(for functional requirements – Technique 62), hence in effect
producing a useful requirements traceability matrix
(Technique 61).
Related This is for cross references to other requirements. These may
requirements: be included because they have a connection with the same
business issue, or because they depend upon the successful
resolution of this requirement. This also shows where a
non-functional requirement should be applied to a functional
requirement, or where an individual requirement is further
decomposed into more detailed ones.
Resolution: This says how the requirement is to be included in the solution,
or gives the reasons for its exclusion from the final solution,
annotated with agreement from all appropriate stakeholders.
Comments: This item lists other information useful in understanding the
requirement, and/or for formulating possible solutions.
Some information, such as the requirement name and the source, will be
available immediately, but other areas will only be completed as the definition of
the requirements progresses. The resolution of the requirement, for example, is
recorded once it has been decided which phase this specific requirement will be
delivered in. By the end of the project this item should contain a resolution for
each requirement, showing how it was delivered or why it was not included, with
a note saying when this was agreed and by whom. In this way the requirements
catalogue provides a useful audit trail of the requests from all stakeholders and
how they were ultimately resolved.
Figure 6.5 is a typical example of a requirements catalogue entry, in this case
relating to the introduction of an airline’s internet booking system. No detailed
resolution has been recorded at this point, since, although it has been agreed to
deliver this feature in Phase 1 of the development, no decision has yet been
taken on the way the requirement will actually be satisfied in the final system.
Technique 58: Acceptance criteria definition
Description of the technique
Once requirements have been identified, documented and validated they will be
used to drive the development and subsequent delivery of solutions. The quality
of this ultimate delivery depends on a wide range of factors, one of which is the
quality of the requirements themselves.
BUSINESS ANALYSIS TECHNIQUES
189
One key aspect of the quality of a requirement is that it is ‘testable’. In addition to
being used as a communication channel between the business and the development
communities, requirements must also provide testers with a clear definition of
what is required from them in terms of the creation of test plans and expected
results. To facilitate this, it is vital that, in addition to the description of the
requirements themselves, the business analyst also defines detailed acceptance
criteria for each requirement. Also known as ‘fit criteria’ or ‘test completion
criteria’, these acceptance criteria are absolutely vital in ensuring that the correct
solution is delivered. In fact, a requirement that does not contain a clear
definition of its acceptance criteria will probably need to be clarified further
during testing, resulting in unnecessary reworking and extra costs.
As we will see here, acceptance criteria need to be defined in quantifiable and
measurable terms for all types and levels of requirement. It is important to note
that a requirement’s acceptance criteria are not the same thing as the resulting
DEFINE REQUIREMENTS
Requirement ID: F-073
Requirement name: Book a flight
Business area/domain: Airline reservation system
Related documents: Minutes of focus group meeting on 12
th
November.
Related requirements: Take credit card payment.
Resolution: Due for delivery in release one of the system.
Comments:
Source: Customer focus group
Owner: Head of Internet Booking Services
Priority: Must have
Stakeholders: Airline customers, airline staff
Type of requirement: Functional
Requirement
description:
Having identified themselves as registered, customers
should be able to book themselves a flight via a secure
web site.
Associated
non-functional
requirements:
1. Access should be limited to the specific customer
themselves and any authorised airline staff.
2. Ensure timely response.
Justification:
A customer focus group stated this to be a key requirement as
the airline’s competitors already offer this service.
Acceptance criteria:
In addition to displaying the correct flight details, the system
should confirm the booking by displaying a reservation
reference code and take note of the date and time that the
booking was made.
Response time should be within 10 seconds for 95% of
transactions.
Figure 6.5 Example requirements catalogue entry
190
test scripts and test cases, which will be produced later and against which the
delivery of the requirement will ultimately be tested. The responsibility for
definition of the acceptance criteria lies with the business analyst in conjunction
with the organisation, while the responsibility for the development of the test
scripts lies with the testers, often with support from the end user community.
This leads to a clear separation of concerns between the key roles that the
business analyst needs to involve. They are:
the customer – who provides the driver for requirements, and the domain
knowledge and experience;
the developer – who fulfils the requirements, using technical knowledge and
experience;
the tester – who verifies that the system does indeed do what the customer
wants it to do, as defined via the requirements.
Requirements can only form the basis for testing if they are specific, objective and
measurable. The careful definition of the acceptance criteria for a requirement
should ensure that the last two of these are adequately achieved. The key
consideration here is to attach some form of quantification and scale of
measurement to each requirement. Without this, it will not be possible to know
whether the requirement has been met. Testing is only complete when these
specific measurable acceptance criteria have been met. If such a mechanism for
measurement cannot be identified during the development of a requirement, this is
usually an indication that the requirement is not specific enough, or does not
represent a single discrete requirement. If you cannot write acceptance criteria for
what you are about to build, you should not be building it. The requirement and its
related acceptance criteria should therefore be redefined until it becomes possible to
identify such a measurement mechanism. Often the problem is that the acceptance
criteria for requirements are not defined in advance, but only during development
or testing, or, even worse, once the work has been done.
Using acceptance criteria definition
The acceptance criteria for requirements, used subsequently to produce detailed
test plans and test data, should quantify the behaviour, the performance or some
other demonstrable quality of the final end product. In order for implementation
of an individual requirement to be considered acceptable, it is often necessary to
meet more that one measurable criterion; this is why we use the plural, ‘criteria’,
here. Acceptance criteria must be defined for all types of requirements
(particularly functional and non-functional ones), and at the same level of
granularity as the definition of the requirements themselves.
The development of acceptance criteria can clearly be linked to scenarios and
storyboards (Techniques 50 and 51), and, in the case of functional requirements,
use cases and use case descriptions (Technique 62). The use of scenarios
particularly helps in defining the scope of a requirement along with its respective
acceptance criteria. Defining the requirements and their related acceptance tests
together can force earlier conversations with the users to take place, and ensure
that more relevant detail is described than would be the case if one were not
considering the acceptance criteria.
BUSINESS ANALYSIS TECHNIQUES
191
Even when it is not possible to allocate specific objective measures to a requirement,
it is still important to try and allocate some scale of measurement that will enable
the testing community to decide whether an acceptable standard has been achieved.
For example, different individuals may have different interpretations of what ‘an
intuitive system’ would look like, and it will be necessary to define a range of
acceptance criteria for different groups of potential users. In some cases, where any
potential criteria chosen seem very subjective, a more objective assessment may be
obtained and verified by some recognised domain expert, independent accreditation
body or standard piece of legislation such as the Disability Discrimination Act.
It is also necessary sometimes to extend the definition of the acceptance criteria
for a specific requirement with some tolerance to allow for fluctuations in the
working environment. For example, consider the following acceptance criteria for
the handling of customer enquires.
The acceptable response time shall be no more than 3 seconds for 90 per cent
of enquiries and no more than 5 seconds for the remainder.
The more detail provided and care taken where defining acceptance criteria, the
more likely will be success in producing a quality implementation, and the less
likely is confusion to occur during testing.
In addition to the clear definition of acceptance criteria for functional requirements,
driven by discussions with business stakeholders and the use of scenarios, it is
also important to define acceptance criteria for each individual non-functional
requirement attached to the functional requirements, to ensure that the operation
of the delivered solution achieves the required standard in terms of performance,
availability, security, robustness and usability. In particular, definition of
acceptance criteria in the tricky area of usability can be made more measurable
by applying the acronym PLUME, which stands for measures of:
Productivity: how long various tasks take to accomplish in a given time;
Learnability: how much training is needed in order to achieve a specified
level of proficiency when undertaking a task;
User satisfaction: subjective responses a user has to the system when asked;
Memorability: how robust the learning about the system use is, and how
long ability to use it is retained without retraining;
Error rates: accuracy in carrying out the task (this measure is
particularly useful in conjunction with the productivity
measures set).
As discussed earlier, a requirement which is not supported by well-defined
acceptance criteria is likely to cause problems of communication, resulting in
delays, omissions and inaccuracies in the delivered solution – so much so that a
school of thought is emerging that the acceptance criteria definition is even more
important that the definition of the requirement itself. This has manifested itself
DEFINE REQUIREMENTS