Requirements - the Key to a Successful Project

Requirements are what a project is all about. A project exists to fulfill a set of requirements be they related to a SW delivery or a new business process. Requirements drive the project scope and unless well-defined and understood, can lead to huge increase in project scope. It is no surprise therefore that a majority of project failures whether, these be the inability to meet timelines or costs can be traced back to poor or ambiguous requirements. A set of well documented and tightly written requirements is the first and most important step to the success of a project. Let us explore a few key aspects of the requirements process and what is involved in ensuring each supports the overall quality of the process.

Stakeholders include users, subject matter experts, quality assurance (QA) analysts, developers etc. and of course the business analyst (BA) whose role is to bring together inputs from this diverse group of stakeholders into a coherent requirements document. An important first step is identifying all possible stakeholders that could contribute to the requirements or the project’s outcome. Users not only mean direct users of a product but also those that may not use the product directly but are impacted by it. A report may not only impact the actual requestor (user) of the report but also others, for example, if the report is the outcome of a batch process, then there could be timing and processing issues to ensure the report is accurate and timely and does not have a negative impact on other dependant processes. Naturally this means ‘users’ other than the report requestor. A user needs to be clear about what he or she expects from the project and at a level of detail that is unambiguous and understood by the downstream project delivery teams. A BA must be able to extract this information using an iterative process, starting with high-level requirements and peeling each layer of the requirements until nothing remains hidden or vague. It shouldn’t surprise anyone that a single line requirement may well result in multiple pages of details. One of the most power tools in a BA’s repertoire is the ability to ‘paraphrase’ i.e. rewording or restating a user’s requirements to see if it changes the understanding of the requirement. This helps define critical details that would otherwise be missed out as well as simplifying and breaking down an otherwise complex requirement.

Just as the requirements gathering process is iterative, the documentation too is built up progressively and having a standard template helps. A basic structure that is logical and flexible is essential. A basic structure would allow for the numbering of requirements and sub-numbering of each detail that supports the main requirement. Also important is the ability to tag each requirement as Mandatory, Optional or Nice-to-have. This is an important feature since users often are not concerned about the cost of the project whereas in the real world almost all projects are cost constrained. Having the requirements tagged allows decisions to be made on what is essential and what can be left out. It also facilitates ‘traceability’ i.e. the ability to link QA testing to an underlying requirement. Finally it is important to version control the requirements document as it is developed from start to the final signoff.

An often overlooked area is the documenting of NF requirements. These are requirements that are often not given enough importance by users or other stakeholders. These could be things such as the more important ones. Some NF requirements can have a significant impact on the cost of a project and can come back to bite if not addressed as part of the requirements process.

The review process of the requirements is an important pre-approval process. It helps all stakeholders, especially those that have been involved in the requirements gathering only intermittently, the opportunity to see the complete set of requirements. Developers may have questions that may bring up until now hidden issues or suggestions that simplify the product or make it more versatile. QA analysts may also have questions that bring out ambiguities and help clean up the requirements. Addressing ambiguities at this early stage can save a ton of effort and money that would have to be expended if these were discovered during testing after the product had been built. Reviews can be formal or informal, the latter being suitable for small projects. A large project usually requires a formal review. Whether formal or informal, the first step is sending out the draft requirements document to the stakeholders. The BA should indicate to the recipients what is expected from them (comments, feedback) and a deadline by when the response is expected. Obviously once responses are received, the BA would incorporate them in an updated version of the document and re-circulate this version to the stakeholders for acceptance. Major changes or issues brought up in the feedback would require discussions with those impacted before the document is amended. In case of a formal review, the draft requirements document is sent to the stakeholders who are asked to review it and invited to a review meeting on a subsequent date. The BA leads the meeting, going over each requirement and obtaining stakeholders’ acceptance. Changes as a result of the review are logged and then sent out to all attendees to make sure they are accurate. Subsequently these changes are incorporated in an updated version of the requirements document and circulated to the stakeholders for acceptance. Many organizations have a well documented review process for projects of a certain size or risk/complexity. This may include a peer BA conducting the review meeting and analyzing the changes as part of process improvement. The final step that completes the Requirements Process is getting the requirements signed off. This is done at the executive level and usually involves the project sponsor, the user’s executive head (if different from the sponsor), the tech head or an executive of the development team and sometimes the QA executive. To obtain a quick and painless signoff it is therefore should have a new version number and after the signoffs are received the document becomes the baseline for the project delivery. Any requirement changes after the signoff must follow a change management process.

Mok, Karen. "Lesson Plan." Cite the Site. Contra Costa County Office of Education, May 2002. Web. 01 June 2010. . "Plagiarism: What It Is and How to Recognize and Avoid It." Writing Tutorial Services. Indiana University, 27 Apr. 2004. Web. 01 June 2010. . "Plagiarize." Merriam-Webster Online. Merriam-Webster. Web. 01 June 2010. . Baccarini, D. (1999). “The Logical Framework Method for Defining Project Success.” Project Management Journal. 30 (4): 25-32. Belassi, W. and Tukel, O. I. (1996). “A New Framework for Determining Critical Success/Failure Factors in Projects.” International Journal of Project Management. 14

(3): 141-151.

Coghlan, D. and Brannick, T. (2005). Doing Action Research in Your Own Organization.Second.London Sage Footprint. Hayes, Frank. (1997). “Managing User Expectations”, Computerworld, Nov 3, 1997, 31,44.