home

Requirements or tasks?

I'm am the Lead BA in my organization, and am struggling with a particular issue regarding requirements documentation.  I work for an insurance company and typically the projects in the portfolio have some IT componenets, usually changing parts of the Legacy systems to accomodate new benefits, but our BA's also work with the business units to understand the things that need to be done to complete the project that are not IT related.

The BA's document the IT requirements and the non-IT requirements in our Project Requirements Document (PRD).  The BA's typically document these non-IT requirements as "Business Requirements".  I disagree with the categorization of these, as I think of Business Requirements as much higher level, but there really isn't any other place in our document for these.  Some examples of these requirements are:

Develop procedures and provide training for Customer Service staff

Create correspondence for Providers

Update Provider directory

Our PRD has sections for Business Requirements, Business Rules, Functional Requirements, and many different types of Non-Functional Requirements (Performance, Usability, Security, etc).  We also have PM's on our projects, and they (somethimes) take these requirements and expand on them in the project timeline with who is responsible and when they will be done. 

Anyone else document these types of things?  What is the true classification for these requirements?  My Manager has insisted that we need to capture these things, because they are things needed by the stakeholders to achieve an objective.  This satisfies the definition of a requirement in the BABOK.

 Thanks - MPS

Requirements or tasks?

MPS

I agree that current methods do not lend themselves to these types of projects. The current methods are designed for software development from scratch and not for system changes, COTS selection, insurance product launches, or other types of projects I regularly encounter. It sounds like you are working on an insurance product launch and I will recommend documentation for that type of project in a moment.

First, let me comment that tasks are solutions to a business need. Generally the first thing you can elicit on a product launch is a mix of activities/tasks/solutions and business needs. From there you can work backward to business needs and their associated business requirements.

Every document you produce should meet a current need of the project. In its early stages the project must move forward with a draft project plan, so the initial mix of solutions and business needs is very useful. It should serve as the basis for the PM’s first WBS and also help you structure your next steps.

Then ideally you would have the time, resources, and support to ask “why” on every one of these until you uncover the business needs and related information. In my experience, there is only time, resources, and support to address the items of highest risk but hopefully your situation is different. If your case is like mine, then I unfortunately recommend keeping the remaining tasks in the Business Requirements document, as much as it may chafe to do so. Remember that they imply requirements that have just not been uncovered yet.

Now, for the documentation: The first draft of the Business Requirements is a “mushy” set of high level tasks and business needs, each of which is at a high enough level that it could represent a small project of its own.  The second draft of the Business Requirements includes Business Needs, Business Requirements, Current State, Decisions, and Assumptions. These are preferably traceable to each other and to their sources.  This document is somewhat less “mushy” but may end up containing some items that remain as tasks. It may include models of the current state and you might also produce documentation of proposed solutions.

Let’s take the provider directory as an example. Why is there a provider directory? Do customers need it to use the product? Do they expect it? Is there a regulatory requirement? Many of these topics can be covered within two sessions: one with business leaders and one with SMEs.  These conversations should uncover a first draft of one or more business needs, one or more business requirements, and one or more ways that need is currently met.

For this example:

  • The business need may be: “Customers must be able to see providers covered by their plan in order to have the best experience of the product. In order to find providers covered by their plan, customers must be able to determine which providers are geographically nearby to a particular location and are also in their plan’s network.”
  • The business requirement may be: “Customers shall be provided one or more method to determine providers that are local and in their plan’s network.”
  • The current state may be: “A provider directory is updated once per month. The directory is made available in searchable form on the customer portal website and is also produced in print form twice annually and mailed to all policyholders for that plan.”
  • The conversation with business leaders may also produce a business decision to stick with the current method (but keep in mind that such decisions may change as further information or opportunities are uncovered) and some assumptions.

To meet the current need of the project, some requirements or needs may still have to be written at a level that is more vague than you would like.  For example all you may know at this point is that: “Insurance regulations in some states (specific states and regulation references yet to be identified) state that a current provider directory must be made available at least once per year.”

I’ve written enough on this subject. Please feel free to ask questions and/or to contact me directly using my account profile if you are interested in more.

    Sponsored Announcements & Special Offers

© 2007-2010 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group