Oct 23, 2023

Chapter 9
Requirements

Author Note

This is early draft material, barely more than a stream of consciousness and notes.

Time, mind, and space.

Mind to mind versus mind model mismatch.

The trick is to balance all these factors against available resources.

There is no mileage in spending time developing too specific requirements, but too general requirements will result in wasted downstream effort.

Figure 9.1:The requirements funnel

Figure 9.2:The design space

Requirements communicate the customer’s needs, wants, and desires to the developers.

Requirements are always expressed in the language of the consumer¹, the ‘domain language’.

Language is slippery, it is easy for misunderstandings to happen even under the best conditions. We maintain a glossary for all terms used in our requirements, this is the definitive record of meaning in our project.

Requirements need to be specific enough that the development team can deliver the requirements in a timely and accurate manner. This obviously means the level of detail will depend on the relationship between the development team and the consumer. When the consumer and developer are close, for example working side by side, the documented requirements can be less specific².

Requirements are constraints in the ‘space of possible solutions’ Figure 9.2.

¹I use the slightly awkward terminology ‘consumer’ and ‘producer’ because many other terms like ‘user’ or ‘client’ are overloaded (people tend to think of ‘user’ as a person while ‘client’ is, for better or worse, bound to ‘server’).

²Assuming there are no external project drivers, such as regulations.