- Project background
- Purpose of project
Every stakeholder and user has a reason that the software should be developed. This section should contain a summary of each of those reasons. The goal is to give the reader an understanding of why these people need the system to be developed.
- Scope of project
The version and scope document described the scope of the software to be developed by listing each feature that would be included. This section should go into greater detail, elaborating on each feature by listing specific behaviors and tasks the software will perform.
- Other background information
This section should contain any additional information that may help a reader understand why the system is needed.
- Perspectives
This section is used to identify the people who will help define the behavior of the software. Each persion's perspective should be taken into account.
- Who will use the system
- Who can provide input about the system
- Project objectives
This section summaries the information that was gathered in the elicitation phase, such as the functionality that the software must implement, the work currently being down or planned in the organization that will be affected or argumented by the software, and any constraints that must be taken into account.
- Known business rules
This section should contain details of any procedures that are currently being performed or that are needed in the organization and that will affect the software. The section should indicate who is involved or will be affected.
- System information and/or diagrams
This section should conatin a summary of any notes taht describe functionality that must be implemented, existing or planned organizational workflow, specific user interactions, information about the environment in which the software will be used, calculations that must be perform, and any other functionality that must be implemented. This will probably be the longest section in the discussion summary.
- Assumptions and dependencies
During elicitation meetings, may assumptions and dependencies will be brought up, They should be summarized in this section. Many of these assumptions may already be in the version and scope document, or in the results of Wideband Delphi estimation session; it is often sufflicient to reference that document, rather than reproduce them in the dicussion summary.
- Design and implementation constraints
Many times there are constraints that must be placed on the software: known input or output data formats; tools; code libraries, visual controls, programming languages, or APIs that must be used; visual or GUI design standards that must be adhered to; and performance or quality requirements and other known nonfunctional requirements, These should be listed in this section in detail.
- Risks
- Known future ehancements
- References
- Open, unresolved, ot TBD issues
posted on 2009-09-17 17:34
Lei Yong 阅读(72)
评论(0) 编辑 收藏