|
|
|
|
|
|
|
|
| | |
|
|
|
|
|
2 Overall Description
From Web 2.0 Wiki, Wiegers Wiki Template
|
This section presents a high-level overview of the product and the environment in which it will be used, the anticipated product users, and known constraints, assumptions, and dependencies.
2.1 Product Perspective
Describe the product's context and origin. Is it the next member of a growing product family, the next version of a mature system, a replacement for an existing application, or an entirely new product? If this Software Requirements Specification (SRS) defines a component of a larger system, state how this software relates to the overall system and identify major interfaces between the two.
2.2 Product Features
List the major features the product contains or the significant functions that it performs. Details will be provided in Section 3 of the SRS, so you need only a high-level summary here. A picture of the major groups of requirements and how they are related, such as a top-level data flow diagram, a use-case diagram, or a class diagram, might be helpful.
2.3 User Classes And Characteristics
Identify the various user classes that you anticipate will use this product and describe their pertinent characteristics. Some requirements might pertain only to certain user classes. Identify the favored user classes. User classes represent a subset of the stakeholders described in the vision and scope document.
2.4 Operating Environment
Describe the environment in which the software will operate, including the hardware platform, the operating systems and versions, and the geographical locations of users, servers, and databases. List any other software components or applications with which the system must peacefully coexist. The vision and scope document might contain some of this information at a high level.
2.5 Design And Implementation Constraints
Describe any factors that will restrict the options available to the developers and the rationale for each constraint. Constraints might include the following:
* Specific technologies, tools, programming languages, and databases that must be used or avoided.
* Restrictions because of the product's operating environment, such as the types and versions of Web browsers that will be used.
* Required development conventions or standards. (For instance, if the customer's organization will be maintaining the software, the organization might specify design notations and coding standards that a subcontractor must follow.)
* Backward compatibility with earlier products.
* Limitations imposed by business rules (which are documented elsewhere, as discussed in Chapter 9).
* Hardware limitations such as timing requirements, memory or processor restrictions, size, weight, materials, or cost.
* Existing user interface conventions to be followed when enhancing an existing product.
* Standard data interchange formats such as XML.
2.6 User Documentation
List the user documentation components that will be delivered along with the executable software. These could include user manuals, online help, and tutorials. Identify any required documentation delivery formats, standards, or tools.
2.7 Assumptions And Dependencies
An assumption is a statement that is believed to be true in the absence of proof or definitive knowledge. Problems can arise if assumptions are incorrect, are not shared, or change, so certain assumptions will translate into project risks. One SRS reader might assume that the product will conform to a particular user interface convention, whereas another assumes something different. A developer might assume that a certain set of functions will be custom-written for this application, but the analyst assumes that they will be reused from a previous project, and the project manager expects to procure a commercial function library.
Identify any dependencies the project has on external factors outside its control, such as the release date of the next version of an operating system or the issuing of an industry standard. If you expect to integrate into the system some components that another project is developing, you depend upon that project to supply the correctly operating components on schedule. If these dependencies are already documented elsewhere, such as in the project plan, refer to those other documents here.
|
|
|
| |
| | |
|
|
|
|
|
|
|
|
|
|
|
|
|