Manage Learn to apply best practices and optimize your operations.

The Pareto principle for well-defined functional software requirements

Following the Pareto principle, 20% additional effort by the business department can result in requirements accuracy and completion improved by 80%.

Often business analysts struggle with ambiguous requirements from the business departments.

There are many ways to deal with that problem. You can use a formal declarative syntax with a restricted amount of words. Or you can try the agile approach and sit with the business user and work with him on a prototype.

There is a third way, however. It's easy, and you might already be using it.

You've probably heard about the "test-first" approach for development. That is, before a developer writes the implementing code, he writes a unit test for it.

If you move this thought to the requirements level, you'll end in this rule: A functional requirement is well defined if the implementing subject is enabled by the specification to check if the requirement is successfully implemented.

In other words, you tell the business department to provide you with information for how the developers could prove themselves if the requirements are fulfilled.

More information on software requirements
Ambiguous software requirements lead to confusion, extra work

Clarifying software requirements

Software requirements: Using models to understand users' needs

Software requirements gathering techniques

Compared to the normal effort behind requirements definition, following this rule would result in a version of the Pareto principle where it would take 20% of the normal effort but it would result in at least 80% accuracy/completeness.

Of course, this could mean a strong paradigm change for your company. But the benefits would basically be the same as the obvious benefits coming with the test-first approach at the developer's side. Only now you've shifted to the earliest stage of the project.

From my personal experience, following this rule ends in very accurate requirements, as the test-driven way of thinking avoids lots of uncertainties that normally come up during the test phase of a project.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.