BUSINESS ANALYSIS

APPROACH

Whichever lifecycle is adopted, it is necessary to decide on an approach to the project

work. The approach concerns the method, standards, events and documentation styles
that are adopted on the project. There are several published approaches to business
process improvement and software development that offer techniques and standards.
The UML is a popular approach, providing a range of modelling techniques that may be
used to represent different views of a system.

Figure 13.1 reflects the need to consider the context and the lifecycle when deciding
which approach to adopt. In deciding this, there are two key areas that should be
considered: the approaches to the development and the delivery of the solution.

Development

When considering the development approach, there are two key questions to answer:

1. Will it be possible to have ongoing close collaboration with the business

representatives during the development of the solution?
2. Will it be acceptable for the detailed requirements to evolve during the development
work or is it essential that the detailed requirements are defined and agreed up
front?

Where it is acceptable, if not preferable, for the detailed requirements to evolve

during the development of the solution, it is vital that the business representatives are
available to work closely and collaboratively with the development team. If both of these
conditions are met, many of the requirements may be defined using techniques such as
use cases, user stories, scenarios and prototypes. These techniques provide a basis for
exploratory conversations and requirements clarification.

However, if the requirements need to be defined in depth prior to the solution development
work, or there is likely to be limited contact with the business representatives while the
development work is under way, formal documentation that includes a well-formed
BRD, business process models and a data model is needed (see Chapter 11).

Delivery

The delivery of the solution may be done incrementally or in one major release. The
approach taken depends upon the context, in particular the status of the existing solution
and whether the organisation requires an entire new solution. Where a legacy system
is to be replaced, it is probable that a direct changeover to a complete replacement
solution will be required and an incremental delivery approach will not be acceptable.
Where this is a new application, or an existing product that is to be improved in some
way, there aren’t legacy concerns and the organisation requires speedy delivery of
some features, a phased delivery using incremental releases is preferable. The context
section earlier in this chapter provides the basis for deciding whether the organisation
requires the delivery of all of the requirements in one release, or if a phased approach
that delivers incremental change is necessary.

346
 DELIVERING THE REQUIREMENTS

Software development approaches

There are several published, defined approaches to developing software products, each
of which provides a framework and standards. Two key approaches are described below.

The UP
The UP from the OMG offers a generic software development process that can be
configured to meet the requirements of an organisation. Its structure acknowledges
that no single development process fits all organisations, development environments
and cultures. It is designed to be suitable for small releases such as enhancements
to existing software products as well as large solution development projects. The UP
provides a guide on where and how to use the modelling techniques from the UML
effectively; techniques from UML are discussed in Chapter 11. The UP is both an iterative
and incremental approach. It is based upon the principle of using UML modelling
techniques to explore and elaborate requirements through a series of iterations.
Increments are developed that may be combined for one release of the entire solution
or may be implemented as phased releases.

Scrum
Agile approaches have become increasingly popular for a number of reasons:

yy The need for organisations to respond quickly to fast-changing business situations.

yy The difficulty – indeed, sometimes the impossibility – of knowing what is wanted
at an early stage of the project.
yy The importance of flexibility when deciding how to fulfil requirements. For example,
there may be a requirement to protect certain areas of system data but there may
be several possible ways to achieve this, each of which may be considered before
deciding on the most appropriate approach.

Scrum is a widely used Agile software development approach, which is based upon
some key roles and principles. The key roles are described in Table 13.3.

Table 13.3 Roles used in Scrum

Development Responsible for developing the product. This team should be

team empowered to be self-organising and should include software
development professionals and business representatives.
Scrum Master Responsible for ensuring that the development team can perform
the work by removing any impediments to progress and providing
required resources.
Product owner Responsible for the governance of the product backlog and acts
as the VoC. This includes the prioritisation of the items within the
backlog and the selection of items for development within a specific
iteration (sprint).

347
BUSINESS ANALYSIS

In a Scrum project, the development work proceeds in a series of ‘sprints’, which are
timeboxed iterations typically between one week and one month in duration. The aim
of the sprints is to deliver working software using evolutionary prototyping. Close
collaboration with the business representatives is vital for this approach to be effective
as the requirements are often defined as user stories (see Chapter 11) so need to be
further elaborated through discussion between developers and business staff.

The product backlog is the prioritised repository for the user stories, and any
requirements defined using alternative styles. The product owner directs the work by
allocating the items from the product backlog that are to be developed during each
sprint. At the start of each sprint, there is a sprint planning meeting where the backlog
items are considered and the work of the sprint is designed. An important issue
concerns the quality of the items held within the product backlog. There is little point
in the development team working on backlog items that are unclear or insufficiently
defined as this can cause a great deal of work for the development team and can result
in wasted effort. This may be avoided if the Scrum team agree on a set of criteria that
determines whether or not a backlog item is ‘ready’ for development. Where an item
does not meet the agreed criteria, the development team may decline to accept it for
development within a sprint.

A daily scrum (a meeting) is held to review the progress of the sprint. These meetings are
intended to last for a maximum of 15 minutes and are sometimes referred to as ‘daily
stand-ups’ because the attendees usually stand up, which helps to ensure adherence
to the time allocation. The Scrum Master is the facilitator for these meetings. The daily
scrum meetings focus on what was accomplished yesterday, what is planned for today
and what obstacles have been encountered.

The working software that is available at the end of a sprint is presented to the business
community during a ‘sprint retrospective’. This is a timeboxed event that should last
up to three hours. A retrospective enables the development team to evaluate the work
completed during the sprint and plan the work of the next sprint.

The rationale underlying Agile approaches assumes that it is impractical for the set of
requirements to be defined completely at an early stage in the project and for the system
to be developed and implemented in its entirety. Products developed using Scrum are
delivered incrementally into live operation. Scrum applies the concept ‘Definition of
Done’, which is a ‘shared understanding of expectations that the Increment must live
up to in order to be releasable into production’.1 The software developed during a sprint
may not be sufficient to be implemented into operation as it may form only part of an
increment. Software developed during several sprints may need to be combined to form
a releasable increment.

Agile approaches, such as Scrum, run the risk that the emerging prototypes are not
documented sufficiently, may cover only a limited number of potential scenarios or are
fragmented. All of these factors can lead to considerable difficulties when the software
product is in live operation. This is, however, often a result of how these approaches
are applied. The Agile Manifesto prioritises working software as the product from the
development process; however, it also states clearly that there is value in documenting
systems and that testing is needed throughout the development activity.

348
 DELIVERING THE REQUIREMENTS

Scrum depends on close cooperation between the business community, the product
owner and the developers, and on the ability to prioritise the work to be done.
Prioritisation is explored in more detail in the next section.

The importance of prioritisation

Prioritisation is extremely important during solution development as there are always

many requirements and limitations on time and budget. Clearly, all requirements are
not deemed of equal importance, and prioritisation helps to determine what should be
worked on during each iteration or should be released into live operation.

There are many prioritisation approaches. Some are relatively simple to define, for
example, high, medium or low, while others have greater depth and complexity. It is
notable that the major issue regarding prioritisation concerns the ability of the team to
agree on a prioritisation level and, if a simple structure is used, to agree on what the
levels mean.

The MoSCoW prioritisation scheme, which was introduced in Chapter 10, is particularly
helpful as the levels are clearly defined (although gaining agreement on allocation of
levels to requirements is still likely to present challenges). The MoSCoW prioritisation
categories are related to the development and delivery of the solution as follows:

yy Must have requirements are delivered in the first deployed increment. These form
the ‘minimum usable subset’ of requirements and may be developed iteratively
using evolutionary prototyping.
yy Should have requirements provide one of the mechanisms for introducing contingency
and flexibility. Where they are included in the plan for a particular increment, they may
be deferred to the following increment if difficulties are encountered and they cannot
be delivered within the defined timescale. They could be implemented as manual
‘workarounds’ in the short term, which is extremely helpful when deadlines are
tight. ‘Should have’ requirements that have not been delivered in the first release are
allocated a ‘must have’ priority in the second increment.
yy Could have requirements may be included in the set of requirements under
development, particularly if they are relatively easy and inexpensive to
incorporate with the higher priority requirements. Where timeboxes are used,
these requirements provide some contingency, as they can be left out should the
development team run out of time.
yy Want to have, but won’t have this time requirements are recognised as those
that should be set aside and considered during one of the later increments. This
is an essential element for incremental delivery approaches as it provides a
means of identifying requirements for later phases of the solution and specifically
annotating them as such. These requirements may be allocated a different priority
once the point arrives for their delivery to be considered. For example, there may
be a specific date when some of these requirements become mandatory and,
when planning for that release, the prioritisation may be changed to Must have.

The MoSCoW approach is also extremely useful for prioritising other types of business
changes. For example, when developing process documentation, MoSCoW prioritisation

349
BUSINESS ANALYSIS

helps to identify the elements that must be included at the outset, those that can wait
for the next version and those that could be dropped if there is insufficient time; or
when developing team capability, the MoSCoW categories may be used to prioritise the
different skills in order to highlight those that are most important and those that are
not needed until later.

Use cases, described in Chapter 11, are useful during prioritisation as they can
provide a highly visual way for business actors and developers to understand the
level of priority assigned to each of the use cases. While modelling the potential scope
of the entire solution, a use case diagram can be used to partition the solution into
practical implementation packages for the short or longer term and provide a means
of considering the different options available to deliver the business requirements. Use
case descriptions are also helpful as they define alternative scenarios through a use
case and identify the main success scenario. Each scenario may be allocated a different
priority level to aid the development work and early delivery of key product features.

Software package approach

This chapter has considered the lifecycles and approaches that may be used when
developing a software product, using either an in-house development team or an
outsourced software development supplier. However, in many situations, organisations
prefer to adopt commercial off-the-shelf (COTS) solutions where possible, using these
to implement best practice within business processes and software applications. The
reasons are not hard to identify:

yy A COTS solution is almost certainly going to be less expensive than the cost of a
bespoke software development process since, by definition, the development costs
for a COTS are shared among the purchasers and users, typically through the use
of licence fees.
yy Implementation should be faster, as the solution exists and only has to be set up
as required by the organisation.
yy Standard support and maintenance packages are available from the software
vendors so a dedicated in-house team is not required and costs are clearly defined.
yy COTS vendors keep their software up to date, for example, in line with legislative
changes, and the costs associated with these updates are shared among the user
community.
However, there are some drawbacks associated with using COTS including:

yy No COTS package is likely to be a perfect fit with the requirements, so either the
organisation must adapt their processes to what the package can do or they must
pay for expensive tailoring and customisation, thereby partly negating one of the
benefits of the COTS approach.
yy If competitive advantage is required, it is unlikely to come from a software package,
since all organisations working in a particular business domain can buy the same
software and adopt the same work practices. However, most COTS offer built-in
customisation features and, if the deployment and use of the software is done
effectively, these may offer an opportunity for differentiation from competitors.

350
 DELIVERING THE REQUIREMENTS

If a COTS solutions is desired, care must be taken that the defined requirements, in the
main, focus on what the system is required to do, rather than how it is expected to work
(unless there are non-functional requirements where the ‘how’ encompasses factors
such as performance and security). The most effective use of a software package
requires a willingness to change business processes and procedures where necessary
to align with how the package works.

ROLES IN DELIVERING REQUIREMENTS

The roles required to deliver a solution depend upon these three factors:

yy the context of the organisation and project;

yy the nature of the lifecycle selected;
yy the approach adopted.

Typically, a project team is set up that includes some or all of the following roles:

yy project manager;
yy business analyst;
yy product owner;
yy solution architect;
yy developer;
yy tester.

The point at which these roles are required differs depending upon the nature of the solution,
the lifecycle to be used and the approach chosen. Example situations are as follows:

yy Where a solution is concerned with changes to business processes rather than

to software applications, the business analyst is needed to provide a business
process improvement service (see Chapter 4). This involves analysis of the business
processes and definition and design of the business process improvements. Roles
such as developer and tester are unlikely to be required for this work. If the work
is complex or extensive, a project manager is likely to be needed to plan, monitor
and control the project.
yy Where a software product is to be developed or procured, the business analyst role
is needed to complete much of the early requirements definition work. The business
analyst is also needed to elaborate the initial requirements so may develop a fully
formed BRD or may define the items within a product backlog and ensure that
they are in a sufficiently ready state for development. A product owner is needed
to govern the product backlog (where this approach is used). Developer and tester
roles are needed once the product moves into a development phase. There may
be a need for a solution architect to oversee the different elements of the entire
solution and ensure that they work coherently. Business analysts are required
during product development to facilitate communication between developers and
business staff, clarify requirements, analyse scenarios and impacts, and define
business rules.
351