Skip to main content

The Top 5 Mistakes in Requirements Practices and Documentation

FEATUREMay29thIn my work with dozens of organizations improving business analysis practices, the following are the most common themes I see hindering the great value that good business analysis practices can provide.

1) Lack of collaboration and review of requirements

Collaboration and review of requirements should be an ongoing process of meeting, discovering, and collaborating to share information and context. Verifying that requirements met the needs of others to guide further work and validating that the requirements will add value to the business are critical pieces to this review and collaboration.

The mistakes I typically see in this area are teams that “gather” and “collect” requirements from stakeholders rather than using proven successful elicitation, discovery, and validation techniques. Following a “gather” and “collect” mindset sets a team up to jump to the solution too quickly before truly understanding the business needs and value required by the stakeholders.

The BA is often assigned to the project after business needs and values have already been discussed and the stakeholders pressure the BA to just move forward. This is the most important time for a BA to use powerful collaboration techniques that help the stakeholders feel that they are not restating the same information but are improving the business value proposition the project is set out to achieve.

Some teams see requirements reviews as sufficient collaboration. With requirements reviews I often see the following:
• Lack of review
• Reviewed, but missing critical stakeholders and consumers of requirements
• Reviewed but as a formality, and stakeholders struggle to truly understand requirements documentation

Ideally for requirements reviews to be successful, those using and signing off on requirements need to be fully engaged in reviewing requirements, verifying they are understandable, cohesive, and usable for the further work to be done, and validating the business value and intent of the requirements. To achieve this, BAs need to ensure that documents are presented and communicated in ways that are understandable to all audiences and the review process engages all audiences to fully participate in the review.

2) Not differentiating between capabilities, rules, project tasks, and design

Many requirements documents that I see in a large number and variety of organizations are missing the essence of what requirements are. The mistake I see is requirements documents lifting project tasks, detailed technical design, and business rules without listing the context and capabilities needed. This sets the project and solution up for a multitude of missed requirements and missed value to stakeholders. Business and solution requirements are capabilities needed by a solution to achieve a desired change in the business. They are not project tasks lists, technical design details, or bullet lists of business logic. Focusing on the true requirements instead of the project tasks and design will shorten the requirements timeline.

Project tasks need to be in a project plan of some sort, and design should be happening progressively as requirements are discovered and must account for feasibility and alternatives. Design needs to be differentiated from what the requirements are, and this can occur in a separate document or not, but it needs to be differentiated. It is no fun to manage requirements change when the requirements document is really tasks and design; this will cause more change management administration than needed. Requirements change becomes much more manageable when it is truly business and solution requirements that are changing. Changing design details and project tasks is likely to happen with more frequency and may not impact the end result, and a failure to differentiate can cause costly rework and unneeded administrative tasks.

Business rules are critical to successful requirements, but I often see requirements only in the context of business rules, and sometimes up to 90% of a requirements document is a listing of business rules. Business rules listings without the context of processes, people, data definitions, sets, projects up for missed requirements, inefficient and inconsistent implementation of business rules. Understanding the business rule outside of technology enablement is crucial to improving the consistency and efficiency of business rules. Differentiating business rules from requirements is critical to understanding and analyzing the capabilities needed to implement the rules.

3) Lack of context and visuals

Context and visuals provide our requirements readers with brain candy. Many studies show that visuals are consumed by the brain much faster than text and help depict relationships, whereas text is processed in a more linear fashion in our brains. Cognitively, visuals are proven to be more effective than text at increasing a reader’s comprehension and retention. On the other side, visuals without text can be too ambiguous. So, why do so many requirements documents lack visuals and context that would help readers comprehend and retain the very information BAs are asking them to approve? As Bas, visuals are sometimes present but often are too complex to engage our readers and need to be simplified. Sometimes our visuals as BAs are design oriented rather than intended to help readers understand context, interactions, and relationships.

Great requirements are documented in a way that allows the reader to choose the level of detail they would like to consume, provide visuals and context of varying levels of detail needed to guide further work, and provide text that clearly traces the visual and context representing the text.

4) Too much focus on the as-is current state

Projects and business analysis work is about changing the way organizations operate. It amazes me how much time is spent on documenting the as-is; I am not advocating ignoring the as-is or current state, because it is needed to understand the gaps that must be crossed to get to the future desired state. The challenge and mistake I see teams making is never getting to defining the gaps and future state. And, sometimes all of the context and visuals are about the current state with nothing showing the context or visuals for the future state.
Our requirements need to understand the current state, but the requirements themselves should represent the gaps and future state. We are not asking our stakeholders to approve the current state. Instead, they are asking us to help them change, hence we need to define the future state. Our requirements need to answer the questions: Why are we spending money on this solution? What value will the solution bring?

There are many statistics out there about the percentage of functionality in current systems that is not used; the numbers typically range between 60-80%. This raises the question of why we would document requirements for the future the way the system works today when 60-80% is not even used today? After all, today’s system was likely designed 10, 20, or even 30 years ago and we can’t possibly compete in todays business environment by developing solutions based on functionality designed for business years ago. After all, how will this take the organization into the future?

Great requirements practices and documents show how the current state is going to change, what the future state is, and the gaps to get there. There are many areas of solutions where the current rules, process, and technology will be leveraged in the future state, and this is where we need to ensure we are focused on the future by defining what pieces will move forward, and we shouldn’t spend too much effort on current state items that will not carry forward. This is done by identifying the current state at a higher level and questioning if this piece will continue to add value in the future state vision. At that point, a BA should only go into details if the value is justified.

5) Allocating requirements too early to the applications they will be implemented in

When evaluating business analysis practices and how they align with software development processes, I often see that the requirements are being allocated to software applications before the requirement itself has much context or elaboration. Understanding the requirement and business need is needed before we can specify what system or application will be changed or built to implement the requirement. The practice of assigning the technology to a requirement before the BA is assigned or before the requirement is vetted defeats the purpose of business analysis in many ways. This practice also makes requirements change a huge challenge. As we discover and elaborate requirements, we often find that the initial idea on implementation is not feasible or optimal. If the requirements process has already allocated the requirement, it takes a change request to change that in some organizations. This is where the process hinders good business analysis. Many times this practice is not in the control of a BA, but I do believe that a BA can collaborate with others, and elicit and document requirements in a technology-agnostic manner to facilitate the discovery of other ways to implement requirements.

Great requirements practices focus on the user, process, rules, events, data, and non-functional needs before deciding which exact implementation technology will be used. This allows the team to discover the true business need and explore options and alternatives that may not have been previously thought of. It also helps ensure feasibility prior to committing to a specific solution design.

Let me know your thoughts on the common mistakes in requirements practices and your challenges in these areas.

Don’t forget to leave your comments below.