Requirements Engineering (Inception)
From Square Root
This process has served it's useful life. It's not a bad thing, it just means we don't need this process anymore.
Read the reflection section for more information.
This process realigns the team's original Requirements Engineering Process to be more inline with our Inception goals. We are shifting from a depth to breadth approach to ensure we have a good idea of total project scope rather than concentrating on creating perfect requirements one at a time.
Contents |
Approach
So far the team has identified and specified many requirements in the form of use cases. But many still have open questions or are only partially specified.
- Identify use cases that need to be define, updated, or finished. Assign an implementer.
- The implementer creates, updates, or finishes the use case according to the Use Case Review Checklist. All use cases are to be recorded in the wiki. The use case is then passed on to a reviewer.
- The reviewer reads the use case and judges it in terms of the Use Case Review Checklist. Problems should be recorded in the Use Case's "discussion" page in the wiki. If there are problems, email the implementer for corrections. Otherwise mark the use case as complete on the Use Case Checklist.
The general idea is that we want to capture requirements in such a way that they are good enough for us to move forward with the next phase of development.
Roles
- Requirements Manager - Manage the use case work assignments and ensure everything is completed on time.
Metrics and Data
At this time we are only interested in knowing whether we have sufficient coverage at a sufficient level of quality to move to the next phase of development. The metrics we calculate should help us determine if we have met this goal.
Use Case Checklist
This data is collected on an ongoing basis as the use cases are completed. This is simply status check on the use case, whether it's been finished, if it's under review, or whether it is completed.
Time per Use Case
This data is collected in the individual task tracking spreadsheets for the person who did the work.
Analysis and Reflection
This process worked as planned. The use of a checklist to show the current status of use cases was effective in both motivating the team and communicating what still needed to be done.
The quality checklist worked but much was left up to interpretation when considering whether something satisfied the checklist item. This meant that some reviewers were more detail and quality oriented than others. More specific review checklist items in addition to a use case exemplar might help resolve this issue.