Gathering requirements is an important part of any software professional's job. It's the main function of a business analyst. Even if you're not a business analyst, you still gather requirements as part of your job. For example, learning about new systems, creating documentation, or even writing code to interface with other systems. Let's have a look at a few requirements gathering tools that we can use.
A good way of gathering requirements and documenting them is to create diagrams for them. Some people (myself included) are visual learners, which means they learn things easier by looking at diagrams, as opposed to reading text or instructions.
A diagram can be useful in many cases:
- Process diagram to explain how a business process works
- Diagram to explain systems and their interfaces
- Diagrams to explain code flows between modules
- Diagrams to explain organisational structures and how teams work
Good Old-Fashioned Phone Call
In a world with all kinds of communication technology, we have learnt to talk using email, SMS, and instant messaging. Sometimes these methods can help, and other times they don't.
A good requirements gathering tool is the regular phone call. Sure, you might use it all the time, or not at all. But it does have its advantages.
You get to speak to the person that you want, and you get to do it right away. You don't need to wait for them to read the email, reply to the SMS, or write back to your instant message. Choosing the right communication method is important, and is something I've written a post on recently.
A phone call, whether it's to a desk phone or a mobile, is a great and efficient way of getting your questions answered by someone.
One of the things I was taught early in my IT career was that email is a valuable record of information. When we need to discuss things with someone, it's easy to forget the details at a later date, or to be a bit confused about some points. This is why I was told to use email as a follow-up or a confirmation.
After you discuss something with someone in person or over the phone, it's a good idea to send them an email to confirm your discussion. It can be as simple as, "Hi John, As discussed, we will build the interface to ABC system using the existing ASP tools and aim for the initial testing date of March 20th. Is this correct?". This will put the discussion down in writing, and make it clear. The recipient can read and respond, by either agreeing if that's what the outcome was, or correcting you if something was wrong.
It also serves as a record in case you forget or need to come back to it later.