Problem Definition Proposal

From DaVinci

Contents 1 Purpose 2 Context 3 Techniques 3.1 Feature brainstorming 3.2 Use cases 3.3 Prototyping 3.4 Quality Attribute Workshop 4 Tailoring 5 Reflection 6 References

Purpose

Team DaVinci will use this document to help make decisions that define the team’s baseline process for the following tasks regarding our customer’s problem.

• Problem understanding.
• Requirement elicitation.
• Requirement codification.
• Validation of the codification of the requirements.

We will base future decisions regarding the tailoring of this process upon this definition and capture our decisions in this document. We will also use this document as input into reflections on our methods for defining our customer’s problem and our thinking behind our decisions. We will capture reflections based on this proposal on our Reflections: Problem Definition Proposal wiki page.

Context

Team DaVinci has been tasked with implementing additions to the Software Engineering Institute’s (SEI) OSATE tool to facilitate modeling of embedded systems in the Society of Automotive Engineer’s (SAE) Architectural Analysis and Design Language (AADL). These additions to the tool will be in the form of eclipse plug-ins and modifications to the existing tool, which is itself implemented as an eclipse plug-in. The additions to OSATE will provide users with the ability to

• Refactor AADL models using wizards.
• Transform AADL models into models of other types based on pre-defined rules.
• Define further sets of rules for transformation of AADL models to previously unsupported model types.
• Run model optimization algorithms on AADL models.

Techniques

This section lists the techniques we will use and our reasoning for using them.

Feature brainstorming

Feature brainstorming involves informal workshops used to determine what the product being developed will do. The output of these workshops is a prioritized list of product features. We will gather our initial list of high-level features, as well as more detailed features, using this technique. It is a quick way to get insight into what the customer believes they need and gives our team a place to start. The features captured using this technique will be added to our product backlog for prioritization and to drive development tasks. The first version of our product backlog, containing only high-level features, will be complete prior to our first Scrum sprint planning meeting scheduled for November 9th, 2005. A feature brainstorming session to determine and document detailed features will be held during sprint 3 or 4, depending on task prioritization activities for those sprints. The backlog is tentatively scheduled to be updated with detailed requirements by the end of February, 2006. The product backlog will be updated based on short feature brainstorming sessions during planning meetings with the customer at the beginning of each sprint.

Use cases

As part of our MSE Methods course, we created some initial use case diagrams and scenarios for our project. This technique allowed the group to reach a common understanding of the problem. The results of the initial use of this technique will feed into future efforts to understand our customer's problem. Because of the usefulness of this technique to elicit, document, and understand our customer's problem, and the correlation between use cases and Scrum "Features," we will continue to use this technique. We will generate use case diagrams and scenarios[1] to determine the goals of OSATE users and to document the tasks needed to support these goals. This will enable us to elicit and codify OSATE requirements. These diagrams and scenarios will be reviewed with the customer for validation prior to implementing the features to which the scenarios are related. They will also serve to validate the team's understanding of the problem OSATE is trying to solve, help ensure a common understanding of the problem among the team, and guide our team in the implementation of features. The use case diagrams and scenarios will be captured on our Use Cases wiki page. We plan to have the first version of the use cases and scenarios published by the end of sprint 4, tentatively scheduled to end in late February, 2006.

Prototyping

We will construct prototypes of varying levels of fidelity (from paper to evolutionary) based on the problem understanding at the time of construction and use them to elicit additional requirements and increase understanding. The use of prototypes will be determined as they are needed, and we will select the appropriate type during the planning for the iteration in which they will be created. We will create prototypes to investigate and answer specific questions. The results from prototypes will be captured on our wiki and links to pages containing these results can be found in the "Experiments & Prototypes" section of our wiki's Main Page.

Quality Attribute Workshop

We will use a quality attribute workshop (QAW) to determine if there are any quality attributes that need to be addressed, and to codify the quality attributes in a way that they can be measured. We plan to hold the QAW in the March, 2006, timeframe. The actual date is dependent on team member, customer, and QAW expert availability. The results of the QAW will be captured on our Quality Attribute Scenarios page of our wiki.

Tailoring

If we modify the above listed techniques, we will capture the modifications here.

Reflection

As a team, we will reflect upon our use of the techniques listed above at the end of each sprint in which they are used, and at the end of every semester. We will capture our reflections on our Reflections: Problem Definition Proposal wiki page.

We will ask ourselves the following questions, among others that are determined as the project progresses.

1. Does an initial feature brainstorming of high-level features help to get the project started? Should detailed features also be brainstormed at the outset of the project?
2. What is the correlation between use cases and Scrum features?
3. For our project, are use cases, QAWs, and feature brainstorming sufficient for capturing and documenting our customer's problem? Why?
4. If use cases, QAWs, and feature brainstorming are not sufficient for our project, how should our approach be modified?
5. What methods for prototyping proved to be most beneficial for the time spent creating the prototype?

Question 1 will be addressed at the end of the first semester, by December 16th, 2005, and will be revisited once detailed feature brainstorming occurs in semester 2. The remainder of the questions will be addressed during our third semester (summer 2006).

References

[1] Schneider, Geri and Jason P. Winters. “Applying Use Cases: A Practical Guide.” Reading, MA: Addison Wesley Longman, 1998.