Too-detailed requirements?

Back in May, Scott Amber had a hot take:

This position is no surprise. In Ambler’s textbook, he advocates simple whiteboard sketches as the maximum level of modeling.

Why do so many project managers focus on so much documentation and process? In a lot of cases, it’s self-serving: tangible work output shows that they are doing something, which can be very important to compensation and continued employment. It also provides a sort of CYA in case the project fails.

Nonetheless, as Ambler suggests, too much is counter-productive. Time spent modeling and collecting requirements is time not spent on building the deliverable. Requirements that are too detailed up front reduce the flexibility needed as a project moves forward.

Ambler says the right detail level of requirements is “just enough”, which is an entirely unhelpful suggestion. In fact, I’d argue that it forces project managers to err on the side of being too detailed. For the reasons above, the incentive is to be more detailed rather than less detailed.

There are really two kinds of requirements: business and technical. The business requirements define what the end users need to be able to do (or not do), regulatory compliance, etc. These should be defined in terms of what, with no respect to how. For example, “the user should be able to remove jobs they submitted”, not “the user should be able to click the ‘Remove’ button on the ‘Jobs’ page to remove jobs they submitted.”

Now, it may turn out that the second example turns out to be exactly how it works, but why commit to that up front? Technical and UX expertise should define how the business requirements are implemented. That’s what your technical requirements are. Modeling and requirements will eventually get detailed as you iteratively develop the system. So detailed requirements are important (as documentation after the fact if nothing else), but the issue is when you get detailed.

Leave a Reply

Your email address will not be published. Required fields are marked *