Don’t trigger a data explosion with enumerated requirements.
Managing requirements can be tricky when it comes to managing data (information). The difference between a good approach and a bad approach can add up to hundreds of hours of labor over the life of a project.
In our picture, we show the weather forecast for several cities. Imagine we were writing requirements for a weather-forecasting page. We need a way to identify the cities for which we will show forecasting information. Imagine there is room on the page to show the forecasts for only fifty cities.
Solutions to this problem have evolved over the years. Good solutions have even been around for a long time. Unfortunately, too many projects stopped climbing the evolutionary ladder along the way.
Thag make fire
Realizing that the developers would not have the business context to know which cities to show, our simian spec writer documents all of the information. He meets with the stakeholders and they give him the list of cities. After eating a banana, Thag enumerates all of the cities for which we want to display weather information.
- […]
- The system shall show the forecast for Paris.
- The system shall show the forecast for Perth.
- The system shall show the forecast for Prague.
- And so on…
While this does show good use of tools, Thag fails the abstract reasoning test. We’ve talked several times about not putting implementation details into the requirements. Marcus wrote a good article about this on his blog a short while ago. This would be putting data details into the requirements. And it introduces a maintenance headache.
Sir Chauncey heats the boiling oil
A little abstract reasoning makes the maintenance of this solution better. Sir Chauncey realizes that there is a list of cities that he can represent as data. When interviewing the stakeholders, he discovers that the list of cities changes every 3 months – good data. We’d hate to have one of our serfs hard code the city names into the application. Sir Chauncey now only has to write one requirement
- The system shall show the forecast for the cities listed in ListOfCities.dat.
This is definitely better. Someone maintains the list of cities, and the development team is free to decide if they want to update the code every time the cities change, or dynamically access the list at runtime. Sir Chauncey hasn’t specified the implementation, and has also not saddled himself (or anyone else) with a long list of requirements to maintain. What our armored analyst has not done is understand why the fifty cities are on the list in the first place.
Kevin flicks a light switch
Kevin knows that there’s a reason why we have a list of citites. He just doesn’t know what it is. So he interviews the stakeholders, and eventually finds out that the marketing department is in charge of the list. Kevin discovers that the list is the fifty cities with the largest estimated number of AOL subscribers. The marketing department has targeted AOL users for this forecasting page.
Kevin also realizes that the limit of fifty cities is actually an implementation detail – and finds marketing’s true requirement – “as many cities as we can show without additional user interaction.” Our rennaissance requirements manager is able to write a more enlightened requirement.
- [R1] The system shall show the forecast for the cities with the largest number of AOL subscribers.
Kevin also writes a constraint.
- [C1] Additional user interaction will not be required to display the city forecasts. {This constraint affects requirement [R1]}
Kevin’s development team, like Sir Chauncey’s, can choose to access the list at run-time, or they can even calculate the list dynamically. And because Kevin wrote a constraint instead of ever creating a list, Kevin’s developers can even design a screen that shows more than fifty cities (they may choose to implement an interface that changes the list of cities every few seconds – like the Hertz Gold board, or a forecast-ticker that scrolls data across the screen, or anything else).
The evolution of our data requirements
What we’ve learned as the science of requirements management has matured is that we should not enumerate requirements when we can apply an abstract idea to describe them. In this example, the notion of each city as data is the abstraction. We’ve parameterized the data and simplified our requirements.
We’ve also learned to keep digging until we understand the true requirements, and not just the enumerated results of the hidden requirement. In this example, the hidden requirement is that we care about the largest AOL subscriber populations by city. We recognize that the list of cities is not an arbitrary list – there is a reason for including each city. So we document that reason.
