Standard IEEE830-1998

Standard IEEE830-1998

1. CONSIDERATIONS FOR PRODUCING A GOOD SRS

   • Nature of the SRS
     • The SRS writer(s) should avoid placing either design or project requirements in the SRS
       • Functionality
       • External interfaces
       • Performance
       • Attributes
       • Design constraints
   • Environment of the SRS
     • IEEE Std 610.12-1999 defines the part that the SRS plays in the total project plan. Since the SRS has a specific role to play in the software development process, the SRS writer(s) should be careful not to go beyond of that role. This means the SRS
       • A) Should correctly define all of the software requirements. A software requirement may exist because of the nature of the task to be solved or because of a special characteristic of the project.
       • B) Should not describe any design or implementation details. This should be described in the design stage of the project.
       • C) Should not impose additional constraints on the software. These are properly specified in other documents such as a software quality assurance plan.
   • • The SRS writer(s) should clearly distinguish between identifying required design constraints and projecting a specific design

2. THE PARTS OF AN SRS

   • Overall description
     • This section of the SRS should describe the general factors that affect the product and its requirements.
       • C) User characteristics
       • D) Constraints
       • E) Assumptions and dependencies;
       • B) Product functions
       • A) Product perspective
       • F) Apportioning of requirements
   • Specific requirements (Section 3 of the SRS)
     • This section of the SRS should contain all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.
       • A) Specific requirements should be stated in conformance with all the characteristics described in 4.3.
       • B) Specific requirements should be cross-referenced to earlier documents that relate.
       • C) All requirements should be uniquely identifiable.
       • D) areful attention should be given to organizing the requirements to maximize readability.
   • Supporting information
     • The supporting information makes the SRS easier to use. It includes the following:
       • Table of contents
         • The table of contents and index are quite important and should follow general compositional practices.
       • Index
       • Appendixes
         • The appendixes are not always considered part of the actual SRS and are not always necessary. They may include
           • a) Sample input/output formats, descriptions of cost analysis studies, or results of user surveys;
           • b) Supporting or background information that can help the readers of the SRS;
           • c) A description of the problems to be solved by the software
           • Special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements.
   • Introduction