Getting Your Requirements in Order
Beginning With the End in Mind
When we built an event registration solution for an Olympics sponsor, I met with the program director and asked what information she needed from the solution. She needed to know the guests’ arrival and departure details, their hotel room preferences, and what games they wanted to attend. This enabled her to assign appropriate rooms for the guests and tickets for their group.
Managers needed arrival and departure reports to organize ground transportation, housing, food and beverage, and scheduled activities. These report requirements defined the objectives for the registration solution. We had a clear idea of where the solution was going when it collected registration information.
Where to Start? It Depends - Really!
The program director and managers needed their reports, which depend on good quality data, mostly collected by the registration solution. If I asked most managers about the value of the registration solution, most would say it's not that valuable to them. They think about the decisions they make based on the data, not where it comes from.
A purposeful architect recognizes that managers focus on the information they need more than its source, as they should. In this case, s/he determines that registration comes first because the reports depend on it. This may seem obvious, but cases arise where a business stakeholder expects information from a source not defined in discovery.
A purposeful architect should check each requirement for dependencies, like a data source or someone taking an action for the solution to proceed. If a high-value requirement depends on another requirement, the other requirement becomes high value as well. It gets developed first to meet the dependency of the high-value requirement.
Value vs. Urgency
When discovery has captured enough requirements to cover a solution’s scope, the business stakeholders should rank them in order of business value to guide development scheduling. Some requirements may have a deadline which gives them a higher ranking.
For example, the registration solution had a requirement to collect the identity of a guest’s companion, in addition to the guest’s identity. Guest registration had to meet this requirement before we deployed it, making it urgent.
Here is a sample list of user stories for a registration solution, including the companion registration requirement:
| Story | Value | Urgency |
|---|---|---|
| Attendee registers companion | High | High |
| Housing manager provides guest and companion names to guest hotel | High | High |
| Transportation manager validates flight information | High | Medium |
| Attendee selects bed count preference | Medium | Medium |
| Housing manager sorts report by guest name, arrival and departure date time | Medium | Medium |
| Attendee registers more efficiently - dependent on Lightning features |
“Low” | Low |
The most valuable requirement, “Housing manager provides guest and companion names to guest hotel,” depends on the attendee registering their companion, so “Attendee registers companion” has a higher ranking for development.
The last story, “Attendee registers more efficiently,” really has a high business value but temporarily has a “Low” value to keep it off the schedule until the Salesforce Lightning features it needs become available.
Keys to Ranking Requirements
Ranking requirements depends on the answers to the following questions:
How valuable is each requirement relative to other requirements from a business perspective?
What degree of urgency does a requirement have?
What requirements do the most valuable requirements depend on?
The business stakeholders should have an idea of the most valuable requirements and which they need sooner rather than later. A purposeful architect checks the requirements for dependencies, ranking requirements that meet dependencies ahead of those that depend on them.
Consider dependencies and urgency as well as business value when ranking requirements.