The Pareto principle for well-defined functional software requirements

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 busin

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Software requirements techniques (Prototyping, Storyboards, Modeling, State transitions) Quality assurance (QA) and testing's role in requirements Agile software development tutorial: Agile requirements gathering Reporter's Notebook: Jack Vaughan on agile methodology Pros and cons of requirements-based software testing How to avoid requirements creep Making requirements walkthroughs more effective (and fun) Software development lifecycle (SDLC) trends 2009: Requirements, agile Using proactive test design methods to catch requirements issues early Is a requirements freeze in a software project a bad idea? Requirements elicitation: Workshops vs. apprentice-style analysis Software Requirements Requirements use cases tutorial: Advanced formats, test case comparisons Use cases for software requirements tutorial: Strengths, flaws, formats Quality assurance (QA) and testing's role in requirements Defining requirements during software project feasibility analysis Pros and cons of requirements-based software testing How to avoid requirements creep Making requirements walkthroughs more effective (and fun) Using proactive test design methods to catch requirements issues early Pictures communicate software requirements without slowing development REAL business requirements key to calculating ROI for a project

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary requirements analysis  (SearchSoftwareQuality.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

ess department to provide you with information for how the developers could prove themselves if the requirements are fulfilled.

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.