Striking the Right Level of Detail in Requirements
|
In today’s hyper-competitive marketplace, companies are releasing products faster than ever before. However, that increased emphasis on time to market doesn’t change the expectations: producing quality products while, when necessary, conforming to all relevant safety and quality standards.
Finding that critical balance between speed and quality is essential for product teams, which is where requirements management comes into play. Unfortunately, a lot of teams don’t take the time to flesh out requirement details – or they have the opposite problem and provide too many details, and confuse requirements with design specifications. Here are some examples and recommendations to make sure you’re getting the most value from your requirements.
Scenario 1: I need more details!
In this situation, teams fall into a trap of not taking the time to define requirements. For example, a marketing team — which tend to think more strategically — will often give high-level problem statements directly to an engineering team, which typically thrive on details.
What happens next is either:
-
- Engineering team builds a product that doesn’t solve the high-level problem
or
- Engineering team will bombard the marketing team with requests for additional information until both sides are frustrated and late on delivery
Neither scenario results in a smooth development process, and both can breed mistrust between teams whose ultimate goal is the same, in spite of their differing roles.
Well-formed and reviewed requirements clear the path for a quality product that meets market needs and expectations.
They ensure each team member is on the same page, and that everyone involved knows exactly what they’re building and why.
Scenario 2: Too many details – I can’t innovate!
In this case, the team members responsible for authoring requirements can sometimes cram too many design details into the requirements themselves. For example, I once saw a requirement that read: “the button shall be red and shall be located in the top-right corner of the console.”
First off, that’s actually two requirement statements – but either way – it’s describing implementation detail and, taken on it’s own, I have no idea of “what” the button should do or “why.” Is this supposed to dispense a soda from a vending machine or fire a missile from a battleship?!?
Requirements like these create friction within engineering teams, limiting their ability to innovate while getting bogged down with overly specific instructions.
Engineering teams should ideally be free to iterate and innovate the design rather than simply doing what they’re told. The requirements should focus on the need and keep teams aligned on “what” is needed and “why” while engineering experts figure out “how” to implement.
Recommendation: Establish a Common Taxonomy and Trace Model
An important step in striking the right level of detail in your requirements is establishing common terms in your product development process.
Many teams use different terms to refer to the same thing (e.g. “specification” – this term means so many different things across different teams).
Having a glossary or standard that clearly delineates important terms and deliverables facilitates clarity throughout the development process and reduces the confusion referenced above.
Using a traceability model establishes appropriate hierarchy and helps break down high-level problems to detailed requirement needs. It also can facilitate test coverage of requirements. This clarity is especially important when dealing with life-critical systems, such as medical devices or autonomous vehicle systems. In these cases, missing requirements or inadequate design and testing can quite literally cost lives.
Finally, teams should be able to differentiate Requirements from Design. In other words, the “Need” vs the “How.” Bundling both together inside requirements can lead to added complexity, unnecessarily constrained design, and friction between teams.
Quickly bringing a quality, safe product to market is a challenge. Requirements and design are both key elements to doing so. Making sure teams strike the right level of detail in the requirements is critical in avoiding confusion and reducing friction in the process.
For a deeper dive on separating requirements and design specifications, check our this webinar, “Best Practices for Writing Requirements.” Jama also offers Requirements 101 workshops – please inquire if you’re interested in improving the requirements process in your organization!
Sr Director, Global Business Consulting at Jama Software
Mr. Mitchell's experience is focused in complex product development for Fortune 500 companies and the U.S. federal government. Jama Software works with inspiring and innovative companies building next generation products like self-driving cars, life saving medical devices, and safety critical avionics.
Preston is a subject matter expert in product management and requirements management best practices with focused experience in avionics, medical devices, and complex software. He's experienced leading clients through the full lifecycle of a technology program.
Preston's current responsibilities at Jama Software include directing our Global Consulting team with focus on scaling our delivery quality and efficiency as Jama Software grows.
Specialties: System Engineering, Requirements Management, Test Management, Scaled Agile
Preston is a subject matter expert in product management and requirements management best practices with focused experience in avionics, medical devices, and complex software. He's experienced leading clients through the full lifecycle of a technology program.
Preston's current responsibilities at Jama Software include directing our Global Consulting team with focus on scaling our delivery quality and efficiency as Jama Software grows.
Specialties: System Engineering, Requirements Management, Test Management, Scaled Agile
Latest posts by Preston Mitchell (see all)