Changing the way you learn

Standard IEEE830-1998

CONSIDERATIONS FOR PRODUCING A GOOD SRS
1. Nature of the SRS
  1. The SRS writer(s) should avoid placing either design or project requirements in the SRS
    1. Functionality
    2. External interfaces
    3. Performance
    4. Attributes
    5. Design constraints
2. Environment of the SRS
  1. 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
    1. 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.
    2. B) Should not describe any design or implementation details. This should be described in the design stage of the project.
    3. C) Should not impose additional constraints on the software. These are properly specified in other documents such as a software quality assurance plan.
4. 1. The SRS writer(s) should clearly distinguish between identifying required design constraints and projecting a specific design
THE PARTS OF AN SRS
1. Overall description
  1. This section of the SRS should describe the general factors that affect the product and its requirements.
    1. C) User characteristics
    2. D) Constraints
    3. E) Assumptions and dependencies;
    4. B) Product functions
    5. A) Product perspective
    6. F) Apportioning of requirements
2. Specific requirements (Section 3 of the SRS)
  1. 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.
    1. A) Specific requirements should be stated in conformance with all the characteristics described in 4.3.
    2. B) Specific requirements should be cross-referenced to earlier documents that relate.
    3. C) All requirements should be uniquely identifiable.
    4. D) areful attention should be given to organizing the requirements to maximize readability.
3. Supporting information
  1. The supporting information makes the SRS easier to use. It includes the following:
    1. Table of contents
      1. The table of contents and index are quite important and should follow general compositional practices.
    2. Index
    3. Appendixes
      1. 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.
4. Introduction

Next up

Standard IEEE830-1998

Description

Resource summary

Similar

	Created by Ernesto Cach Gonzalez almost 5 years ago