.: Discovery / Requirements
This is the process of discovering the real needs which the new software must meet. The "need" is already understood at some level, of course, because that’s the force that gets the project started. But to be successful, the real needs must be understood in some detail, and implicit assumptions about these needs must be investigated.
A requirements document usually includes the following kinds of information:
- Who are the users? What are their roles and responsibilities? What information or functionality must the system provide in support of the users’ fulfilling their responsibilities?
- What specific usage scenarios (use cases) are envisioned? In support of each scenario what information must be supplied to the software? How does the information and functionality produced by the system relate to each of these scenarios?
- Is the above related to existing business practices? Are we seeking to streamline or improve existing business practices?
- Temporarily setting aside all practical issues, what would be the purely “ideal” picture of business practices, usage scenarios, system behavior and outputs you can envision?
- How much of the “ideal” can be put into practice? What are the approximate ratios of cost and benefit?
- What specific levels of performance are required?
- How will the software be maintained after it is completed? Will business conditions dictate frequent changes and enhancements or will the system remain relatively static? Will future responsibility for the system be in-house or contracted out?
- What types of user support will be needed? Is extensive context-sensitive online help required? Should there be a user manual? What is the expected complexity of user support? Does the system need to provide extensive information about what a user is doing in order for them to be supported?
- How are cost and benefit to be evaluated? What are the guidelines to be used for exploring the benefits of various elements of the “ideal” in relation to their expected cost?
- What kinds of extra flexibility or “over-generalization”—not needed now—should be built-in so future enhancements will be more economical?
- List the specific outputs (reports, screen-based information, exported data, data feeds to other systems) which must be produced.
- List the specific sources of information need to support the creation of the outputs mentioned above (imports, data feeds from other systems, user-inputs, etc.
Discovery / Requirements
Problem Domain
Risks
Architecture
External Design
Functional Design
Implementation
Quality Assurance
|
