What are brittle requirements
What are brittle requirements? To put it simply, they are requirements that are easily broken. Or requirements that easily have gaps or issues in the logic. Where even basic and common use cases can cause issues with how the requirements would perform in a product and system. Brittle requirements are vague, ambiguous and/or not easily understood. Where the requirements don’t provide the detail to outline how something is to perform.
In addition to not covering information and details that are needed, brittle requirements may cover information that they shouldn’t. IE, they incorrectly extend logic into a scenario or use case. Because the requirement was too generalized, making it too brittle.
Or, logic was extended beyond its original intent. This can happen when systems are added to overtime. More and more changes are made. Functionality is stacked on functionality and is soon doing things it shouldn’t, or at least other than intended.
Brittle requirements are the requirements created and written that partially define a product, system, and functionality. When instead, they should be refined to more clearly make that definition. Or added to, in order to more clearly make that definition.
Why should you avoid them
Brittle requirements will result in more bugs and production issues. Definitely more than needed. Brittle requirements cause systems to go down. They cause errors and incorrect processing or handling of data. Which all of these cause headaches for the users, those that have to fix them, and everyone else involved.
Brittle requirements cause more meetings and discussions on how to handle issues. Or more retrospectives to learn from problems experienced. Brittle requirements cause the need for more formalized testing and extremely detailed regression. Or maybe more automated testing than might be required.
They also cause a lack of trust. When things continually go wrong, it can erode the trust in teams to complete the job without issue. Brittle requirements promote that loss of trust and can really hurt the process.
What practices help avoid brittle requirements
Just in time requirements
Just in time reqs is a process that to me resolves around 2 notions. The first, is that you aim to understand the big requirements first. At least before other requirements. The most important things, that make or break a product and functionality. These are the requirements that you organize other requirements around. These are also the requirements that you build off from, and add to, to refine and build out the definition. So starting with these items helps to get the most important things right, and to get those right first. Then allow you to move on to the next items.
The second idea here is that you get enough to go enable work. You get requirements and work requirements in smaller portions, and really focus on those. Then when they are in a good place, you get the next ones, or keep expanding the information. This also helps to get the pieces correct, and build more robust requirements information.
BDD, aka Behavior Driven Development
BDD is a process built to solve communication issues between those building software products and those needing or using them. Too often, the needs are not fully understood. There also tends to be communication issues in getting to that good understanding of needs. Or problem to be solved. Which is sort of an underlying problem with requirements anyways. In that they don’t paint the full picture and more is often needed.
BDD tackles this issue by trying to place needs in a specific context for the team. That context is figured out collaboratively. It also extends the understanding by using specific examples. Instead of just saying, “I need xyz”. BDD extends that requirement process to say “I need xyz, because of a specific reason”. It also then adds examples in a detailed and specific way, to help build that understanding of what is needed. Typically, this is an example in the format of, given some scenario, when I do this, then this happens. Presenting in this way helps build a solid understanding of the needs for all involved.
DDD, aka Domain Driven Design
DDD is also a tool to help teams work more collaboratively and to help build the shared understanding. It does this by attempting to use shared language to describe and implement the software products needed. By translating everything to shared language, the teams can be more in sync and actually deliver what is needed.
As opposed to an often seen example, which is business users using their typical terminology for things. Then development teams taking that terminology, and thinking it means something else or not understanding what it means.
Agile way of working
In general, the practices of Agile help to avoid brittle requirements. The practices of Agile help obtain and reinforce good information and collaboration. It does this by stressing the interactions and collaboration of team members and users.
By having actual conversations and real collaboration, you learn more than by contrasting and more traditional requirements practices. Which, is no coincidence that Agile practices came to be, as a way to help address some of the issues of traditional requirements practices. Brittle requirements being one of those issues.
In the end
Remember to help create and promote strong and resilient requirements. The products and systems you help build are only as strong as the information and decisions used to build them.
Additional reading and books to understand what to do about brittle requirements
Also available on Leanpub is the guide to the Product Owner skills needed, check out here.