This post isn’t about composition of requirements. It is about using the object-oriented concept of composition when expressing requirements.
Composition is the notion that one object or entity is made up of multiple smaller objects. Grady Booch’s Object Oriented Analysis and Design with Applications (2nd Edition), is the de facto standard for learning about OO. He explains composition using the simple test – if the parent object “has a†child object, it is composition. He contrasts this concept with inheritance (child object “is a†parent object). A car has wheels (composition). A dog is a mammal (inheritance).
In Telescopes, Microscopes, and Macro-scopes…, I stressed the importance of writing requirements at the right level of detail to avoid ambiguity. There is also a huge benefit to being able to group a set of requirements and talk about them as a single entity.
This is where composition comes into play.
As an example, imagine writing the requirements for a system that allows a company to manage proposals (customer-specific contracts for the sale of services) as part of a CRM system. There are multiple requirements – how salespeople can create proposals, the workflow of the approval process, and proposal management activities.
The product roadmap for this system involves releasing “support for proposals†in a single release. There is benefit then, to being able to address this set of requirements collectively.
If you write one requirement – “The system shall support creation, processing, and management of proposals†– it is very easy to manage the delivery. But you’re at the telescopic view – and horribly ambiguous. If you put enough detail to get to the macroscopic view into the requirement, you run into the problem that you’re really describing multiple requirements in one requirement (another no-no).
The best approach is to use composition – write the high level requirement, which serves as the parent requirement for the more detailed requirements:
1. Proposal support
1.1 Proposal states. Proposals will be shown to users as having one of the following states, as defined in the data dictionary: draft, submitted, approved, rejected, completed.
1.2 Proposal creation. Salespeople can create and save proposals which are automatically created in the draft state.
1.3 Proposal workflow. Managers can create, submit, approve or reject a proposal. Salespeople can create and submit proposals.
1.4 Proposal viewing. The system shall present an interface that allows users to view all proposals in the system, filtering and sorting by proposal state and creation date.
1.5 Proposal modification. Completed proposals can not be modified. All proposals can be edited, and their state will be changed to draft after editing. Only draft proposals can be submitted. Only submitted proposals can be approved or rejected.
By introducing the composition concept, we can collectively manage the separate requirements, without losing the benefits of individual requirements (for example, 1.3 above would likely be linked to the requirements for user ACL or role-based permissions, but requirement 1.4 is unrelated).
