MaddisonWard_Business_Requirements_Capture

Defining tight business requirements

Version 1.4July 2010

Business Requirements Capture

2Copyright © Maddison Ward 2006

The Requirements Challenge

p.2

Articulating requirements clearly and crisply is one of the greatest challenges in developing IT systems.

Poorly defined requirements is one of the most frequent causes for IT programmes to go seriously off-track.

Delays caused as a result of fully understanding and articulating the precise business requirements imperil the delivery deadline and costs companies considerable unnecessary sums.

If a requirement cannot be articulated for the solution in a timely fashion, this will cause a shortfall in the development velocity of the delivery team.

Each delivery team has a direct cost (not including the programme “overheads” of Project Management, Integration Testing etc). Poorly articulated requirements frequently results in dead time (unproductivity) and dead money.

If a requirement is changed as a result of further business thinking, and this change results in rework, then depending in the extent of the change and the amount of development that has already been undertaken, this could cost a very small cost or a significant sum.

The key issue, however, is that cost notwithstanding, the delivery deadline is put increasingly at risk the more the requirements are changed, unarticulated, unclear or unforthcoming.

It is therefore absolutely essential that the requirements are developed in a timely manner if the project or programme delivery is to be successful. In practice, this means:-

Ownership of the business requirements is comprehensively understood and agreed. Decisions regarding requirements is made rapidly Business requirements have been thought through and agreed with all significant stakeholders prior to the

project needing them to start development. Requirements can evolve through the delivery lifecycle, but this is a very different engagement model (called

Agile) and requires very different business disciplines.


What is a business requirement?

p.3

Quite simply, a business requirement is an unambiguous statement of need.

Requirements cover all parts of a business process and are closely aligned with the business target operating model. Examples include:-

What the solution should look like (both to the users and the customers) – I wants/I needs Data required to be captured, how it relates to other data and what the data will be used for Validation of the data (for example, a valid date format – this could be US style, UK style etc) Business rules to be applied to the data, or to the process. These could be, for example:-

Event driven: Send an email to a student advising him/her where an assessment will take place Data driven: A student cannot do a “History of Art” module as part of a “Computer Science” degree Time driven: The student has asked a tutor to call him on this day at this time regarding study intensity Geography driven: The student cannot apply for an English student loan whilst resident of Scotland. Permissions driven: This student’s grade can only be changed by the supervising tutor

Permissions of users authorised to change the data infers we know all the users, we fully understand the organisation structure and therefore the approvals process / permissions / escalations of all those users.

Product catalogue & product rules are particularly relevant where the product and/or its interrelationships are complex. Using a mobile phone company as an example:-

A customer can only purchase a priceplan with a data component for a phone that supports 3G A customer must be warned that a Nokia charger won’t work with an iPhone A customer cannot migrate onto a new priceplan until 3 months before the end of his/her contract A customer cannot purchase a International Roaming option in the US for a phone that doesn’t support the US network

All of these rules and permutations have to be worked out in advance of the developers building a solution. Although some aspects of a product catalogue, for example, can be “user configurable”, the dimensions, framework and extent of the rules have to have been articulated to build the requisite level of flexibility into the solution.


How are business requirements derived?

p.4

In practice, being able to articulate a business requirement unambiguously and with crystal clarity is a considerable challenge.

Historically, business requirements were all derived at the beginning of programme and were articulated prefixed with “The solution must have the ability to...” (this was called “waterfall development”). However, this led to many problems:-

Firstly, because these requirements were derived at the beginning of a programme in one huge exercise, by the time the solution had been built and tested (in many cases, several years later), the business requirements would have changed to such an extent that the solution no longer met the business need. Efforts would be put in place through “change controls”, to try to keep pace with the evolving business need, but frequently, the amount of change would overwhelm the developer’s ability to keep pace, resulting in many large development programmes failing.

Secondly, the skill in being able to think through a business need and articulate it in a crisp, succinct and unambiguous way was beyond the abilities of all but the very best business analyst, and frequently, this ambiguity resulted in a system being built that didn’t quite do exactly what the business wanted.

Thirdly, the temptation was for the business to stray from trying to define the business need or business outcome and wander into trying to design the solution, resulting in a sub-optimal implementation.

To remedy this issue, software engineering techniques were developed through the last decade to enable business needs to be derived and articulated more easily and more iteratively.

Use of “storyboards”, “narratives”, “use-cases” and “persona’s/actors” to walk through “business scenarios”, “day-in-the-life-of”, or colleague “I needs” analysis allows the business to articulate what they want the solution to do agnostic of the technical solution and with closer alignment to the actual desired business outcome.

Breaking the overall solution down into particular business capabilities allows the business to focus only on one part of the solution at a time.

Using an iterative process, the business needs can be prioritised and refined over the lifetime of the programme, offering less opportunity for divergence.

Several software engineering techniques use flavours of this method, including Rational Unified Process and Agile.


Requirements pitfalls?

p.5

The following are examples of bad requirements:-

The solution must comply with all applicable laws Which laws are applicable? This is a “catch all requirement”

The solution must comply with ISO20020 Information Governance This is not one requirement. This is hundreds of requirements, all contained in the ISO 20020 document. Each

one of these should be individually specified and understood

The solution must have the ability to use multiple dictionaries and support multiple languages & character sets This is not one requirement, it is three. Which dictionaries? What languages? etc.

The system must provide tools like calendar and calculatorTo do what? Like???? What else? Scientific calculator? Financial calculator? The one supplied free with

Windows? A calculator on someone’s desk?

The solution must support changes to the challenge/response password This is highly ambiguous – what does this actually mean??? How? Using an online system, phoning a call

centre etc. etc. This could be three lines of code or a whole business process

In addition, none of the above have reference numbers, so there is no traceability, nor is there any rationale as to what business outcome, or business benefit!


Requirements Capture – the right way.

p.6

The following is an example of business scenario that forms the basis of a phase of development:-

This narrative articulates, at a macro level, the desired business outcome and matches it to business processes.

Customer Activity (aka User Story/Use Case) Capability / Process

Stuart Robb will go to the COMPANYX web page and browse for a handset (an Apple iPhone 5c), a car charger and a prepay SIM. He will add these to his cart and pay for them with his Visa card, registering (a username / password) with COMPANYX in the process using the minimum details necessary to complete the purchase.

Browse HandsetCart & PayUser Registration

During the checkout, he elects to collect the phone from the COMPANYX store in Knightsbridge, ideally where it’s confirmed that all the items are in stock. The Knightsbridge store will see the order and put a handset / charger aside for Mr Robb.

Collect InstoreStore Stock Mgt

The following day, Mr Robb goes to COMPANYX Knightsbridge, the sales assistant looks up Mr Robb, sees the handset & charger has been put aside and also notes that Mr Robb has already paid. The assistant puts the SIM in the phone for Mr Robb and hands it over, having added the SIM / MSISDN to Mr Robb’s account and activated the phone. Mr Robb leaves the store delighted with his joined up experience.

Instore Order MgtAccount ActivationCustomer Feedback

A week later, Mr Robb needs to top up. He can use any of the usual top-up channels and on this occasion he decides to use his bank’s ATM to top up £10. He goes online the next day and sees that his balance is running low again, because he’s been calling his mates in Australia.

Multi-channel top-upCustomer Accounts MgtMulti-channel balance

Customer (Business) Outcome: Customer orders prepay phone online, collects in store and is able to use immediately.On November 5th (21 weeks from today), COMPANYX will be launching an MVNO called XYZZY.

1. Core – minimum capability that we have to deliver


Example Requirements Summary

p.7

Ref: Process / Epic

Trigger (when...) Actor (as a...) Narrative (I want to...) Benefit (because...) KPI's (MI report)

Wireframe / Mock-up Explanatory Notes Requirement

Owner Priority

Complexity

(H/M/L)

Estimated

Mandays

Phase / Releas

e

ACQ-1 Acquisition Responding to

a campaign Customer Purchase a new phone from a store

I can choose the phone I want in person and collect & connect immediately

n/a n/a How do I know where the store is? Inferred requirement? Stuart Robb 1 L 5 1.1

ACQ-2 Acquisition Responding to

a campaign Customer Find my local storeI can find the store most local to me increasing likelihood of a visit

# of customers using the branch locator, per month ACQ-2-1 Branch locator functionality Stuart Robb 1 L 5 1.1

ADM-1

Administration

Opening a new branch Administrator Add a branch to the

branch locator tool

Branch locator will have details of every branch for the benefit of customer lookups

n/a ADM-1-1 Imbedded GPS location required for Google Maps Stuart Robb 1 L 8 1.1

REG-1 Registration

A new customer wants to make a purchase

Salesperson Register the new customer on the system

Customer information becomes known to us which we can use for fulfilment

Registration must take no longer than 1 minute REG-1-1

- Salesman must verify the customer is not an existing customer.- See Wireframe REG-1-1 for details of data to be captured and business rules

Stuart Robb 1 L 10 1.1

REG-2 Registration

Wanting to make my first purchase

Customer Register myself on the system

I don't need to call or attend a branch to transact with the company

# of new self-registrations per month REG-2-1

- System must de-dup customer automatically- See Wireframe REG-1-1 for details of data to be captured and business rules. Note, the data capture is identical to REG-1

Stuart Robb 1 L 10 1.1

REG-3 Registration

A new customer is registering their details

SystemAutomatically verify a customer does not already exist

I don't want duplicate customers polluting the system

Exceptions Report n/a See "DCD-TA004: Customer De-duping Technical Specification" Stuart Robb 2 M 100 1.1

That scenario can then be decomposed into specific process steps and from each step a requirement derived. Once the steps are understood, they can be estimated, visualised and prioritised.


Workshop process & intensity

p.8

When understanding a business solution, there are three dimensions that need to be considered:-

What is the business trying to achieve – macro-level business requirements

How will this particular capability work and how will IT systems support it – micro-level detail

Is what you’ve built what I was expecting – stand-ups/prototypes & reviews

The project will need to undertake workshops, using hot-housing techniques that span across all three dimensions.

Business Requirements Hot-house

Review the scopeLook at the holistic solutionUnderstand the major scenariosReview the business processesUnderstand business volumetricsConsider geographical impactsWalk through an outline solutionWhat are the interim / transitional processes

Intensity: Several major workshops at the commencement of the stage

Systems Design Workshops

What data should be capturedHow does it relate to other dataWhat should the validation beWhat business rules should be applied to this data and howWhat happens to this dataHow is it displayed and to whomWho has access to amend itWhat are the appropriate “lists of values”

Intensity: Every two weeks through design & build (aligned to Sprint

cycles)

Solution Review Workshops

Have you designed what I’m expectingDoes it work in the way we wantIs the data captured and processed in the way we envisagedAre the rules working as we want them toDo the right people have access

Intensity: Every two weeks at the end of each development Sprint


Hothousing & iLabs

p.9

Getting the right people together, including suppliers, is one of the key success factors in developing a robust set of requirements

Using a hot-house and innovation labs can quickly get to a common understanding of the solution needs.

Frequently, index cards are used to capture the initial requirements, as these can be easily blu-tac’d and moved around, especially during prioritisation...


The Requirements Capture Process

p.10

In order to mitigate the huge risks that are posed to an IT programme where requirements cannot be articulated in a timely fashion, it is essential to develop a set of requirements protocols that are strictly enforced.

1)The project will arrange workshops to understand the business requirements The project will issue a scope to be addressed and a terms of reference. The project will also issue any relevant background reading material to assist in the understanding of the workshop. There may be many of these workshops through the lifecycle of the programme – several hours a week is not untypical.

2)Business prepare for the workshop Business define ownership of the requirements and final decision-maker who will be attending the workshop. Business prepare for the workshop by ensuring all likely data items, validation rules, business rules, product rules, customer rules,

users/permissions have been thought-through and can be articulated at the workshop. This may involve the business having internal pre-workshop activities, as required (for example, to think through processes, organisation structure etc).

3)Workshop is held. Business walk through the scenarios, bringing clarity to the business need where necessary. Each scenario is decomposed to the

extent that it becomes unambiguously clear what is required to be developed and how it should perform. Business prioritise these scenarios, such that the most important business requirements have the highest priority.

4)Unclear requirements are clarified If, during the workshop, there are any requirements that are unclear or ownership is not agreed, the business (independent of the

project) shall convene the right stakeholders to identify the owner and fully clarify the requirement.

5)Outstanding unclear requirements more than 5 days old If a requirement is outstanding unclarified for more than 5 days from the date of the workshop, the project will use its best judgement

to articulate the requirement, or document how the existing system satisfies the business need (where applicable). A list of these will be consolidated and sent to the Project Steering Group, with the appropriate Steering Group owner assigned to

resolve. The deadline for resolving the ambiguity will be a further 5 days.

6)Unclear requirements more than 10 days old Any requirements that still remain unclarified beyond 10 days from the workshop, the project will ask the appropriate project board

member for an adjudication/decision. Programme will present a change request to the project board where slippage has been caused because the requirement is not

articulated within the necessary timescale.


User Acceptance Testing

p.11

The final consideration is the user acceptance of the solution:-

UAT is the FINAL validation that the solution correctly performs all the tasks the business expect of it

There are “acceptance criteria” that are defined prior to the commencement of the UAT process.

These acceptance criteria are measurable and relate directly to business requirements

If the acceptance criteria are not met, the business then need to decide whether the solution can be put live or not.

The business, therefore, need to prepare for an extensive UAT phase and must have the following dimensions.

1)UAT is performed by real business users (not IT analysts working as a proxy for the business)

2)The UAT is comprehensive in its scope, sufficient to ensure all parts of the solution have been reviewed and validated by the business

3)There is a test performed against each specific, individual requirement (with traceability through requirement reference number)

4)The business need to provide sufficient business resources to undertake the UAT

5)The acceptance of the solution, and its approval to go live is the accountability of the business owner for the solution (not IT).

MaddisonWard_Business_Requirements_Capture

Documents

Transcript of MaddisonWard_Business_Requirements_Capture