Business Analysis Principles

Version 1.0

John Jacobi, Senior Business Analyst

March 2012

13 Bruton Street
London
W1J 6QA
Mobile: +44 (0)7966 335314
Fax:
+ 44 (0)207 333 1558
Email: [email protected]

NashTech

Page 1 of 5

Offshore Software Development

CONFIDENTIALITY

This document is distributed on a restricted basis, is commercial in confidence to the recipient,

and may not be used for any purpose other than that associated with a NashTech project. The
contents of this document may not be disclosed to any third parties without the expressed
advance written authorisation of NashTech.

TABLE OF CONTENTS
1

INTRODUCTION ................................................................................................................... 3
1.1

Business Requirements .................................................................................................... 3

1.2

Functional Requirements .................................................................................................. 3

1.3

Estimating ......................................................................................................................... 5
CONCLUSION ...................................................................................................................... 5

NashTech

Page 2 of 5

Offshore Software Development

INTRODUCTION

Requirements are key to a project. Without these there is little way of establishing what needs to
be done, the scope of the project or even how to start. Whatever methodology is used for a
project there must be some requirements and there must also be some way to control, manage
and document these. NashTech business analysts are skilled and experienced at helping and
assisting clients in getting their business requirements formally captured and documented for a
project.
1.1

Business Requirements

Generally, business requirements are gathered and documented in a common commercial

package such as Excel or Word. NashTech business analysts are able to work with this
information, regardless of the amount that has been produced. The information is then put
through a Requirements Management Process:

Gathering the tasks of identifying and collecting the business requirements from
current documents, stakeholders, meetings and workshops.

Analysing the tasks associated with the investigation and clarification of what the
requirements actually mean, whether each requirement should be addressed within this
project and the priority of each requirement.

Documenting this is the formal recording and classification of requirements into

functional and non-functional; the deliverable from this is the Business Requirements
Catalogue, which is then ready for approval.

Approving the sign-off by the business stakeholders that these are the requirements
for the project.

The gathering, analysing and documenting will generally occur concurrently and will often have
several cycles during the process. The approving is generally the last task.
1.2

Functional Requirements

At NashTech the business analysts work on the principle of taking the business requirements
and producing sufficient documentation using a number of approaches to:
Functionally specify the required system, so that:
a) The business users can understand what the new system will do for them
b) NashTechs developers in Vietnam can start to technically design and develop the
proposed system
Specify the non-functional requirements
Produce a fixed-price quote (if required). NashTechs business analysts are experienced
and skilled at knowing the level of detail they need to get to, to be able to produce a
fixed-price estimate. The level of detail required is not a full-blown specification but is in
a sufficient format to understand the transactions within a use case. Therefore,
NashTech can often provide a fixed-price quote prior to fully detailed and completed use
cases (and a Software Requirements Specification) have been produced.
NashTech refers to sufficient documentation as some methodologies and approaches will state
an endless list of documents that need to be produced before design and development can start.
NashTech has developed its approach over many years and is experienced enough to know
what needs to be produced, resulting in projects starting with confidence.

NashTech

Page 3 of 5

Offshore Software Development

Through workshops, meetings and question and answer sessions NashTech will transform the
business requirements into documented functional requirements. The preferred approach is to
produce:
1. Use Case documents
2. Software Requirements Specification
The use case document describes the steps (actions) between a user (but termed more
specifically an "actor") and the software system that is required. The document is composed into
the following structure:

Goal the goal to be achieved by the use case

Brief Description
Business Requirements the business requirements that are covered by the use case
Actors - the persons or external software systems that interact with the use case
Preconditions the conditions that must be in place prior to the use case starting
Postconditions the conditions that will exist after the use case has been completed
Flow of Events, which are made up of:
o The Basic Flow
o Any Alternative Flows
o Any Sub-flows
Business Rules the business rules that must be adhered to by the use case
Assumptions any assumptions that have been made during the creation of the use
case
The structure of NashTechs Software Requirements Specification is split into two main sections:
1. Functional Requirements (which will include use case diagrams and a use case
catalogue) and any further functional requirements that have not been captured in the
use cases.
2. Non-Functional Requirements:
o User Interface
o External Interfaces
o Usability
o Performance
o Security
o Audit
o Volumetric Data
o Timing and Dependencies
o Supportability
o Reliability
o Migration
o On-line User Documentation and Help System Requirements
o Purchased Components and Licensing
o Legal, Copyright, and Other Notices
o Applicable Standards
In most projects the above two documents are sufficient for NashTech to proceed but, where
appropriate, further documents will be generated, which include:

Style Guide specific characteristics for the style of screens, windows and popups etc.
Screen Mock Ups

NashTech

Page 4 of 5

Offshore Software Development

Some purists will shake their heads in disbelief with regard to creating screen mock ups but
where appropriate (for the right project and client) it is a good tool to have as users can
visualise what they will be doing on a screen. The NashTech business analysts can then easily
translate these into use cases.
1.3

Estimating

As previously stated, NashTech can provide estimates for the design, development and testing
of the required system from the use cases produced by the business analysts. An estimating
method known as Use Case Point (UCP) is used, which has been developed over many years.
Within a use case it is crucial for the business analyst to identify the transactions that occur
between the user and the system; these need to be identified at a high level, for estimating
purposes. Transactions are "round trip" processes from the user to the system and back to the
user, finishing when the system awaits a new input stimulus, for example:

User enters the search criteria and clicks enter. The System processes the search and
returns a list of customers appropriate to the search criteria (1 transaction)

The total number of transactions allows NashTech to categorise whether the use case is:
Simple
Average
Complex
There are a number of other factors that can influence the estimate, which include:
Technical Factors
Environmental Factors
Project Type (Pilot, Maintenance, Development)
Risk Factors
From the categorisation of the use cases, the identification of actors and other factors,
NashTech has enough information to produce a robust estimate.

CONCLUSION

NashTechs business analysis principles help to capture, analyse and prioritise clients business
requirements, resulting in a catalogue list that reflects the full extent of a project. NashTech then
takes those requirements and describes them functionally, to allow all parties, whether they are
technical or business, to understand the system and what will be delivered.
It should be noted that use cases and UCP estimating are not the only way NashTechs
business analysts approach requirements. Other methods that are tried and tested are used, for
example, business analysts may functionally specify the requirements (not in use cases) and
then produce an estimate using what is known as a Work Breakdown Structure. In essence,
NashTech will use the right approach for each individual project.

NashTech

Page 5 of 5

Offshore Software Development