What and How of Requirement Gathering - Part 1

This time rather than writing on some technology or solution, I thought to write on one of the important phases of SDLC which is nothing but requirement gathering. To be more specific, this article will be more about collecting information about business requirement. What are the various sources to get and understand most of the portions of any business requirement.

It’ very important to understand that, information can be gathered from many standpoints. It can be from Business front, Application front, Operations front, Technology front, and may be many more. So, while gathering information, one should have a clear vision on what kind of information they are looking for. Let’s have a look at few of the well-known categories:

• Business – Goal of business, Service offerings, Products, Financial Structure, etc.
• Application – Productivity tools, interaction with business application system, Code Modules, etc.
• Operations – Identify the information’s origin, information’s consumption, information’s ownership, Data warehousing, Data models, Data Management policies, etc.
• Technology-Technical Services, i.e. Development Environment, Topologies, Network Services, Security, DBMS, Technical Specifications, Hardware, Software etc.

The next biggest question would be how to gather all this information?

If you will search on the internet about how to gather information, you will get lot many ways. But most of these tactics, more or less fall into 1 of the below categories:

Shadowing: In this technique one will observe a user performing the tasks in an actual world environment and ask the user any questions related to the task. It is basically like following the user as he or she performs daily tasks. In other words, more the questions, more the information.

Note: This technique is effective only for frequently performed activities or tasks because if the task is performed occasionally, then it would be difficult to shadow someone.

Some common questions which can be asked during shadowing can be:-

• What decisions do users make when starting or completing a task?
• What modifications must be made over time to make it easier to complete the task?
• Which related tasks may affect the design of the solution?
• Are there any performance criteria?
• How many people does a user interact during a given task?
• Are there any variations in the steps to complete the task?
• How often does system or management interfere with their job?
• What do users like/dislike about the system?
• Characteristics and preferences of user.
• Concepts and terminology used by users?
• What trainings do users need?
• How can training and support costs can be reduced?
• Have users been through the training or they are self-taught?
• What information about the user is not documented?

In essence, one has to observe and question both the management and the users. If there are any external stakeholders involved with the task then they should also be part of this observation.

Hope you got an overview of shadowing. There are a few more techniques, which can be considered in order to get the required information for starting any project. But being a completely theoretical write-up, I would like to end this blog here itself and will write about more techniques in my next blog.

Till then keep reading.