Before starting design on a project, it may be a good idea to prioritize your requirements. Why? Because grouping requirements together by relative importance can help you down the road with the customer in terms of flexibility in tradeoffs, design, and implementation should scope start to creep … as it usually does.
You’ll need the customer onboard to perform any requirements prioritization and that’s not an easy thing to do, but enlisting the customer in this effort and doing it at the beginning of the project before you actually spend resources on project requirements can give you the best flexibility.
Making a case for prioritization
If you postpone requirement prioritization and you end up facing a resource shortage, you may find yourself throwing away work already performed on lower priority requirements in a panic effort to focus on and finish the truly important ones. By the time a crisis like that comes in to play, it may be too late to fix it with prioritization. The portion of the project or product developed with the lower priority requirements may be too tightly intertwined with the portion implementing higher priority requirements to do anything about it. Dropping some requirements late in the development process may require major and expensive rework on the project and end solution.
Knowing requirement priorities early can help avoid the late-stage implementation train wreck. Prioritizing your requirements before design starts provide options to manage requirement additions and risk, enables the delivery of a useful product in spite of changes in schedule and resource allocations, and guides architecting and design tradeoffs.
Prioritizing provides options to manage requirement additions and risks
Even when you have a high-quality set of requirements and use them to derive the initial development cost and schedule, the product design process will reveal new requirements. It’s simply a way of life. For example, if the marketing department hears that a competitor is implementing new x, y & z features soon, you may find yourself adding those requirements into this release even though you started with excellent requirements. Things change, conditions change, competitors necessitate change. You must add development time and money, or drop other requirements in order to add the new requirements. If you are able to prioritize requirements up front, then you’ll know where to find the resources for the important late additional requirements. You’ll know which requirements can be postponed for later implementation to make room for the new requirements.
Prioritizing enables the delivery of a useful product in spite of changes in schedule and resource allocations
Marketing may decide that you have to deliver the new product or project sooner than originally planned due to competition, etc. or your budget could get cut. With requirements already prioritized, you can react to these squeezes by developing the solution with the most important features included now, and phase in remaining requirements as budget and time allows and with agreement from the customer (or in this example marketing … who in this case is the first-line customer).
Prioritizing guides architecting and design tradeoffs
Prioritizing requirements before a schedule or budget crunch can guide you to a product architecture that allows postponing less important requirements without forcing redesign. Prioritization can drive the architecture so that adding the lower priority features later won’t require rework of the rest of the solution. If you expect to add more to a product or solution at a later time, you can put the ‘more’ into the requirements in a manner that allows the developers to architect for the total future product. The product can be developed incrementally with the higher priority requirements in the earliest version and the lower priority requirements in the later versions of the product or solution.