James Cadle Business Analysis Techniques: 72 Essential Tools for Success

Подождите немного. Документ загружается.

192

in some of the Agile approaches to development by the replacement of

requirements-based testing with test-driven requirements. In this situation the

emphasis on communication with testers focuses on the detailed deﬁnition of the

acceptance criteria that must be met, and it is these that are used to drive the

development of test plans and test scripts, rather than the actual requirements

themselves. While this approach certainly has many merits, the optimum

strategy is to follow best practice both in the deﬁnition and documentation of

requirements and in the development of their respective acceptance criteria.

This builds an important bridge between the disciplines of requirements

engineering and testing, resulting in the more eﬀective delivery of quality

solutions to business problems.

Technique 59: Requirements validation

Description of the technique

Once requirements have been documented various checks need to be made, to

ensure that the quality of these requirements is as high as possible. This is true

for the individual requirements as they are identiﬁed and developed, and also

when the set of requirements is complete enough to be passed forward to later

stages of development. This section focuses on a range of these checks that can

be made on the requirements, rather than any subsequent testing of the solution

that is derived from them.

Before looking at the range of techniques that can be employed to improve the

quality of requirements, it is worth examining the diﬀerence between the terms

‘veriﬁcation’ and ‘validation’. We deﬁne them as follows.

Requirements ensures that the requirements deﬁnitions and any supporting

veriﬁcation: models meet the standard necessary to allow them to be used

eﬀectively to guide further work. Veriﬁcation ensures that the

requirements have been deﬁned correctly. It constitutes any

checks undertaken by the business analyst and other key

stakeholders that determine whether the requirements are

ready for subsequent formal review by customers and end

users, and provide all the information needed for any further

work to be undertaken based on them. In other words,

veriﬁcation ensures that things are done right.

Requirements ensures that all requirements support the delivery of value

validation: to the business, fulﬁl its goals and objectives, and meet

stakeholder needs. In other words, validation ensures that

the right things are done.

Obviously it is as bad to build the wrong thing right as it is to build the right thing

wrongly. The guidance provided here helps to ensure that the right thing is built

right, not just in terms of the requirements themselves, but more importantly in

term of the ultimate solutions delivered as a result of these requirements. Without

this there is of course even the possibility that we end up building the wrong thing

wrongly.

BUSINESS ANALYSIS TECHNIQUES

193

Using requirements validation

In order to achieve quality in requirements deﬁnition by the application of both

veriﬁcation and validation techniques we need to consider all of the points listed

in Table 6.5.

As Table 6.5 suggests, before we can employ the various techniques for

undertaking both veriﬁcation and validation we should be aware of the criteria

against which the requirements need to be evaluated. This includes not only an

understanding in principle of what constitutes a well-deﬁned requirement, but

also a clear view on which customer objectives need to be met.

When looking at what makes a good requirement, it always worth keeping in

mind that diﬀerent stakeholder groups will have diﬀerent perspectives on what

is important in the deﬁnition of a requirement. For example, some stakeholders

have more interest in whether the requirements are deﬁned according to local

standards, whereas others are more interested in consistency across the

requirement set. Since all these diﬀerent views need to be incorporated into

any veriﬁcation checks, we will describe them all here. Here are the main

characteristics against which individual requirements and sets of requirements

can be checked in order to achieve quality. They should be:

DEFINE REQUIREMENTS

Table 6.5 Considerations for veriﬁcation and validation

What to check against Techniques for

carrying out checks

Veriﬁcation Quality criteria for a Static testing (peer group

good requirement reviews, walkthroughs,

technical reviews,

inspections)

Feasibility checking

Validation Business objectives and Static testing (peer group

stakeholder goals and reviews, walkthroughs,

measures that the solution technical reviews,

is meant to deliver inspections)

Necessity checking Metrics and

KPIs Scenarios and prototyping

Stakeholder sign-offs

194

unambiguous; unique;

clear and understandable; categorised;

cohesive; complete;

consistent; correct;

conformant; concise;

current; testable;

modiﬁable; implementation independent;

traceable; owned;

relevant; feasible.

In more detail, requirements should be:

Unambiguous: Each of them should have just one possible interpretation.

Ambiguity is very dangerous in requirements, since it leads,

at the best, to confusion, and, at the worst, to the wrong

thing being built. It is also a potent source of disputes

between analysts, developers and business stakeholders as

to what was really wanted.

Unique: Is the requirement unique, or does it overlap with other

requirements?

Clear and Requirements are useless unless they can be understood by

understandable: all those who have to read them, but this can include people

from a variety of backgrounds with diﬀerent types and

levels of knowledge and experience. The end users of the

proposed system will possess business knowledge but not

necessarily technical expertise, whereas developers may be

in the reverse situation.

Categorised: Has the requirements catalogue been correctly partitioned

by type of requirement, and has each type of requirement

been addressed (in other words, has any key category of

requirement been overlooked)?

Cohesive: While a speciﬁc requirement should relate to only one thing,

all requirements in a set should support the overall purpose

and scope.

Complete: In some ways this is the most diﬃcult characteristic to

satisfy, since omissions from requirements are hard to spot.

The chances of ﬁnding omissions are improved by getting

several ‘pairs of eyes’ to examine the requirements.

Techniques such as the development of a CRUD matrix

(create, read, update and delete – Technique 65) can be

particularly helpful in ensuring completeness.

BUSINESS ANALYSIS TECHNIQUES

195

Consistent: Consistency has a number of aspects in relation to

requirements:

Individual requirements must be internally consistent, or

in other words must not have inherent contradictions

(for example, ‘available to all’ and ‘restricted access’).

Requirements must not contradict each other.

Terminology must be used consistently (for example,

the term ‘customer’ means the same thing in all

requirements).

Correct: In a way, if positive answers can be given to all of the above

characteristics, then the requirements can be considered

correct. However, there is another issue of correctness

here – do the requirements capture the essence of the

problem or issue to be addressed? One approach to checking

this is to make sure that it is requirements and not speciﬁc

solutions that have been captured.

Conformant: It is desirable to have a standard format for the way in which

requirements are documented and presented. Although

standard formats can sometimes be seen as a straitjacket

and not exactly suitable for all requirements, the beneﬁts of

following a standard are considerable and usually outweigh

any disadvantages. Advantages include:

Individuals gathering requirements do not waste time

devising their own formats.

Reviewers of the requirements documentation know where

to ﬁnd things.

Those charged with devising and delivering solutions

based on the requirements have them presented in a

standardised format, making them easier to understand.

Concise: Subject to the need to be as precise and accurate as

possible, it is also desirable to express requirements as

concisely as possible. Over-wordy requirements

descriptions are hard to read, and make it diﬃcult for

readers to grasp the important and essential points.

As well as the need for conciseness in individual requirements, it is important

that there is no redundancy when considering the set as a whole. Redundant

requirements tend to obscure what is important, and may contradict what is

written elsewhere about the same business issue. So some general characteristics

to be observed include the need for them to be:

Current: The requirements should not have been made obsolete by

the passage of time.

DEFINE REQUIREMENTS

196

Testable: An important use of the set of requirements, once a system

has been developed, is in testing the system. However,

requirements can only form the basis for testing if they are

speciﬁc, objective and measurable. There must be a clear

deﬁnition of how it is to be proved that the requirement has

been successfully fulﬁlled.

Modiﬁable: Related requirements must be uniquely identiﬁed and

grouped together in a standard way, in order to be

modiﬁable. This criterion can be satisﬁed by clustering

requirements logically and keeping careful track of

versions.

Implementation The requirement should state what is required, not how it

independent: should be provided, and should not reﬂect a particular

design or implementation. There may be exceptions to this

rule, for instance in the area of interface requirements, or

because of other constraints. This characteristic of

requirements is perhaps the hardest to judge and to

implement.

Traceable: It is often necessary for people studying a set of

requirements to get more information about them by

studying source documentation (such as interview notes

or meeting minutes). This can be particularly useful when

maintaining and supporting a system after implementation.

Each atomic requirement should be identiﬁed unambiguously,

sources of requirements must be recorded, and cross

references between requirements must be in place.

Owned: Has a speciﬁc stakeholder been assigned ownership of

the requirement for the purpose of sign-oﬀ (of both the

requirement and the ultimate solution delivered in response

to the requirement)?

Relevant: It is important that all requirements really are within the

scope of the project, and that their inclusion does not lead

to ‘scope creep’. It is also possible that some requirements,

though within scope, do not add to the overall

understanding of the business need.

Feasible: Each requirement must be capable of being implemented

within any deﬁned constraints such as budget, timescales

and resources available.

In addition to these checks, which are primarily for veriﬁcation purposes, some

form of necessity, priority and objective checking will needed when undertaking

validation prior to any form of sign-oﬀ or agreement to move forward.

One of the most important kinds of check is that of necessity. This involves

performing a critical appraisal of each requirement in order to determine whether

BUSINESS ANALYSIS TECHNIQUES

197

it genuinely addresses a real business need, and is relevant to objectives of the

current project or programme. As the name suggests, necessity checking focuses

on determining the level of actual need for a requirement. This is diﬀerent from

feasibility checking, which is concerned with ascertaining whether a requirement

can actually be achieved in business, ﬁnancial and technical terms. Necessity can

be assessed in terms of three key aspects of each individual requirement or

aggregated set of requirements:

contributing to deﬁned business goals;

addressing the cause rather than the symptoms of a problem;

being a real need rather than just a wish.

Enterprises invest in IT in order to achieve some business advantage, and it is

vital to examine requirements with respect to business goals and organisational

objectives. Any requirements which do not contribute towards the achievement

of these should be at least questioned if not removed.

Having a set of deﬁned criteria against which to check quality is not enough. The

business analyst needs to select the most appropriate technique to use when

undertaking the actual veriﬁcation or validation checks. There are four main

types of static testing techniques (that is, excluding prototyping and actual

testing of the ultimate solution) that can be employed to undertake these quality

checks. They vary in terms of those involved in the process and their level of

formality. They are:

peer reviews and desk checking;

walkthroughs;

technical reviews;

inspections.

Peer reviews and These are similar in execution, the diﬀerence being that an

desk checking: element of software code is desk checked, whereas a

document or model is peer reviewed. The purpose of the

peer review is to identify defects and omissions, not to

provide solutions to the problems – although suggestions

may be given. The desk check is used to identify logic

errors or omissions in code, not to provide solutions to the

problems – although, again, suggestions may be provided.

The peer review is usually an informal review of a

document or model. No formal documentation, fault log or

analysis is produced. Usually the original document is just

marked up and returned to the author. The eﬀectiveness of

such reviews depends upon the motivation of the reviewers

and their willingness to ﬁnd a signiﬁcant number of faults.

They should have a skill level appropriate to the document

being reviewed. A person with programming skills would

review code; a business analyst would review a

requirements speciﬁcation.

DEFINE REQUIREMENTS

198

Walkthroughs: The main purpose of a walkthrough is to impart

information to others. It can be used as part of the learning

process for a team. Participants at the walkthrough may

be able to oﬀer some valuable input, but they are usually

less familiar with the subject than the presenter is.

Walkthroughs are led by the author, and the document

under discussion may be marked up and reworked after

the walkthrough has taken place. In some walkthroughs

the document being discussed is circulated in advance. In

others it is presented for the ﬁrst time at the meeting, and

only the presenter is familiar with its content and

structure.

Technical A technical review is used to subject a document or model

reviews: to intense scrutiny with the objective of improving its

quality or solving the problem it is addressing. For example,

the design of a website may be subject to a technical review

in which the proposed design is circulated in advance, and

participants are asked to ﬁnd faults and omissions in the

design as well as making suggestions for its improvement.

The technical review is a relatively formal process,

generating records of faults found and recording actions to

be taken. It is usually led by a chairperson who attempts to

build a solution out of the contributions made by the

participants. It is not purely a fault-ﬁnding activity, and can

therefore be used to develop solutions rather than just

evaluate current proposals.

Inspections: An inspection is a more formal static testing method. It

follows a deﬁned process based on rules and checklists,

which includes both entry and exit criteria. If a document

does not meet these entry criteria then the inspection does

not take place. The document will only be released when it

passes the exit criteria. Metrics are collected and are used

to improve the documents as well as the processes by

which those documents are produced and reviewed. The

main purpose of the inspection is to ﬁnd defects. It is a true

testing activity.

Once all of the various checking (both veriﬁcation and validation) and reviewing

techniques discussed here have been employed, the formality of sign-oﬀs or

quality gateways for requirements is likely to be a less arduous process, and the

quality of the requirements deﬁned and the solutions that are subsequently

derived from them will be signiﬁcantly higher.

Technique 60: Requirements management

Description of the technique

Requirements management is primarily concerned with the control of changes to

requirements. Throughout the time when requirements are being deﬁned, and

BUSINESS ANALYSIS TECHNIQUES

199

also the period after the requirements set has been baselined, it is important to

have a formal mechanism for their control, authorisation and management. This

can include managing their development, maintaining consistency with other

documents and models, handling changes as they occur, communicating changes

to those concerned, and ensuring that correct versions are referred to at all times.

While this is true of any conﬁguration item that needs to be managed, it is

particularly true of requirements, due to the iterative nature of their development

and the fact that changes to them are inevitable, given the volatile nature of

business, ﬁnancial and technical drivers. Organisations are not static; they

undergo constant change in order to deal with new situations and to respond to

new threats and opportunities. Change itself is not a bad thing, but uncontrolled

change will be very detrimental to the delivery of quality solutions and will

lead to unmanageable scope creep.

The changes in requirements that may need to be reﬂected in order to ensure a

good quality of requirements deﬁnition include:

new laws and regulations;

the results of more detailed investigation;

new ideas;

new people and changes in stakeholder objectives;

new technology;

changes in other systems and processes.

Conﬁguration management is concerned with identifying and distinguishing

between diﬀerent versions of the various requirements documents, controlling

any changes made to these and managing the way the various versions are

grouped together to form a particular set. This discipline applies direction and

control to the deﬁnition of requirements for the purpose of controlling change,

and hence maintaining their integrity and traceability throughout the

development. If this level of requirements conﬁguration management is not

applied, various problems can occur, including:

diﬃculties in identifying the most current version of requirements;

diﬃculties in replicating any previously reviewed version of requirements;

the reappearance of errors and omissions that had previously been dealt

with;

testing or even building a solution from a wrong or incomplete version of the

requirements.

Without an eﬀective approach to requirements management, all of these issues

are likely to occur and to inﬂuence the ultimate quality of the solution. In

addition to managing the requirements in this way, it is also essential to apply

the same levels of control and management to any supporting documentation and

models.

DEFINE REQUIREMENTS

200

A number of elements of the technique of requirements management need to be

considered, including:

baselining;

conﬁguration identiﬁcation;

planning which conﬁguration items should be used;

naming conventions;

version and issue numbering rules;

conﬁguration control;

version control;

problem and issue reporting;

change control.

Baselining: Much of what has been discussed in this section on

requirements deﬁnition has focused on eliciting, analysing and

documenting requirements in an eﬀective way. However, there

will come a point at which the focus will start to move towards

the delivery of solutions based on these. This may be from the

full set of requirements in a waterfall approach, or on a

prioritised subset when a more Agile development approach is

being taken. In both cases, the focus now becomes more one of

formalised control in reaction to change than one of actively

searching for new requirements. At the point when this

transition of focus takes place, the requirements need to be

baselined. After this a diﬀerent set of values will be used when

evaluating what to do when new requirements are identiﬁed or

existing ones extended or amended. Once this change has

happened the main focus moves from elicitation, analysis and

documentation towards conﬁguration and change control,

version control and ensuring traceability. It is vital, however, to

ensure that new requirements agreed after this point are still

analysed, documented, veriﬁed and validated as rigorously as

those introduced before the baseline point had occurred. After

baselining the level of formality attached to requirements

management will vary greatly, depending on the approach taken

to development, the culture of the organisation and the software

tools available to evaluate the impact of proposed change.

Conﬁguration This component of requirements management is concerned

identiﬁcation: with the initial planning undertaken before change control

procedures are implemented. It involves a range of activities,

including:

Decisions as to which deliverables need to be the target

of conﬁguration and version control. These conﬁguration

items would normally include the individual requirements

themselves, the overall requirements priority list and any

BUSINESS ANALYSIS TECHNIQUES

201

supporting models and documentation. It is also important

to ensure that some form of requirements traceability matrix

or product breakdown structure is used to maintain

consistency between individual conﬁguration items.

Agreement as to the naming and numbering conventions to

be used for each conﬁguration item, and as to who has the

authority to change version numbers either forwards, or,

perhaps more contentiously, backwards. This is particularly

signiﬁcant in an Agile development environment, where

ideas may be tried out via prototypes but there will remain a

need for all changes to be reversible. This is impossible to

achieve if good conﬁguration management procedures are

not in place and adhered to.

Decisions about the level at which version numbers and

change control apply. Should this be at the level of the

requirements speciﬁcation itself, a subset of the requirements

catalogue or each individual requirement within this?

Decisions as to what level of history of changes needs to be

maintained, and to whom this is to be circulated each time a

change is made.

Conﬁguration Once the conﬁguration items and their groupings have been

control: agreed, the mechanisms for actual requirements conﬁguration

and control must be deﬁned. This control is applied to all

conﬁguration items, to ensure that only the correct and current

versions are used during the remainder of the development.

This element of requirements management includes:

The implementation of a controlled area to set up a library of

conﬁguration items, and the allocation of speciﬁc levels of

responsibility to particular roles and individuals, with items

only being accessible by the person responsible for their area,

and any changes only permitted within the constraints of

this deﬁned procedure.

Control of defects or error reporting. Any problems identiﬁed

with conﬁguration items will be reported to the librarian, so

that each problem can be investigated, and appropriate

action taken, in a controlled manner.

The deﬁnition and implementation of a formal change

control process. This includes impact analysis,

decision-making and the change implementation itself.

Ensuring that everyone is working on the correct version of

any item. At all stages of any piece of work this is vital. To

achieve it, any changes made must be controlled, so that it is

always possible to identify the latest version. In turn, this

means that any changes are only made to these latest

versions (thereby avoiding the problem of reintroducing

errors that have been corrected previously).

DEFINE REQUIREMENTS