The "Flexible Features Split" Modeling Pattern

No matter how much time you invest, no matter how thorough your model reviews, no matter how skilled your modelers are, the requirements are still going to change throughout a project. Yet, in many situations you need to be able to define, fairly early in a software development project, what is going to be delivered by the team for the current release. Perhaps you're developing commercial software which needs to be advertised long before it's available, or perhaps you're outsourcing development of the system and want to know what you're going to get before you sign the contract. Worse yet, you have a defined delivery date and a fixed budget: sounds like a classic "iron triangle" dilemma, doesn't it? The fundamental question is how do you meet these needs yet still remain agile?

Solution

First, do some initial agile modeling to identify the scope of the project via requirements envisioning. This will not only provide you with an understanding of what needs to be built, it also provides you with a high-level list of requirements which your stakeholders can put in priority order. Your goal is to identify the requirements to the point that you understand what they mean, it is not to fully document them. For example, the requirement "Enroll a student in a seminar" may be sufficient detail for now, or perhaps you need a point-form version of a use case of the use case to feel comfortable, but you certainly don't need a fully documented version. Create models which are just barely good enough for your current needs; remember that you can always fill in the details later on a just-in-time (JIT) basis.

Second, prioritize your "finalized" list of requirements and commit to delivering the top X% no matter what, but also promise to deliver something from remaining requirements if time permits. A common value for X ranges from 60 to 80, your goal being to set X at a reasonable level which enables you to safely deliver sufficient functionality for the given schedule and budget.

Third, publicly commit to only delivering that X%, but strive to deliver beyond that. Doing so puts your development team in the enviable position of under promising and over delivering while still being on time and on budget.

Consequences

Early in the project you do not have an exact definition of what will be delivered, you merely have one that you believe is going to be close. Many stakeholders are uncomfortable with this approach and will insist on more requirements modeling up front than is actually healthy for your project. Expect some interesting political battles as a result.