Not all requirements are known


It is time to start development, but not all requirements are known.


Requirements come in three levels of detail (at least).  Least detailed are ‘Scope requirements’, that delimit the scope of the system and its broad functionality, and enable rough estimates of effort.  ‘Detailed requirements’ enable development of the system to commence, and during development, the finest detail may be sought in ‘Clarifications’.  The Waterfall process that attempted to collect all requirements before proceeding to analysis, etc. may have been useful in its time.  However, in those days, the cost of changing any requirement once development on it had been done was very high.  Much work has been done to bring these costs down, and any process that does not take advantage of the shifted balance between ‘getting it right first time’ and ‘fixing it when it’s found to be wrong’ will be considerably less efficient than the ideal.  These days, IterativeDevelopment is the norm. 

Prevention, Amelioration, Cure

Prevention of Incomplete Requirements requires such a heavyweight process that it should not be attempted out of safety-critical projects.


Start off by gathering ImpliedRequirements that enable the scope of the system and rough estimation to be investigated.  Once you have a reasonable level of detail in some area of requirements, you could JustDoIt, or perhaps BuildPrototypes to flush out more requirements.  A similar approach could be taken in the form of EarlyAndRegularDelivery, suitable where detailed requirements can be provided on demand, but not all at once.  When collecting detailed requirements, and particularly when clarifications are needed, it helps to EngageCustomers.  Where the customers are not available on demand, it helps to interface with them via a SurrogateCustomer.


XP has taken these approaches to their logical conclusion, gathering scooping and estimation requirements as UserStories, and having the CustomerOnSite as part of the team, to provide detailed requirements and clarifications just in time for development.


1. Agile Requirements Challenge #3. Project Stakeholders Don't Know What They Want