1. Business Requirements Capture ...made easy Version 1.4 July 2010

2. The Requirements ChallengeArticulating 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 in one part of the solution in a timely fashion, this will cause a shortfall in the development velocity of a team (of typically eight people a pizza team). Each team of eight people has a cost (not including the programme overheads of Project Management, Integration Testing etc). If a requirement cannot be articulated that impacts the development of the solution programme wide, that results in dead time and dead money. If a requirement is changed as a result of future 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 amount 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 or unforthcoming. It is therefore absolutely essential that the requirements are forthcoming 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 fully articulated. p.2 Copyright Maddison Ward 20062 3. What is a business requirement? 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: 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 students 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 wont 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 doesnt support the US networkAll 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 extend of the rules have to have been articulated to build the requisite level of flexibility into the solution. p.3 Copyright Maddison Ward 20063 4. How are business requirements derived? 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 developers 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 didnt quite do exactly what the business wanted. Thirdly, the temptation was for the business to stray from trying to define the business need and wander into trying to design the solution, resulting in a sub-optimal outcome. 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 and personas/actors to walk through 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. This also makes it much clearer exactly what the business wants the solution to do. 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 Unifiedp.4 Process and Agile. Copyright Maddison Ward 20064 5. Requirements pitfalls? 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 calculator To do what? Like???? What else? Scientific calculator? Financial calculator? The one supplied free with Windows? 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 benefit they support or why!p.5 Copyright Maddison Ward 20065 6. Requirements Capture the right way. The following is an example of business scenario that forms the basis of a phase of development:This overarching narrative, commonly known as a concept paper drives out the detailed requirements for the release Customer Outcome (aka EPIC): 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 Customer Activity (aka USER STORY)Capability / ProcessStuart 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 Handset Cart & Pay User RegistrationDuring the checkout, he elects to collect the phone from the COMPANYX store in Knightsbridge, ideally where its 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 Instore Store Stock MgtThe 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 Robbs account and activated the phone. Mr Robb leaves the store delighted with his joined up experience.Instore Order Mgt Account Activation Customer FeedbackA 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 banks ATM to top up 10. He goes online the next day and sees that his balance is running low again, because hes been calling his mates in Australia.Multi-channel top-up Customer Accounts Mgt Multi-channel balancep.6 Copyright Maddison Ward 20066 7. Example Requirements SummaryProcess / Trigger Ref: (when...) EpicActor (as a...) Narrative (I want to...) Benefit (because...) I can choose the phone I want in person and collect & connect immediately I can find the store most local to me increasing likelihood of a visit Branch locator will have details of every branch for the benefit of customer lookupsACQResponding to Acquisition Customer 1 a campaignPurchase a new phone from a storeACQResponding to Acquisition Customer 2 a campaignFind my local storeADM- Administrati Opening a 1 on new branchAdministratorAdd a branch to the branch locator toolSalespersonCustomer information Register the new becomes known to us customer on the system which we can use for fulfilmentA new customer REGRegistration wants to 1 make a purchaseKPI's (MI report)n/an/aComple Estimat Phase / Requirement xity ed Priority Releas Owner (H/M/L Manda e ) ysHow do I know where the store is? Inferred requirement?Stuart Robb1L51.1# of customers using the branch locator, per monthACQ-2-1Branch locator functionalityStuart Robb1L51.1n/aADM-1-1Imbedded GPS location required for Google MapsStuart Robb1L81.1REG-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 rulesStuart Robb1L101.1REG-2-1- System must de-dup customer automatically - See Wireframe REG-1-1 for Stuart Robb details of data to be captured and business rules. Note, the data capture is identical to REG-11L101.1See "DCD-TA004: Customer Deduping Technical Specification"2M1001.1Registration must take no longer than 1 minuteWanting to REGRegistration make my first Customer 2 purchaseRegister myself on the systemI don't need to call or # of new self-registrations attend a branch to transact per month with the companyA new REGcustomer is Registration 3 registering their detailsAutomatically verify a customer does not already existI don't want duplicate customers polluting the systemSystemWireframe / Explanatory Notes Mock-upExceptions Reportn/aStuart Robbp.7 Copyright Maddison Ward 20067 8. Workshop process & intensity 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 youve built what I was expecting? The project will need to undertake workshops, using hot-housing techniques that span across all three dimensions.Business Requirements Hot-house Review the scope Look at the holistic solution Understand the major scenarios Review the business processes Understand business volumetrics Consider geographical impacts Walk through an outline solution What are the interim / transitional processes Intensity: Several major workshops at the commencement of the workpackage Copyright Maddison Ward 2006Systems Design Workshops What data should be captured How does it relate to other data What should the validation be What business rules should be applied to this data and how What happens to this data How is it displayed and to whom Who has access to amend it What are the appropriate lists of values Intensity: Every two weeks through design & build (aligned to Sprint cycles)Solution Review Workshops Have you designed what Im expecting Does it work in the way we want Is the data captured and processed in the way we envisaged Are the rules working as we want them to Do the right people have access Intensity: Every two weeks at the end of each development Sprint p.8 8 9. Hothousing & iLabs 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 lab 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-tacd and moved around, especially during prioritisation...p.9 Copyright Maddison Ward 20069 10. The Requirements Capture Process 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.1)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).1)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.1)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.1)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.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 p.10 member for an adjudication/decision. Vantage will present a change request to the project board where slippage has been caused because the requirement is not Copyright Maddison Ward articulated within the necessary timescale. 2006 10 11. User Acceptance Testing 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 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). p.11 Copyright Maddison Ward 200611 12. Business Requirements CaptureCopyright Maddison Ward 2006