O'Reilly logo

Business Analysis Techniques by Paul Turner, Debra Paul, James Cadle

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

BUSINESS ANALYSIS TECHNIQUES
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
184
DEFINE REQUIREMENTS
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 docu
mentation
First, let us consider the typical content of the requirements specication,
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.
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)
185

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required