Requirements Engineering Process
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.
Control and ensure quality of requirements elicitation,analysis and administration during the project.
Contents |
Approach
What are we trying to avoid. Background
- Major projects failed because of:
- Not customer involvement
- Assuming to understand the problem
- Lack of Contextual info
- Incomplete Requirements
Techniques
- Use Cases
- Interviews:
- Brainstorming:
- Weight Matrix for technique
STEP1 - Preparation Requirements Engineering
Input:
Tasks:
- Make a road map.
- Plan for requirements activities.
- Agree on resources, process, and schedule for Requirements activities.
- Resources/stake holder availability.
- Obtain and organize the agreed upon resources and process.
- Select Elicitation Techniques.
- Fill time tracking.
- Fill identified Risks
Output: Plan with estimations each phase.
STEP2 - Problem/ High Level Requirements
Entry: Existing customer documentation, plan
Tasks:
- Gather existing information (documents, teams head).
- Create Glossary, business/technical terms.
- Create Problem, Vision, and Contextual Information.
- Constrains
- Create HighLevel Requiremnts document
- Caterorize and Prioritize HighLevel Requirements
- Gather Quality Attributes Information
- Adjust plan. If necessary
- Fill identified Risks
- Fill time tracking.
Validation:
- Answer the problem questionare
- Client Evaluation.
- Use the check list validate.
- Client Evaluation
Output:
- Refined Problem
- Vision
- Glossary
- Refined High Level Requirement Document
- Traceability matrix
STEP3 -Detail Requirements
Entry: Highlevel Requirement Document
Tasks:
- Functional requirements
- Detail Use Case
- Quality attributes. (Extensibity, maintaniabilty)
- Usability and User Design Requirements.
- Adjust plan. If necessary
Validation:
Output: Detailed Requirement, Traceability (High Level vs. Detail Level)
STEP4 - Detail Requirements
Input: Tasks Post mortem
- Identify process improvements opportunities
After Change Request Process:
Considerations:
- Iterative
- We can go back to previous steps
The following roadmap will be followed.
Roles
- Requirements Engineer
- Quality Assurance
- Stakeholder
Metrics and Data
Metrics:
- Time by Phase:
- Correction in verification faces Phase:
- Face to face customer hrs:
- Customer line customer hrs:
- Requirements creation by date:
- Requirements changes:(Version)
Analysis and Reflection
This process was intended to help the Square Root team specify detailed requirements through use cases. The idea was that we would complete one SQUARE step, specifying it at the lowest level possible, before moving on to specify the next step. Since there is no constraint precluding us from addressing SQUARE steps in parallel we chose to chunk groups of steps together for the sake of creating some kind of plan. The use cases project in Methods class jump started the planned road map by forcing the team to specify several use cases in a short amount of time; however once the project was completed, addressing specific use cases in greater detail became problematic. The problems can be attributed to the following:
- Waiting for answers to questions from the client blocked the completion of other use cases.
- Other studio tasks such as proposals and presentations took more immediate precedence.
- Not enough was known about some use cases to continue pursuing them, further research or experimentation is required.
- All of these factors combined with a largely sequential strategy created a situation where no work was moving forward.
Examining the actual tasking and milestone data collected and comparing it with the planned completion times exposed the issue. The first step outlined in this process had been carried over for two complete iterations (iterations Fall2008.2 and Fall2008.3) with no progress made other than the initial work done for the Methods project. To make matters worse a number of use cases outside of the steps and previously specified cases had been identified but little to no work was completed on them. If the team was to complete the Inception Phase by the end of the fall semester, as planned, this issue would need to be resolved.
An adjustment was made for iteration Fall2008.4. This process was officially retired in favor of a more lean, parallel approach that better complemented the team's working style, knowledge of the project, and most importantly the needs at this time. Highly specific, low level use cases were not required to complete the Inception Phase. Only a broad understanding of scope so that a reasonable architecture could be created and better estimations could be made was needed.
This new strategy should cut horizontally across all use cases, ensuring they meet a minimum level of detail required at this stage of the project. This strategy is officially retired November 14, 2008. Please see Requirements Engineering (Inception) for the new process.
References
- Tsui & Karam - Software Engineering
- Pressman
- Methods Requirements Engineering Paper
- Contextual Design
- Mentors of Faculty