Gathering requirements for software development projects has always been a difficult process, and has veered through various methodologies like waterfall and agile. Regardless of the methodology, though, there are certain pitfalls to deciding and describing just what an application should do that can result in projects stumbling or failing. Requirements fractalization, focus on little used details, or lack of developer and stakeholder involvement can all actively harm the best architecture.
Requirements Fractalization
Remember learning about fractals in math or science class? They’re repeating patterns that can be viewed at any scale. That is, keep zooming in on a fractal and you’ll keep seeing the same image — and the same complexity.
When a project is first estimated, requirements are usually written at a high level with relatively little attention to detail. That’s especially true today, with the current focus on early releases, beta software, and fast iterations. Why write down a lot of details that are likely to be thrown away before implementation when the first customer release sends the app in a completely different direction?
But it’s easy to imagine how this lack of detail in an initial project proposal affects the reliability of an early project estimate: a line item like "there should be reports" might result in a week or two of work, or six months.
One common sign that an early estimate was too optimistic, with troubling repercussions on budget and schedule, is when the high level requirements expand fractally. A client and developer sit down to identify a project requirement and determine:
- There should be reports
- Reports should be customizable
- Custom reports need searchable field selection
- Field selection needs to include customer-supplied IDs
- Customer-supplied IDs can be strings or integers
- Users should be warned when the ID type changes
- The warning should allow duplicating the custom report
- Duplicate custom reports should be shown side by side
- And it’s turtles all the way down!
80/20 and 90/90 Rules
When requirements fractalization starts to occur, it’s worth remembering the 80-20 rule (more formally known as the Pareto principle):
Roughly 80% of the effects come from 20% of the causes.
— Joseph M. Juran, using work by Vilfredo Pareto
This applies to land ownership (80% of land is owned by 20% of people), sales (80% of sales come from 20% of customers), and various other enterprises. In software, it applies in two important ways:
- 80% of users only use 20% of an app’s features
- 80% of code is written in 20% of the time
Although the latter often feels more along the lines of the 90-90 "rule":
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
— Tom Cargill, Bell Labs
It’s easy to follow a logical path from each important feature through all the possible ramifications, and end up with individually sensible but collectively impractical solutions for each one. In the aggregate, these minor details are too expensive and not useful enough. For each step away from a key feature, consider: How often might this requirement detail get used? Is there a simple workaround that can sidestep this chain of requirements?
If the requirement detail wasn’t originally listed as a key feature, or doesn’t clearly set the application apart from the competition through an excellent and commonly accessed user experience, strongly consider any inexpensive alternative, even a "This feature isn’t yet finished" alert or an automatic email to customer service.
Developer and Stakeholder Input on Complexity
It’s easy to fractalize features when writing a requirements document. Common causes include assuming:
- Implementation of a detail is simple
- A feature will be unusable without a particular detail
There are a few ways to counteract these causes throughout the life of a project. Fractalization in requirements planning is common and often unavoidable, so the key is recognizing it and preventing it from diverting the immediate focus of a project. If a team is susceptible to it, then it’s helpful to integrate these steps throughout all stages of the project, not just early planning.
Review the requirements document with people who wear different hats
Typically a project manager and client contact will collaborate on a set of requirements. After a first draft has been written, it’s often helpful to bring in a developer, who can identify unexpectedly expensive details or suggest ways to transform disparate details into a simpler, reusable approach; and a stakeholder, like a CEO, who can authoritatively nix less-important details.
Actively encourage individual developers to speak up when confronted with a fractal requirement…
or one that can be satisfied more simply than outlined. Pre-development document reviews can be tiring and tend to be skipped entirely if planning time runs short. But a developer ultimately digests each detail, and can feel either empowered to speak up to reduce project cost and complexity, or restricted to literal, unquestioning implementation.
View written requirements as tentative plans…
that can be adjusted to better reach the real goals of the application. Developers will only feel inclined to suggest changes if the requirements owner tends to accept those changes or work towards a simpler approach, rather than resolutely champion the primacy of the requirements document.
Maintain a backlog of requirements details…
that get shifted out of early releases. A feature detail may be important or useful but still need to be delayed in order to release a product sooner. A growing list of these delayed details can provide more confidence in the act of shifting them out of the current development cycle.
Above all, reflect on the ultimate goals of the project frequently, and remember that it’s better to release a triangle than never finish a snowflake.
