Everyone wants software that is user-friendly, robust, fast, and secure. Everyone also agrees that a failure to establish the right requirements often prevents software from fulfilling that wish.
Business analysts often end up writing fuzzy requirements for developers and testers because they haven’t explored the users’ needs to sufficient depth. Details go missing in conversations; feature requests are left vague. And the problem with vague quality requirements, of course, is that you can’t verify or test them; they’re no better than unverifiable functional requirements.
In order to address the problem of ambiguous, incomplete, and generally nonfunctional requirements, consultant Tom Gilb (known for the development of software metrics, software inspection, and evolutionary processes in the realm of business analysis) developed “Planguage,” a language with a rich set of keywords that permits precise statements of quality attributes and other project goals.
Let’s look at an example of Planguage in action:
- TAG: Performance.Report.ResponseTime
- AMBITION: Faster response time to generate HR reports on the base user platform.
- SCALE: Seconds of elapsed time between pressing the Enter key or clicking OK to request a document and the beginning of the display of the document.
- METER: Stopwatch testing performed on 10 reports that represent a defined usage operational profile for a sales analyst.
- GOAL: No more than five seconds for 95 percent of reports.
- STRETCH: No more than two seconds for predefined reports, five seconds for all reports.
- WISH: No more than 1.5 seconds for all reports.
- Base user platform DEFINED: The very least required: Quad-core processor, 8GB RAM, Windows 8, Query Gen 3.3 running, single user, at least 50 percent of system RAM and 70 percent of system CPU capacity free, network connection speed of at least 30 Mbps.
Each requirement has a unique tag or label, and uses a hierarchical naming convention. Requirement labels such as “Performance.Report.ResponseTime” are intuitive. “Ambition” states the goal/objective of the system that leads to this requirement. “Scale” is the unit of measurement and meter describing the metrics/measurements. All stakeholders need to have the same understanding of what’s meant by “Performance.”
Requirements aren’t met unless every goal condition is met, so the business needs to make sure the goals are justifiable in terms of real business needs.
The notation of Planguage might be somewhat unfamiliar to some people. Others, however, recognize the merits immediately.
Planguage has quite a few additional keywords for flexibility, and to help with precision in specifying quality attribute requirements along with business objectives. There is no place for ambiguity in Planguage; offering multiple levels of achievement will yield a far better statement of a quality requirement than a simple black-and-white, yes-or-no construct.
The drawback to using Planguage is that the final requirements are much bulkier than simple quality-requirement statements, but the richness of information provided outweighs this inconvenience.
- Revealing a Project’s Missing Requirements
- How BAs Can Manage Stakeholder Expectations
- Why a Business Analyst’s Role Is So Hard to Define