Best Practices for Business Requirements Capture/Analysis

This is often the hardest part of a software implementation. Imagine the countless times when you have been in meeting trying to understand what the client wants and or the best way to capture this without losing the client’s trust. There are a few trusted techniques that have helped our process of eliciting and capturing requirements. This is based on real world experience that you can refer to and use in a manner that meets your objectives.

The first steps and the most important step is to write a project charter. There are many templates for project charter and feel free to use what works for you but ensure that you have approval from your client on the format of the project charter. Project charter is a 1-2-page document that must capture the scope of the project i.e. what are you trying to accomplish from a business perspective with the project implementation. Typically, the project charter must include a bulleted list of items that are a high-level list of requirements from the project implementation. Within the public sector, you would go through a competitive solicitation process before you get to the point of writing the project charter. By this point, companies typically have promised a list of deliverables that they will provide from the project implementation. In such case, this can be constraining. It is important to note that processes like an RFP can be very long and the business objectives can be different from what was documented in the contract resulting from an RFP. However, you can base the list of items in the charter on the deliverables listed in the contract with the client. This forms the baseline, but you must ensure these items are presented, discussed, and accepted by the client.

Once you have the charter approved, discussions with the client on requirements can begin in earnest. Documenting requirements during these discussions can take the form of informal note taking. However, it is important compare notes with the project charter almost daily during the requirements gathering phases. What you are looking for is an answer to the following question… does the requirement fit within the stated business objectives in the project charter? If it does, you’re good. If not, bring to the client for clarification. If it’s an outlier, create a parking lot and list the item there. Basically, you are creating another list of items that do not fit within the agreed to scope of things.

Now, it is important to begin documenting the confirmed and scoped requirements in narrative form soon after the discussions end to avoid forgetting details mentioned in the discussions. I refer to this as an implementation specification document or ISpec. The purpose of the ISpec is to use the approved and validated requirements and construct a document that captures the overall business context for the proposed software implementation. You might wonder, if you are following agile principles, why the requirements cannot become user stories. This is a lesson learned from personal experience. User stories are very discreet work items and they often lack the full business context. Most importantly, there needs to be a review and approval on your understanding of requirements from the business division. A narrative document provides a better medium. An example of this for a procurement management system is documenting the requisition process in a document with roles, steps, actions performed at each step and rules associated with the step. You can also do this using a flowchart. Something that demonstrates in very clear terms, the understanding of the requirements that can be reviewed and approved by the business stakeholders.

It is at this point that you can begin decomposing the requirements into user stories or backlog items. Another lesson learned from documenting user stories is to keep the structure simple. Remember, the user stories are for the developers and developers often want to get the requirements in most concise and clear manner possible. Discuss and align with your development team on user story structure. Key point is to include the details from the ISpec into acceptance criteria for the user story. It provides the dev team with one area where completion criterion for the story are documented.