We have considered each requirement as a separately identifiable, measurable
entity. Now we need to consider the connections between requirements and to
understand the effect of one requirement on others. This means we need a way of
dealing with a large number of requirements and the complex connections between
them. Rather than trying to tackle everything simultaneously, we need a way of
dividing the requirements into manageable groups. Once that is done we can
consider the connections in two phases: the internal connections between the
requirements in each group; and then the connections between the groups. It
reduces the complexity of the task if our grouping of requirements is done in a
way that minimises the connections between the groups.
Events or use cases provide us with a convenient way of grouping the
requirements [8, 4, 11,]. The event/use case is a happening that causes the
system to respond. The system's response is to satisfy all of the requirements
that are connected to that event/use case. In other words, if we could string
together all the requirements that respond to one event/use case, we would have
a mini-system responding to that event. By grouping the requirements that
respond to an event/use case, we arrive at groups with strong internal
connections. Moreover, the events/use cases within our context provide us with a
very natural way of collecting our requirements.
The event/use case is a collection of all the requirements that respond to
the same happening. The n-to-n relationship between Event/Use Case and
Requirement indicates that while there are a number of Requirement to fulfil one
Event/Use Case, any Requirement could also contribute to other Events/Use Cases.
The model also shows us that one Requirement might have more than one Potential
Solution but it will only have one Chosen Solution.
The event/use case provides us with a number of small, minimally-connected
systems. We can use the event/use case partitioning throughout the development
of the system. We can analyse the requirements for one event/use case, design
the solution for the event/use case and implement the solution. Each requirement
has a unique identifier. Each event/use case has a name and number. We keep
track of which requirements are connected to which events/use cases using a
requirements tool or spreadsheet. If there is a change to a requirement we can
identify all the parts of the system that are affected.
Requirements Test 10
Is each requirement tagged to all parts
of the system where it is used? For any change to requirements, can you
identify all parts of the system where this change has an effect?
