Requirements gathering, possibly the most crucial step in software development, is often times the first “real” step a company takes in developing an application. That’s not to say that Scope Definition and problem analysis don’t happen. Its just that Requirements Gathering is often time considered the “kickoff” point from the perspective of most business users.  The goal of requirements gathering is to create a definitive description of exactly what the solution must do in order to resolve the business problem and be considered a success.   It is during this phase that we work most closely with the system users to derive these requirements. 

One reality about Requirements gathering that many don’t realize is that it is more likely that your business users and system owners don’t know their own business processes than it is that they do.   As surprising as that sounds it really isn’t bazaar,  many users are far too busy to analyze what they do plus get a strong understanding of how they fit into the organization as a hole.  And while system owners may have a strong high level understanding of what their business does, the minutia of the process that achieves that is often abstracted from them.

If this sounds like an uphill battle, that’s because it is. But if you assemble the right team,  excute the right tasks (often times over and over and over again), and diligently develop and manage the right artifacts;  then you can come out of requirements gathering with a solid foundation. Often times this leads to the requirements gathering team to have a better understanding of what the business does, then even the business users or the system owners do. 

The Team:

Project Manager:  The project manager acts mostly as a facilitator during requirements gathering, they will be working to get the right people together in the right room so that requirements can be acquired thru interviews, observation or other techniques.

 Business Analyst:  It is the responsibility of the Business Analyst to capture the requirements. They will work with the users to understand what they do, what they need, and how to put the system together to get them where they need to go.  Business Analysis is part art and part science and requires exceptional people skills as you help lift the fog surrounding what the system needs to do.

System Users:  System Users are the Business Analysts primary contact. The Business Analysts will meet with System Users as many times as it takes to get a solid and complete understanding of what is needed.

System Owners:  Often times there will be gaps in understanding between the various System Users; the System Owners are the best place to start to either fill these gaps or find out who will be filling these gaps. They are also an excellent “sanity” check. Its surprising how often one can hear “they do/want what?”  from a System Owner when a BA is explaining the process they have obtained thru their interaction with the  System Users.

The Tasks:

The tasks involved are really a cycle of specific tasks. Thinking of it like a mini process helps, below are the tasks involved in requirement gathering.

• <!--[if !supportLists]-->Requirements Identification – Learning of a requirement and defining it in as much detail as possible.
• <!--[if !supportLists]--><!--[endif]-->Prioritizing – Define how important the requirement as it relates to other requirements in the system
• <!--[if !supportLists]-->Project Impact – New requirement means a new project plan. Fit in the new requirement and evaluate its impact on the entire project.

<!--[if !supportLists]-->·         <!--[endif]-->Update documentation – Once we have a full understanding of the new requirement we have to serialize it into documentation. To do that we must update our requirements documents and models. These documents are how projects are defined and the center of communication. It is crucial that these documents stay as up to date as possible.

The Artifacts:

The artifacts are those documents that are the center of communication between the different members of the project team. The key is to make these documents as throe as possible, while making sure that all members of the team understand them.  There are many different types of artifacts that can be used, and it is best to view different types of artifacts like tools rather than items that must exists. After all the goal of these artifacts is for communication, if an artifact isn’t successful with your team, don’t waste cycles using it.

Example Artifacts:

• <!--[if !supportLists]-->Requirements document – A hallmark of this state. Often times these documents are hundreds of pages long and provide very detailed descriptions of each function of a solution. Sometimes this document is called the Functional Requirements document.
• <!--[if !supportLists]--><!--[endif]-->Business Process model – A series of workflows and state or status diagrams and descriptions that act as a high level overview of how the different requirements interact
• <!--[if !supportLists]-->Business Data Model – This document describes the data that the solution must capture and work with. It is often times that this document acts like a dictionary. Its description of different objects helps users understand what the other documents and models are describing.
• <!--[if !supportLists]-->Screen shots or UI Model – These documents work to help describe how screens will function. Often times they include descriptions of every field that will be viewed or edited on a screen along with mapping information to specific points in other documents like Requirements or models.
• <!--[if !supportLists]--> <!--[endif]-->Stories – Stories are used in Agile development and are like mini versions of all the above documents. The specifies of a story are much more laxed leaning more on the idea of the bear minimum to make a requirement understandable rather than a ridged and in-depth description.
• <!--[if !supportLists]--><!--[endif]-->Acceptance Testing document – Sometimes it is easier to describe a piece of functionality by describing the test that validates it. In these cases, writing a few tests cases early is worthwhile. After all, any project worth its weight in salt will have one of these anyways.
• <!--[if !supportLists]-->Use Case Models – These are often very high level graphical representations of requirements, defining all of the actors of the process and what the process will do.

References:

Whitten, Jeffery L., & Bentley, Lonnie D. (2008). Introduction to System Analysis and Design. New York: McGraw-Hill Irwin.