Problem Definition Proposal
From ZenWiki
Contents |
Purpose
This proposal describes the requirement elicitation methods employed by Team Zen on the SEI Studio Project. It will describe the following:
- Processes used to elicit requirements
- Processes used to maintain requirements
- Processes used to change requirements
- Methods used to analyze the effectiveness of each process described
This document will be revised throughout the semester as methods are tried and evaluated.
Point of Contact
This document is maintained by Sajjad Mustehsan. All related correspondence can be directed to sajjad <at> cmu <dot> edu. For Fall 2006 semester, it was maintained by Marc Novakouski (mnovakou@andrew.cmu.edu).
Client Overview
The primary customer for this project, Grace Lewis, is located at an extremely advantageous location, at the SEI in Pittsburgh. She is an MSE mentor and has a great deal of familiarity with the MSE program. She has made herself very available to the team. As such, the processes defined in this document will take into account her unique knowledge base and availability. If the situation changes, this document may be updated to reflect any appropriate changes in processes used.
Process Proposal
Process 1: Gathering Requirements
Process
The following methods will be used in gathering requirements:
- Client Interviews
- Business Drivers Discussion
- QAW
- Problem Frames abstracted to Context Diagrams
- Contextual Interview (if possible)
- Use Cases
- Design Decisions
- Architecture Feedback
- Requirements Feedback
- Prototyping/Experiments
This list may be expanded to include additional techniques as needed.
Analysis
Method Analysis
For each method used, the following data points will be created:
- How many requirements were elicited from using this technique?
- What was the design level of the requirements that were discovered? (high vs. med vs. low level)
- What was the priority of the requirements that were discovered?
- Was it easy for the team to use this technique? Was it easy for the client to engage in the use of this technique?
- Based on the team’s understanding of the technique, would it have been better used at a different point in the project lifecycle? What phase would be ideal? Why? What phase would be worst? Why?
- From a qualitative, "gut feeling" type standpoint, how effective was it to use this method? Why?
This list may be expanded to include additional measures of analysis as needed.
Initial data points for each method will be captured by the end of each iteration in which the method is employed. As the project progresses, the information pertaining to each technique may be updated as understanding increases.
Stability Analysis
We also wish to examine the stability of the requirements that are captured. To do so, the SRS will include a revision history which captures every change made to the SRS. To analyze the stability of the requirements, we will count how many times each individual requirement changed (not including their initial addition to the SRS) and take the average of the number of changes. We will do this on both an iteration basis and a overall project basis. This approach should be able to show how stable requirements are in an individual semester and also how stable they are over the course of the project.
Maintenance
The data points captured for each method will be maintained on the wiki.
Process 2: Maintaining Requirements
Process
All requirements discovered by the various elicitation techniques will be documented within 1 week. This allows time for follow-up questions, as well as slack for dealing with non-Studio tasks.
All requirements will be documented within a Systems Requirements Specification (SRS). The SRS will be set up as a table or database. The first data set within the SRS will define the requirements. This table will be set up with each element having the following attributes:
- Category: The functionality to which the requirement pertains. As requirements decompose, further level of decomposition will be reflected in this attribute.
- Example: a high level requirement could have this attribute as “Category X,” and a decomposed requirement of that requirement could have this attribute as “Category X: Subcategory A.”
- Requirement: Each requirement will be assigned a unique number which associates its functionality with its category.
- Example: a high level requirement could be 4-1, where this indicates Category 4, requirement 1.
- Example: a low level requirement could be 4.1.2-3, where this indicates Category 4, Subcategory 1, Subsection 2, requirement 3.
- Description: Each requirement will have text associated with it describing what the requirement is.
- Example: The ZEN tool shall provide the user with the ability to select an answer to the current question.
- Qualifications/Comments: Each requirement will have space for additional comments or qualifications.
- Example: When running as a server, the ZEN tool will be referred to as a "ZEN server"
- Required: Each requirement will be marked with either “Y” or “N” for the required attribute. A “Y” means that the requirement is currently required for the final delivery. An “N” means the requirement is currently not required for the final delivery.
- Elicitation Method: Each requirement will be logged with the method it was elicited by. (Note: more will be added as the project goes on.) At this time, they are:
- Design Decision: This requirement was elicited by the Zen team via a design decision based upon customer requirements. It represents a design or architecture decision made to support customer needs.
- Problem Frames: This requirement was elicited via the use of Problem Frames.
- Interview: This requirement was elicited via a direct interview with the client, i.e. face-to-face or email communication.
- QAW: This requirement was elicited via a Quality Attribute Workshop.
- Business Drivers: This requirement was elicited via use of the Business Drivers template.
- Architecture Feedback: This requirement was elicited via presenting an architecture mockup to the client and eliciting feedback.
- Priority: Each requirement will be associated with a “High,” “Medium,” or “Low” priority which indicates which requirements are most important to make the project successful.
- Requires Further Decomposition: Each requirement will be marked as “Y” or “N” for this attribute. A “Y” means that this requirement needs to be further decomposed to fully specify the solution. An “N” means that this requirement is sufficient to drive either design or code decisions.
- Quality Attribute(s): Each requirement can be associated with a quality attribute as specified by the Quality Attribute Scenarios.
Please Note: The above table will be revised throughout the project lifetime.
When using an Excel spreadsheet, the SRS shall separate the major functionality categories by inserting a black line between them. For example, between the last requirement which begins with 2-x or 2.x, and the first requirement that begins with 3-x or 3.x, an additional space will be inserted to add to readability.
The second data set within the SRS will be for the Quality Attributes. The Quality Attributes will be logged in a scenario manner with all of the information captured from the QAW logged. A Quality Attribute Tree will be maintained as well.
The final data set within the SRS will be for revision history. This data set will contain the following attributes:
- Revision Number
- Date of Revision
- List of Requirements affected by the revision
- Summary of the revision/reasons for the revision
The SRS will be maintained at this time as a simple excel spreadsheet. If excel proves to be an inappropriate tool for requirements maintenance, a more appropriate tool will be identified and used. The process of identifying a more appropriate tool will be defined only if we choose to perform that process.
The content and structure of the SRS may be modified as needed by the team.
At the end of each iteration, the SRS will be reviewed for the following purposes:
- Adding any requirements that were not documented
- Improving the ease of finding requirements (if possible)
- Improving the clarity of the allocation/sorting
- Matching the current allocation/sorting to the current understanding of the project architecture
- Identifying any other problems with the SRS and taking as action items to be resolved on a timetable determined by the current requirements engineer
The SRS will be maintained either locally in documents or on the wiki.
Analysis
To analyze the effectiveness of maintaining requirements, the following methods will be used:
- Documenting how many changes were made, and of what type, at the SRS review at the end of each iteration
- Documenting any problems left unresolved, and the reasons for the lack of resolution, at the SRS review
Process 3: Changing Requirements
Process
The requirement change process will be based upon the 3 semester lifetime of the project.
Semester 1
During the first semester (September 2006-December 2006) the ZEN team will accept any requirements proposed by the client. Any changes, additions, or deletions will be reflected in the SRS within 1 week with no further action needed.
Semester 2
During the second semester (January 2007-May 2007) the ZEN team will require submission of a change request to the SRS in order to change or add any requirements estimated by the team to require more than 40 hours of work. This change request may require a reduction in scope; this will be decided upon by the team and the client. The change request must be informally agreed upon by the client and the ZEN team. This informal agreement may be documented within email.
Semester 3
During the third semester (June 2007-August 2007) the ZEN will require submission of a change request to the SRS in order to change or add any requirements estimated by the team to require more than 16 hours of work. The change request in most cases will require a reduction in scope to accommodate the requested change. The request must be signed by the client and the team to confirm acceptance to any schedule or scope impact.
Non-Impacting requirements
Any additions, deletions, or changes not covered by the above plan will be added directly to the SRS with no further action needed.
Analysis
To analyze the effectiveness of this method of handling change, the following methods will be used:
- Documenting how many change requests are accepted per semester.
- Documenting how many change requests are denied per semester.
- Documenting how many changes are made in the 2nd and 3rd semester without change requests.
Process 4: Tripwire Events
Process
Certain events may impact the project to such an extent that the scope of the project will have to be reevaluated. These events are termed “tripwire events”. If any of these events happen, the scope of the project will be required to be reworked via changing the SRS.
Tripwire Events
- Loss of a team member. If a member of the Zen team is removed from the team for any reason, the project scope must be reconsidered.
- Excessive unavailability of a team member. If a member of the Zen team is unavailable due to other commitments or sickness or any other reason for more than 3 weeks (first semester), 2 weeks (second semester), or 1 week (third semester) then the project scope must be reconsidered.
- Change in client representative. If the primary client representative is replaced at any time during the second or third semester, the project scope must be reconsidered.
- Excessive unavailability of any client input. If no client representative is available, in any way, for more than 3 weeks during any time of the project lifecycle, the project scope must be reconsidered.
Analysis
Analysis of a tripwire event mitigation process will occur at the end of any iteration in which a tripwire event occurred. If no tripwire events occur during a semester, the team will evaluate at the end of the semester if the process should be changed or if it reflects appropriately the needs of the team.
Reflection
Reflection on the effectiveness of these processes will be performed at the beginning of each iteration.
Reflections on Problem Definition
