There is a distinction between the project requirements and the requirements package.Requirements can be organized, sliced and diced, torn apart, allocated, put back together, assigned attributes, etc. Packages are finely wrapped presentations of requirements in ways that suit a specific stakeholder audience. Very often we conflate the two, or start with the package before understanding what the requirements are and what our stakeholders need to see.
According to the BABOK, the purpose of Prepare Requirements Package is:
“To select and structure a set of requirements in an appropriate fashion to ensure that the requirements are effectively communicated to, understood by, and usable by a stakeholder group or groups.”
And the BABOK goes on to further articulate why this is important.
“Requirements should be presented in formats that are understandable by the stakeholder. This task describes the work required to decide which format(s) are appropriate for a particular project and its stakeholders. They must be clear, concise, accurate, and at the appropriate level of detail. Requirements documentation should be created only to the extent needed to ensure clear understanding by the team.”
I think this is a powerful task because it clearly separates the elicitation and analysis of requirements from the creation of a package to communicate requirements. This is essentially saying that discovering the requirements is not the end-all-be-all of business analysis. We must also invest the effort in creating packages that support our stakeholders in understanding those requirements.
And these packages are not necessarily documents. They can also be presentations or visual models.
It’s difficult to think about a project where I didn’t create a requirements package of some sort. And they have ranged significantly from a collection of nicely formatted wiki pages to slide decks presented to the board of directors to formal documentation (aka big thick requirements documents) reviewed by a large cross-functional stakeholder group. As I matured as a BA, this is one area that I found myself experimenting with, always looking for a simpler and easier way to communicate the essence of the requirements to inform a particular decision or follow-up task.
One example I’m especially proud of is a one page epic I created to scope a significant feature to be developed using agile. On one page I captured the business rationale for the feature, key stakeholders, essential business requirements, constraints, risks, and unknowns. It was easy to review and validate, and a great touchstone for elaborating the requirements into a product backlog and user stories.
Just like the perfect birthday or holiday gift starts with understanding what the person really wants, the perfect requirements package starts with understanding what your stakeholders really need and how they will best understand it.
This post is one installment in our Journey Through the BABOK with BA Stories series.
Well articulated article. I always believed that requirements should be gathered in methods which can be understood by the key stakeholders as well as the IT counterparts. It doesn’t matter whether you have used flowcharts or Use cases, what matters the most is the requirement being made to understand to the various stakeholders. Thanks Laura.
The requirements package I am most proud of included the as is maps, the to be maps and then the requirements split into four categories that provided meaning to the business and the implementation. The process maps made the package relatable to the business, the maps referenced the requirements so it gave direct relationships to the business process.