Business Analysis Practice

DELIVERING THE REQUIREMENTS

• Delivering the solution
• Context
• Delivery
• Lifecycle
• Development and delivery approach
• Roles
• Deliverables
• Techniques
 DELIVERING THE SOLUTION
• Context: the nature of the organization and
project that will provide the basis for deciding
how the solution will be delivered.
• Lifecycle: the process adopted for developing and
implementing the solution.
• Approach: the methods and standards that are
used during the lifecycle.
• Roles: the key roles to be filled during the project.
• Deliverables: the products to be delivered by the
project team.
• Techniques: the management and development
techniques used to plan, analyse and document
the project work.
CONTEXT
• The context for the organization and the project will provide the
basis for deciding how any business changes are to be delivered.
• Organizations are subject to external pressures from customers,
competitors and other business demands and these usually determine
the need for change and the constraints within which those changes
need to be met.
• The key factors to take into account are
• The culture and underlying philosophy of the organization
• The business context for the proposed changes
• Any constraints that impinge upon the project
• The prioritized needs of the business
• The drivers for the project
DELIVERY LIFECYCLE
• It shows in overview the sequence of stages
to be carried out when analyzing,
developing and delivering business changes.
• it does not indicate how the solution is
developed and delivered
• Although they focus on software
development, it is important to align this
work with the broader business changes,
such as the definition of new processes and
revised job roles.
The concept of a systems development
lifecycle
• The development approaches to IT systems are known as systems
development lifecycles (SDLCs)
• The lifecycle covers the entire life of a system from feasibility study to
operation.
• There are two main philosophies that underpin systems development
lifecycles:
• and multi the linear approach, whereby steps are carried out in sequence and
are completed before moving on
• the evolutionary approach, whereby the solution to be delivered emerges
during iterative periods of software development based upon the use of
prototyping -disciplinary teams.
The waterfall lifecycle
• shows the development proceeding
through a series of sequential stages.
• In theory, each is reviewed and signed off
before the next starts.
• The backwards-facing arrows in the
lifecycle indicate the need to check back
at each stage to ensure that the project
has not expanded its defined scope, that
the present stage builds logically on its
predecessor and that modifications to the
deliverables from the previous stage may
be made where required.
The ‘V’ model

• is a variant of the waterfall model and consists of similar stages and

sequence of the work.
• ‘V’ model is based upon the same principles as the waterfall lifecycle,
in effect the waterfall has been bent back on itself following the
development activity. This adds another dimension, showing explicitly
the connection between the earlier – developmental stages of the
project and the later – testing – stages. In particular, the derivation
and usage of the test criteria is made explicit at each stage.
 Extended ‘V’ model

• ‘V’ model has been developed to

show the context and nature of
business analysis work.
• the initial work concerns an analysis
of the business needs and the
development of the business case
that justifies the recommended
solution. This solution sets out the
scope of the business change work
to be explored further in the
requirements definition stage.
• This model is also used to show the
range of business analysis work in
the light of an IT solution lifecycle
Incremental delivery
• When analysing the requirements for the business change solution,
some requirements will be more important, or more urgent, than
others.
• One way of achieving this is to develop and deliver the solution in a
series of increments.
• The incremental delivery lifecycle shows the analysis and design for
the solution being completed initially. This is then followed by two
incremental delivery phases, each consisting of development, testing
and implementation. The most pressing requirements are in increment
1 and the rest follow in increment 2.
Iterative systems development
• 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
and these form the basis for all subsequent work. An alternative
approach is sometimes represented by a spiral model which was
originally devised by Barry Boehm in his article: ‘A spiral model of
software development and enhancement’ (Boehm 1986).
• This developed into the basis for early Agile approaches such as Rapid
Application Development. 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 iterative development approach is
founded upon some fundamental generic
principles
• Evolutionary – Detailed requirements are evolved through a series of iterative
prototyping development stages.
• Empowerment and collaboration – It is a fundamental requirement that the team,
including business staff and IT developers, are empowered to make decisions
during the software development and work as a collaborative team.
• Fitness for purpose – The deliverables are required to be fit for purpose rather
than aligned slavishly with a set of defined requirements.
• Testing all the time – Testing is an integral part of the iterative development
approach so the software should be tested continuously. Automated testing tools
are very useful in doing this.
• Re-factoring – Iterative development adopts an exploratory approach so
any work may be reversed if it does not add value. This is not perceived as
being a mistake or waste of time but instead as an integral part of the
iterative process.
• Incremental delivery – The system is likely to be deployed in increments,
with each subsequent increment providing additional functionality or
improved performance.
• Prioritisation – An approach such as MoSCoW is used to identify the
different levels of priority amongst the features to be delivered.
• Timeboxing – The concept of a ‘timebox’ whereby time limit is set, at the
outset, for the development of part of the system. Prioritisation is used to
provide some contingency in the timebox, for example by including
features of a lower priority that may be deferred or dropped if time does
not allow.
Generic agile model
• Identify options and feasibility - A feasibility study is conducted to
determine the options that the business might pursue in order to address
the business need. This will set out the options available, in particular the
costs, benefits, impacts and risks of each alternative option, and possibly a
preferred option.
• Define and agree business requirements - Once a preferred option has
been selected, the high-level business requirements need to be defined,
from which more detailed solution requirements can be derived. This stage
identifies the scope for the systems development project by defining a set
of highlevel features to be delivered by the solution. These high-level
requirements are also prioritised during this stage.
• Elaborate solution requirments - The high-level business requirements are
explored and elaborated into more detailed requirements for the solution,
using techniques such as storyboards, wire frames and prototyping. An
iterative approach is adopted in order to develop a final, operational
prototype. This confirms the functional requirements to be built and
deployed in the current release. As Agile development projects typically
deliver functionality incrementally, this stage and the following two stages
(engineer solution and deploy solution) will be repeated for each
incremental solution delivery.
• Engineer solution - Once the functionality for the current delivery has
been agreed, a production-ready solution is built that can be deployed into
the live environment. This stage will addresses the non-functional
requirements and technical infrastructure required to turn the operational
prototype into a fully fledged, working solution.
• Deploy solution - The tasks necessary to deploy the working solution into
the live operational environment are conducted, including data take-on,
data conversion, preparation of documentation, end-user training,
installation of the live environment and transition to the service delivery
team.
• Evaluate solution - Once the solution is ‘live’, typically some period of time
after it has been deployed, an evaluation of the solution 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 such as performance and usability. Once the final version is
deployed, a benefits review will be conducted to examine whether or not
the benefits have been realised and, if not, identify any further actions
required to enable their realisation.
Advantages and disadvantages of the
lifecycles
• There may not be time to define all the requirements at the outset and
only the most important or urgent ones can be defined in the time
available.
• It is unlikely that the business actors will know exactly what they want,
particularly if they are moving into new and uncharted areas of business.
Even if they are reasonably knowledgeable about the requirements, it is
likely that there will be areas where they are less certain. These areas could
concern the exact details for some requirements or non-functional aspects.
• t is important to establish some of the business changes quickly in order to
demonstrate capability and achievement, and keep the support of the key
stakeholders.
• The pace of business change is so rapid these days that a completely
defined set of requirements can become out-of-date very quickly
Developing the business solution
• While the lifecycles described above are concerned with software
development, the basic principles also apply to other business
changes.
• Given that most requirements are delivered through a mix of IT and
process changes, the lifecycle chosen for the software elements may
impose a lifecycle and constraints on the other aspects of the
business solution.
• Where a complete solution is to be implemented, the entire set of
process, task and job definitions will be required at the same point.
DEVELOPMENT AND DELIVERY
APPROACH
• The approach will determine the methods and standards to be adopted on the
project.
• Organisations will need to take account of the context and the lifecycles
described above 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: there are two key questions to answer:
• are we able to work collaboratively with the business users during the
development of the solution or is this not possible?
• are the requirements unclear or well understood?
• Delivery: do we require one delivery of the entire solution or a phased delivery
using incremental releases? The context described above will provide 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
Software development approaches
• Two key approaches
• The Unified Process (UP) from the Object Management Group
(OMG) is a generic software development process which can be
configured to meet the requirements of an organisation. The UP
provides a guide on how to use the Unified Modeling Language (UML)
effectively. 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.
• Agile software development approaches include DSDM and Scrum.
The Agile methods provide a means of developing IT systems using an
iterative approach while still ensuring the quality of the software
solution.
• Scrum is a widely adopted manifestation of the Agile approach. The
ScrumMaster is a facilitator for these meetings but is not a project
manager in the conventional planning and directive sense. In a Scrum
project, the development work proceeds in a series of ‘sprints’ which
are timeboxed periods of effort, typically from one week to one
month in duration.
The importance of prioritisation
• there are always many requirements and limitations on time and
budget. Clearly, all requirements are not deemed of equal importance,
and this helps determine what should go into each work package or
iteration.
• It is here that a prioritisation scheme such as DSDM’s MoSCoW
structure, is particularly relevant. (Must have, Should have, Could have
and Want to have but not this time around.)
Software package approach
• in many situations, organisations prefer to adopt commercial off-the-shelf (COTS)
solutions where possible, using these to implement best practice and engender related
business process changes.
• A COTS solution is almost certainly going to be cheaper than the organisation having to
fund the entire development process since, by definition, the development costs are
shared by all the users of the package.
• Implementation should be faster, as the solution exists and only has to be set up in the
way the customer wants.
• Support and maintenance packages are available from the software vendors.
• COTS vendors keep their software up to date, for example in line with changes in
legislation.
• Disadvantages
• No COTS package is likely to be a perfect fit with the requirements
• Unlikely to show competitive advantage
ROLES
• The roles that are required to deliver the solution will depend upon
these three factors:
• the context of the organisation and project; the nature of the
lifecycle selected; the approach adopted.
• Typically, there will be a project team that will include the following
roles: project manager; business analyst; developer; tester
DELIVERABLES
• The products that are to be delivered will also vary depending upon
the nature of the solution, the standards of the organisation and the
lifecycle and approach adopted.
• deliverables is that they should always be suitable for the purpose.
TECHNIQUES
• Techniques adopted during the development will depend upon the scope of
the solution, the standards of the organisation and the lifecycle and
approach adopted.
• The use of a waterfall-based lifecycle will require the use of formal
documentation that has been reviewed and ‘signed off’.
• The an Agile approach has been adopted for a project, this will determine
the techniques to be used.
• Organisations may have defined templates for requirements documentation
that include standards for modelling business processes and IT
requirements. They may also have templates for organisational documents
such as job role definitions and job descriptions.
• Many organisations have adopted support tools that impose both a
development process and the modelling standards to be used.
Thank You