For successful project delivery, you need to capture detailed business requirements. Here’s a How-To guide for doing that.
Remember to start with high-level requirements. You’ll find information on that process in the post on “How to capture business requirements“. Capturing these requirements get you thinking about your business process and how it works or doesn’t work.
How to capture detailed business requirements
The next level of business requirements spell out the desired project outcomes. They allow project teams to understand what they need to achieve in order to successfully deliver for the business.
Here’s how to capture those:
1. Diving deeper
The next part of the process is to delve deeper into what each of the requirements that you’ve already captured actually means. To do this I’m going to use some examples
The requirement is to Capture customer information
This is a very broad requirement, so the best thing to do is to ask what this means in terms of your business process – ‘What is it that you actually need to do?
–> Capture the customers’ name – Is this full name as in surname and first name? Does a middle initial need to be captured?
–> Capture the customers’ address – What format is this going to be in? Street address, suburb, state, postcode. Do you need to capture country information?
Again as in the initial gathering process, the idea is to get things down then refine them. The information here might be your first cut. Often the business does not know what it wants until you ask these specific questions.
The requirement is to Capture the customers’ contact details – Is that phone number(s) and/or email address or both
–> Document other customer information required – Is member information required? If the customer is a member of your business, is this in the form of a member number?
–> Do you need details of other family members? – What other customer information do you need to do your job or complete this part of your business process?
The requirement is to Capture work request data/information
–> Capture customer number – what form is this in?
–> Capture the system that requires work undertaken on it – [this may not be relevant is the process you are working on only deals with the capture of work request for one system only] Is version information important here? Do you need to know what patches have been applied? Is system configuration information needed?
–> Capture information on the issue/work request requirement – Is this going to be written information in the form of a story? Do you need lists of choices for people to use? What form/format is this information best captured in?
Once you’ve done this second level of requirements capture, again you will start to see things that you hadn’t thought about earlier. For instance, in the first example, you may need to capture two addresses, a physical address and a postal address (one may be a billing address). When you capture the phone number will there likely be more than one? And do you need to capture the country code, as well as area/local code? Detail the data capture format.
This level of detail is required if a system is going to be built, or configured, to meet your needs. It is really worth thinking about and documenting this level of detail. It means that the end product will meet the businesses needs exactly how they wanted.
Ranking your requirements
Once you’ve captured this second level of requirements gathering and you have a list of requirements it is important to rank them. The list is likely to be quite extensive and quite long. Now rank each of the items that you have listed into ‘must haves’ or mandatory items, and the ‘nice to have’. The ‘nice to have’ aren’t going to mean that your system isn’t going to do what you want it to do, they are the things that might make it more attractive, for example. These are also the items that will add cost to your quote to undertake the system build/configuration. It is very worthwhile listing these though because in the build phase you might be surprised how some of these can be added without additional cost or time. Especially if the system is being built from scratch.
Most of the items you will have captured here are ‘functional requirements’, in that, they perform a function and deliver something. People usually forget the very important part of requirements gathering and that is the ‘non-functional requirements’ those things that are really important but sometimes less tangible. For instance, the time that it takes for a database query to be returned and displayed on your GUI or webpage. What is an acceptable time for you to wait for this response? If the system was built and it took five minutes to return the page I’m sure that you are going to say that it’s not delivering for you. You would really want less than five seconds. Ensure that this important information is captured as a requirement.
What sort of reporting do you need to capture from the system, or should I say, about your process? This is another key area that most people forget, and it is much easier to think about and define up front as part of your requirements than three months after the system has gone live. Why? Because after go live when you start to think about reporting, you may suddenly find that your system hasn’t been configured (a) to capture the data that you need, or (b) deliver it to you in a meaningful way.
As I explained in Part 1 – the more time you take to do your requirements gathering up front, the more likelihood of success and delivery of a system that is really going to meet your business needs.
Document these more detailed requirements in the same way as before, and again, have them reviewed by the key business stakeholders. It’s well worth the effort.