Project Management Insight

In last weeks article “How to capture your business requirements – Part 1″ I described the process for the initial capture of your business requirements.  This was your first cut of high level requirements, to get you thinking about your business process and how it works, or doesn’t work.  I discussed the need to not think about solutions, but rather about what you needed a solution to do for you.  This is very important, and the same space that you need to have your thinking in, in order to move into the next stage of requirements gathering.

The next part of the process is 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.

Example 1 -  Requirement – Capture customer information

This is a very broad requirement, so the best thing to do is to thing of what this means in terms of your business  process – ‘What is is that you actually need to do?’

• Capture the customers name – is this full name as if surname and first name?
• Capture the customers address – what format is this going to be in?  street address, suburb, state,  Do you need to capture country information?   [Again as in the initially gathering process the idea is to get things down then refine them.  The information here might be your first cut]
• Capture the customers contact details – is that phone number(s) and/or email address or both
• What other customer information is required?   is member information required, if the customer is a member of your business, for instance, and 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?

Example 2 – Requirement – 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, for instance?  do you need to know what system configuration has occurred?
• 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 – might you need to capture 2 addresses, an actual physical address and a postal address (so that you can bill the client for example).  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 as well as the phone number (this is more the format of the data required to be captured).

This level of detail is what is required if a system is going to be built or configured to meet your needs.  It is really worth thinking and documenting this level of detail, as it means that the end product that you are delivered will meet all of your needs.

Let’s say you’ve worked through this second level of requirements gathering and you have a list of things which you need in order to complete your business process.  That list is quite extensive and quite long.  Now it is time to rank each of the items that you have listed into ‘must haves’ or mandatory items, and the ‘nice to haves’.  The ‘nice to haves aren’t going to mean that your system isn’t going to do what you want it to do, but they are the things that might add expense 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.

Most of the items you will have capture 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’d really want less than five seconds, so ensure that this important information is capture 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 it, define it, up front as part of your requirements that do that three months after the system is go 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, nor (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.

Karen