Requirements Planning

What's a good requirements plan?

It's certainly not measured by how thorough it is, in fact too much verbiage could be a sign of a bad one.

It's not the one that results in the most detailed and comprehensive set of requirements.

It is most definitely not the one that gets the project through to the nest stage in the fastest possible time.

So what is a good one? In my opinion a good requirements plan give you

The requirements necessary to define an appropriate solution, documented in a form that can be easily consumed by stakeholders, elicited and defined in a way that is sympathetic to the nature of the organisation and project, that can be executed in a timely and cost effective manner.

Parsing that out there are four essential elements to a plan:

• Requirements: What requirement types will you elicit/define and at what level?


• Artefacts: What form will you document these requirements in?


• Techniques: How are you going to interact with stakeholders to elicit requirements and to validate and designs?


• Execution: When and who is going to perform this work?

For every one of these except Execution you can pick up BABOK 2.0 and get a list of possible answers

I think it's always worth setting some time aside at the start of the project to come up with a requirements plan separate of the project plan. It doesn't have to be formal document, it doesn't even have to be written down, it doesn't have to (and probably shouldn't) remain static over the project, but it should force you to sit down and understand why this project is different from all the others.

Because if you're not consciously planning, you'll just end up doing the same thinking, and having the same conversations throughout the project and it will take up even more of your time, and you'll do it worse than if you'd thought about it up front.

P.S. I know I've ignored change management, and traceability - but this is a blog not a textbook.

Types & Levels

I've struggled to reconcile two of my favorite frameworks for talking about requirements for a while now, and I think I've finally got the idea settled in my mind. Basically I'm using BABOK 2.0 defs for , My classifications are

• BABOK 2.0 requirement classifications
  • Business
  • Stakeholder
  • Solution Functional, which are further broken into:
    • Behavioural
    • Process
    • Information
    • Interaction
  • Solution Non-Functional, and
  • Transition.
• Bruce Silver's Three Levels of Process
  • Prescriptive
  • Descriptive
  • Executive

For ages I was just using the Silver levels as a sort of Zachmann levelling for processes (proper ones, not the hand-waving level-0 processes), then I started using them to describe the other Behavioural, Information, and Interaction requirements as well, now I'm realising that I should be applying them to all the requirement types in one big matrix, and once I do that I can start putting actual the names of actual artefacts in the intersections between them.

Now it gets interesting, what's a Prescriptive vs. Descriptive Business Requirement? How are behavioural and process artefacts different on the descriptive level? etc. This is getting into definitional debate land that I don't really care about but it's a nice way to get a list of things on one page.

So what use is that? Well, it's the menu items you order off at the beginning of the project for what you intend to produce. It's a major input to requirements plant. It allows you to define what you want to collect (e.g. Stakeholder Requirements), what level you want to collect it at (e.g. Prescriptive), and the intersection between these defines an appropriate the artefact (e.g. Use Cases).

If you decided that full use cases are too much work, or unsuitable you can pop up to the Descriptive level and see that for Behavioral requirements, maybe some User Stories are the go. I doubt I'll ever use this in practice, it's way too complicated and involved, and only BAs who think about method more than they should will like it, but at least I have a coherent internal view I can use myself.

Now if only I could get the same clarity around business rules..

COTS Workflow you already have, you just don't know it

Most organisations already have an purchased, implemented, and widely used world-class workflow and case management solution with great reporting and metrics - they just don't know it.

It's your humble IT help-desk and issue tracking software.

The core of this software's functionality is to define the process by which events are dealt with, manage and manage and track the work that needs to be done to respond to these events, and report on the results.

Just think how useful this would be for:

• Customer queries
  
• Purchasing (Your own lo-fi purchase-to-pay process.)
  
• Leave Requests
  
• Expense Requests
  
• Training Requests
  
• Case Management
  
• Sales Cycles
  

Basically any long-running, manually intensive process is a candidate to be tracked and reported in such a system.

Obviously there's significant down sides to using a ticket-tracking system instead of a "real" BPM suite, integration with external apps is horrible for instance, management and dashboard reporting cab be pretty sparse, resource assignment is generally primitive, and the process modelling side will be nowhere near as pretty or support the full expressiveness of BPMN 1.1.

But all this matter less than you think. You have a system here and now that can quickly and cheaply (so cheaply) solve many of your internal process issues - but IT has just kept it for themselves.

So go start playing around with whatever you have - (or install Trac/buy Jira if you don't have anything) and start working. All you need is a process map, and a state diagram showing transition, and who is responsible at each stage, and you can have a system implemented and ready to start training in less than a week. Less than a day if you've done it before.

If you're willing to get fancy you can also use the fact that the notes and description section for tickets in tools like Jira has most of the power of it's Wiki available so integrating in information from external sources is easy.

So what are you waiting for - what process in your organisation would be better served by a ticket-tracking system and what are you going to do about it?

References:
http://en.wikipedia.org/wiki/Issue_tracking_system
http://www.atlassian.com/software/jira/