Implied Requirements

If you need a way to nail down the functionality that needs to be covered, then make a list of functional areas and domains instead of breaking it down into traditional requirements. undefined

To be applied after

 * Implied Requirements is an input for Development Episode, Recommitment Meeting, Work Queue and Work Split.

Contents of following sections belong to the original Organizational Patterns website and have been divided into following parts: Context, Problem, Solution, Discussion.

Context
... a Product Initiative [Cunningham1996] has identified the direction for further development and a Market Walk-through [Cunningham1996] has explored the customer motivation and developmental possibilities behind it. We expect positions and attitudes to be understood but have yet to make any commitments beyond everyone’s general commitment to do a good job by the company.

Problem
A commitment implies an agreement between people. Development commitments generally obligate developers to meet some customer need in a timely and satisfactory way. The tension here is to define a need in sufficient detail that commitments have meaning without exhausting up-front analysis or over constraining a solution.

Solution
'''Select and name chunks of functionality. Use names that would have meaning to customers consistent with the Product Initiative.''' Allow these names to imply customer requirements without actually enumerating requirements in the traditional sense.

Discussion
Examples: These names will fill in the blank in the recurring questions like: Who’s handling the programming (or specification, or customer contact, or manual update, or release notes) for _____.
 * Year-End Tax Reports
 * Dollar Denominated Japanese Bonds
 * High-Quality Printing
 * Disconnected Operation on laptops

A version of this pattern first appeared in [Cunningham1996].