| | 32 | === 3.1 Stakeholder Summary === |
| | 33 | |
| | 34 | * [Name the stakeholder type.]: [Briefly describe the stakeholder.] |
| | 35 | * [Summarize the stakeholder’s key responsibilities with regard to the system being developed; that is, their interest as a stakeholder. For example, this stakeholder: ensures that the system will be maintainable, ensures that there will be a market demand for the product’s features, monitors the project’s progress, approves funding, and so forth] |
| | 36 | * ... |
| | 37 | * ... |
| | 38 | |
| | 39 | === 3.2 User Environment === |
| | 40 | |
| | 41 | [Detail the working environment of the target user. Here are some suggestions:\\ |
| | 42 | Number of people involved in completing the task? Is this changing?\\ |
| | 43 | How long is a task cycle? Amount of time spent in each activity? Is this changing?\\ |
| | 44 | Any unique environmental constraints: mobile, outdoors, in-flight, and so on?\\ |
| | 45 | Which system platforms are in use today? Future platforms?\\ |
| | 46 | What other applications are in use? Does your application need to integrate with them? |
| | 47 | This is where extracts from the Business Model could be included to outline the task and roles involved, and so on.] |
| | 48 | |
| | 49 | == 4. Product Overview == |
| | 50 | |
| | 51 | === 4.1 Needs and Features === |
| | 52 | |
| | 53 | [Avoid design. Keep feature descriptions at a general level. Focus on capabilities needed and why (not how) they should be implemented. Capture the stakeholder priority and planned release for each feature.] |
| | 54 | |
| | 55 | * Need: |
| | 56 | * Priority: |
| | 57 | * Features: |
| | 58 | * Planned Release: |
| | 59 | * ... |
| | 60 | * ... |
| | 61 | |
| | 62 | == 5. Other Product Requirements == |
| | 63 | |
| | 64 | [At a high level, list applicable standards, hardware, or platform requirements; performance requirements; and environmental requirements. |
| | 65 | Define the quality ranges for performance, robustness, fault tolerance, usability, and similar characteristics that are not captured in the Feature Set.\\ |
| | 66 | Note any design constraints, external constraints, assumptions or other dependencies that, if changed, will alter the Vision document. For example, an assumption may state that a specific operating system will be available for the hardware designated for the software product. If the operating system is not available, the Vision document will need to change. |
| | 67 | Define any specific documentation requirements, including user manuals, online help, installation, labeling, and packaging requirements. |
| | 68 | Define the priority of these other product requirements. Include, if useful, attributes such as stability, benefit, effort, and risk.] |
| | 69 | |
| | 70 | * Requirement: |
| | 71 | * Priority: |
| | 72 | * Planned Release: |
| | 73 | * ... |
| | 74 | * ... |
| | 75 | |
| | 76 | |
| | 77 | |
| | 78 | |
| | 79 | |
| | 80 | |
| | 81 | |
