Properly managing requirements starts earlier than you think. While it’s critical to track requirements throughout development to make sure the right product is being built, for instance, none of that matters if they were wrong from the start.
If that’s the case, and issues aren’t fixed in a timely manner, problems will mount. Errors will likely show up in the final product, leading to costly rework, missed deadlines and potentially threatening the release of the project itself. And often times, it’s not even a technical problem or tool that can send things into a downward spiral; it’s simple human error.
That’s why it’s important to focus on getting requirements right before any other work actually occurs.
To that end, here are three common issues that can doom initial requirements and throw a product off schedule, adapted from Christer Fröling’s recent webinar, “Garbage In, Garbage Out: How Poor Requirements Inhibit Systems Development.”
- Brain Games
As you may have noticed, humans have communication problems. When requirements are initially getting relayed from key stakeholders through interviews or discussions, the propensity for miscommunication is high.
Our minds do all sorts of different tricks to make sense of information, and everyone has different blind spots. We can draw conclusions, ignore information, make assumptions, generalize and oversimplify.
All of these common practices of interpreting information can introduce errors during the requirements gathering process with stakeholders, but it doesn’t end there.
- Bad Language
We’re not talking about cuss words. This is vague and ambiguous words and phrases that can make their way into requirements and leave a lot of information open to interpretation.
Just think about the difference between a boardroom round table where everyone is giving their opinions on a product’s proposed functionality and the distillation of those ideas into a formal written document. There’s so much that gets lost when we go from talking to typing: no voice inflections, tones or pauses for emphasis.
The subtleties of communicated language need to be taken into account when requirements are written, so it’s extremely clear for the next reader what needs to be built and why.
- Needless Distractions
During the review process for initial requirements, it’s easy to get caught up in superficialities and miss the real dangers.
For instance, if you’re spending too much time fixing minor grammatical errors, you can wind up in a scenario where you’re wasting more energy critiquing the writer of the requirements than really taking a thorough look at the actual technical asks being made.
By only paying attention to the surface level of the requirements, you risk missing major liabilities that could be sitting just beneath the words themselves. Luckily, there are requirements tools that can help clear up the language for you, so you can focus on the technical detail.
For a deeper look at how to resolve some of these issues and get better requirements from the get-go, check out our on-demand webinar, “Garbage In, Garbage Out: How Poor Requirements Inhibit Systems Development.”