Requirements Change Notification

Responding to changing requirements is a crucial aspect of requirements management. RmChangeImpactAssessed scenario describes how proposed or actual changes can be dealt with. In integrated systems, workflows for responding to change require a means to notify interested parties that change has taken place and needs to be dealt with.

Suspect links is one mechanism by which actual change can be tracked. Suspect links emphasises the traceability that exists between artefacts - so that changes to artefacts can call into question the correctness of some trace relation. In common usage, suspect links are restricted to changes to the artefacts at either end of such a relation, or, sometimes, to the relation itself.

Other forms of change notification are more general and support other workflow besides those around trace relationships. For example, a change to a requirement could cause an email to be sent to the author of that requirement, or perhaps any party that has registered some interest in that requirement.

Notice that the notion of change is complex. Processes often require the notion of immutable artefacts, so that requirements are fixed (for example, for a release, or milestone, or product) at some known state. This state is the state against which qualification and implementation take place. Other processes are less rigorous, and accommodate changing requirements in a more agile style (but not necessarily as part of an agile process). Tool support for dealing with immutable artefacts varies, and is often inconsistent across lifecycle applications, so a common challenge is to prevent change happening, or to have mechanisms which allow change to be identified and communicated so that it can be reacted to.

Even in formal environments, some business-level changes may be expressed as a direct change to a requirement (or the creation of a new requirement). Often, such proposed changes will be captured in a requirements change request.

Scenario test engineer responds to change in requirement scope

Preconditions

1. A requirement collection C has been defined which specifies some need.
2. A test engineer is producing qualification assets which qualify the requirements in that collection
3. A need to remove a requirement from that collection has been identified and agreed.
4. The test engineer has been enrolled in notifications that are germane to changes in content or scope

Scenario

1. The requirement is removed from the collection
   1. ALTERNATIVE: requirement is added to the collection.
   2. ALTERNATIVE: requirement in the collection is modified.
2. The test engineer is notified of the change to the collection
   1. OPTION: The notification is an email.
   2. OPTION: The notification is a task (created and assigned to the test engineer). This task describes the nature of the change to which the test engineer must respond. The test engineer examines assigned tasks on a regular basis.
3. The test engineer analyses this change, and acts on it (for example, suspending or re-prioritizing work)
   1. OPTION: The task is completed.

Discussion

• OSLC should not be concerning itself with the internal behaviour of a system on receipt of a notification - what's interesting here is what the QM system must do with the RM resources in order that the RM system will allow enrollment in notifications.
• Are enrollments for users, or for systems, or does that not matter?

Postconditions

1. The requirement collection and the qualification assets are coherent
2. The qualification assets reflect the desired requirement scope

Scenario test engineer is enrolled in notifications

Modification to RmRequirementCompletedScenario scenario: As test engineer establishes traceability between QM assets and RM assets, the test engineer is enrolled in changes that affect the content and scope of the requirements, and thus typically are changes that need to be dealt with in the qualification assets.

Post conditions

1. Test engineer is enrolled in changes to the scope (adding/removing requirements) from the collection.
2. Test engineer is enrolled in changes to the content (changing requirements).

Discussion

• Not all changes are interesting - how does the QM system indicate which changes are worthy of notification?
• How to avoid "false positives" - many notifications which distract those enrolled in such notifications?
• Granularity of notification (For example, if tasks were being created, a profusion of them would be unsatisfactory.)