Blog

As a business analyst, requirements management is at the top of my list of interests and is something that is rarely talked about or discussed, but essential to any sucessful software development process. Without requirements, there are no defined statements as to which the project outcome should conform to. Each requirement should be documented, actionable, measureable, testable, and should define a business need or opportunity. This is important to a successful and timely delivery of systems, but when applied correctly, it can be used in all facets of decision making.

The foundation of the requirements gathering paradigm is the simple understanding that to solve a problem, you must first understand the problem. In particular, the steps to understanding the problem are elicit, analyze, and document. So what exactly do these three steps mean? Let's delve a little further into the world of requirements anlaysis..

Prior to eliciting requirements, you must first identify the key stakeholders, access the environment that the system shall reside on, and define any domain constraints. Solid requirement statments cannot rely soley on the end user/customer telling you exactly what the system should do because you will never be able to gather all of the requirements necessary to build your system. Instead, the elicitation process should involve interviewing, use cases, and prototyping. When interviewing, solict participation from as many stakeholders as possible holding multiple JAD (joint application design) sessions. JAD sessions are workshops in which the analyst meets with key stakeholders and project managers in order to review the business process requirements for the system, so that you are able to understand the different perspectives. During any interview session however, you must keep in mind that you should be able to rationalize the importance of each statement you elicit. Developing use cases can oftentimes help with the elicitation process in that it helps customers identify key requirements and provides a better understanding of what they want the system to do.

The requirements analysis step comes next, which can be defined by two words; consistency and completeness. Oftentimes during the gathering process, requirements can be ambiguous, incomplete, or contradictory. During the analysis phase, these problematic requirements will be fixed prior to presenting them to the customer and can require additional JAD sessions and discussions. A good requirement statement should be one that is clearly stated, expressing facts, and cannot be open for interpretation. Keep in mind that requirements should also remain within scope and the limitations of implementation.

Lastly comes the documentation stage. This is the stage where the requirements you have gathered are written as shall statements. These statements should be written so that they are easy to understand by both developers and the end user, and should also be traceable. Requirement statements can be documented in a requirements management plan, or even something as simple as a spreadsheet. For more advanced features such as tracing to test cases and design, you can use Telelogic DOORs, JIRA, or Requisite Pro.

Understanding the requirements management process is essential for any successful software development process. Requirements ensure that the end product meets stakeholder needs and expectations and also ensures that the project stays within scope. The requirements process does not end upon reveal of requirements, but rather, should be exercised throughout the course of the project lifecycle.

Want to learn more? Theres a multitude of books out there, but here are some of my favorites: The Software Requirements Memory Jogger by Ellen Gottesdiener, and Telling Stories: A Short Path to Writing Better Software Requirements by Ben Rinzler.