BUSINESS ANALYSIS

The incremental delivery lifecycle is illustrated in Figure 13.6. This lifecycle is based
upon early work to establish feasibility and conduct the analysis and design for the
solution. In this version of the model, these stages are followed by two incremental
delivery phases, each consisting of development, testing and implementation. The most
pressing requirements are delivered in Increment 1 with the rest following in Increment
2. In practice, there may be further increments, depending upon the project context and
the business requirements.

Figure 13.6 The incremental lifecycle (© Assist Knowledge Development Ltd.)

Feasibility study
Increment 1
Development
Analysis

Testing
Design
Implementation

Increment 2
Development

Testing

Implementation

A disadvantage of using the incremental lifecycle is that the total cost of delivering the
solution is likely to be higher than delivering the solution in one release. This is due to
the need to ensure that each increment delivered does not compromise the solution
when it is implemented. Also, in the second and subsequent increments, it is necessary
to carry out a specific form of testing known as regression testing, to make sure that the
additional features do not cause problems within the delivered solution. The high level
analysis and design for the solution is defined such that the design is future-proofed and
can accommodate the later increments. If this is not done, inconsistencies, errors and
conflicts may arise that diminish the quality and effectiveness of the solution.

This lifecycle utilises the linear structure defined in the waterfall lifecycle but also allows
for incremental development and delivery. The need for a complete set of requirements
and an overall design is one of the fundamental differences between the incremental
lifecycle and the iterative approach described below.

The iterative lifecycle

A feature common to the waterfall, ‘V’ and incremental models is that a complete set of
requirements is gathered at the start of the project, which then forms the basis for all
subsequent work. An alternative approach is represented by a spiral model as originally

340
 DELIVERING THE REQUIREMENTS

devised by Barry Boehm (1986) in his article: ‘A spiral model of software development
and enhancement’. Boehm’s original perception of the spiral model incorporated the
concept of iterations (or ‘rounds’ as Boehm called them) and used prototyping to reduce
risk when developing software for complex situations. This developed into the basis for
early Agile approaches such as RAD.

With the advent of Agile methods, such as DSDM and Scrum, iterative development has
increasingly used prototyping and related techniques in order to evolve the detailed
requirements and the corresponding software features. The Agile methods apply the
generic principles shown in Figure 13.7.

Figure 13.7 Principles underlying the Agile approach (© Assist Knowledge Development Ltd.)

Collaborative Prioritised Timeboxed Evolutionary

working requirements iterations development

Empowered Incremental Continuous Experiential

teams delivery testing learning

These principles focus on the following:

yy Collaborative working: The development team members, from both business and
technical domains, work together collaboratively.
yy Prioritised requirements: A prioritisation approach, such as MoSCoW (see Chapter
10), is used to identify the different levels of priority among the features to be
delivered.
yy Timeboxed iterations: The concept of a ‘timebox’, where a time limit is set for an
iteration or ‘sprint’, during which an iterative approach is used to complete an
identified set of work items.
yy Evolutionary development: Detailed requirements evolve through a series of
product development iterations, typically using exploratory techniques such as
prototyping.
yy Empowered teams: The development team, which includes business staff and
software developers, is self-organising and empowered to make decisions about
the software development work.

341
BUSINESS ANALYSIS

yy Incremental delivery: The solution is deployed in increments, with each subsequent

increment providing additional functionality or improved performance. This allows
for early delivery of product features that offer benefit to customers.
yy Continuous testing: The software is tested continuously as testing is an integral
part of the iterative development approach. Automated testing tools may be used
to support this.
yy Experiential learning: Learned experience informs the approach to the development
work. Where this work does not deliver a desired outcome it is not perceived as a
waste of time but instead as an integral part of the iterative learning process.
It is essential that business analysts understand these key principles and that they are
able to adapt their skills and toolkit as necessary.

A generic Agile model that encompasses the key aspects of iterative software development
is shown in Figure 13.8.

Figure 13.8 The generic Agile lifecycle (© Assist Knowledge Development Ltd.)
Establish
business need
and evaluate
options

Establish
solution
backlog
Plan Deliver solution increments
solution
increment

Develop solution
Plan
Iteration
release(s)
Requirements

Analysis and design

Development

Test

Iteration 1.. n
Evaluate
Deploy and
evaluate
Feedback solution increment

The model begins with understanding and establishing the business need; a perceived
business need initiates the generic Agile lifecycle. The stages within this lifecycle are
described in Table 13.2. The arrows on Figure 13.8 show the overall sequence. The
dotted arrows show optional revisiting of previous stages in the light of feedback
generated during solution planning, development and deployment.

342
 DELIVERING THE REQUIREMENTS

Table 13.2 Stages of the generic Agile model

Stage Description

Establish Each change initiative is initiated by an identified business

business need need. This may originate from the external environment, where
and evaluate a change requires an organisational response, or may reflect
options an internal requirement resulting from strategic or tactical
change. It is often the case that a stated business need is
revised following the investigation of the situation (see Chapter
5). Understanding the issue to be addressed and expressing it
clearly is vital to ensure that any proposed solution will deliver
the required outcome.
A feasibility study is usually conducted to determine the options
that the business might pursue in order to meet the business
need and to evaluate the costs, benefits, impacts and risks
of each option. The feasibility study may also recommend a
preferred option.
Once a solution increment has been deployed, there may be
feedback that requires the solution to be reconsidered. The
benefits review may also identify where additional features or
changes are required if the business benefits are to be realised.
This may mean further consideration of options to deliver the
outcomes required by the organisation.
Establish Once an option has been selected, the high-level business
solution backlog requirements are defined from which more detailed solution
requirements can be derived. The business requirements are
explored and defined as solution requirements, using techniques
such as user stories, use cases, storyboards, wireframes and
prototyping. A product/solution backlog is established as a
repository for these requirements.
The backlog is maintained as the solution development
progresses. This involves prioritising and reprioritising the work
items within the backlog and determining when they are to be
fulfilled. Feedback from deployed increments is also considered
and used to update the backlog as necessary.
Plan solution The increment, or release, of the solution is planned in advance
increment of the development work. This involves deciding on the features
and characteristics, documented as solution functional and non-
functional requirements within the product backlog, that are to
be deployed within the increment. A release backlog, containing
the requirements selected for inclusion within the increment,
may be formed.

(Continued)

343
BUSINESS ANALYSIS

Table 13.2 (Continued)

Stage Description

Develop solution An iterative approach is applied to elaborate and analyse the

requirements, and design and test the solution. Each iteration
is planned so that the requirements to be addressed within
that iteration are identified and prioritised. Typically, these
requirements include some that have a ‘must have’ priority,
some that have a ‘should have’ priority and possibly some with
a ‘could have’ priority. The different prioritisation levels are used
to provide contingency in the timebox. For example, where some
‘must have’ requirements are found to be complex and require
more time than initially allocated, features of a ‘should have’
or ‘could have’ priority may be deferred or dropped, in order to
ensure that the timebox delivers the mandatory requirements.
Several iterations may be required to develop working software
that may be deployed into operation. The working software
should address both functional and non-functional requirements.
Once the planned increment has been developed and agreed, a
production-ready solution is built that can be deployed into the
live environment.
Deploy and The tasks necessary to deploy the working solution into the live
evaluate solution operational environment are conducted, including data take-on,
increment data conversion, preparation of documentation, end-user
training, installation of the live environment and transition to the
service delivery team.
Once the solution has been in operation for a period of time, an
evaluation is undertaken to determine whether it has met the
business objectives and is working satisfactorily. This review
may lead to perfective maintenance to improve aspects of the
solution such as performance and usability. Where sufficient
functionality has been deployed, a benefits review is conducted
to examine whether or not the benefits have been realised
and, if not, to identify further actions required to enable their
realisation.

Disadvantages of the lifecycles

The waterfall, ‘V’ model and incremental lifecycles consist of a sequence of stages and,
as a result, incorporate a high level of control. While this offers many advantages, in
practice, the use of these lifecycles also has disadvantages:

yy There may not be time to define all the requirements at the outset. This may
result in a poor BRD containing requirements that are not of sufficient quality or
inconsistent documentation where only the most important or urgent requirements
are well defined.

344