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.
   • Characteristics of a good SRS
     • Correct
       • The SRS should be compared with any applicable superior specification, such as a system requirements specification, with other project documentation, and with other applicable standards, to ensure that it agrees.
     • Unambiguous
       • Requirements specification languages
       • Representation tools
       • Natural language pitfalls
     • Modifiable
       • An SRS is modifiable if, and only if, its structure and style are such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style.
         • b) Not be redundant (i.e., the same requirement should not appear in more than one place in the SRS)
         • a) Have a coherent and easy-to-use organization with a table of contents, an index, and explicit cross-referencing
         • c) Express each requirement separately, rather than intermixed with other requirements
     • Complete
       • a) All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces.
       • c) Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure.
       • b) Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations.
     • Verifiable
       • A requirement is verifiable if, and only if, there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement.
     • Consistent
       • Consistency refers to internal consistency. If an SRS does not agree with some higher-level document, such as a system requirements specification, then it is not correct
     • Ranked for importance and/or stability
       • Degree of stability
       • Degree of necessity
         • a) Essential. Implies that the software will not be acceptable unless these requirements are provided in an agreed manner.
         • b) Conditional. Implies that these are requirements that would enhance the software product, but would not make it unacceptable if they are absent.
         • c) Optional. Implies a class of functions that may or may not be worthwhile. This gives the supplier the opportunity to propose something that exceeds the SRS.
     • Traceable
       • An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation.
         • a) Backward traceability (i.e., to previous stages of development). This depends upon each requirement explicitly referencing its source in earlier documents.
         • b) Forward traceability (i.e., to all documents spawned by the SRS). This depends upon each requirement in the SRS having a unique name or reference number.
   • SRS evolution
     • The SRS may need to evolve as the development of the software product progresses. It may be impossible to specify some details at the time the project is initiated
       • A formal change process should be initiated to identify, control, track, and report projected changes
       • Requirements should be specified as completely and thoroughly as is known at the time, even if evolutionary revisions can be foreseen as inevitable
   • Prototyping
     • A prototype should be used as a way to elicit software requirements. Some characteristics such as screen or report formats can be extracted directly from the prototype. Other requirements can be inferred by running experiments with the prototype.
   • Embedding project requirements in the SRS
     • The SRS should not normally Specify design elements such as the following :
       • A) Partitioning the software into modules
       • B) Assignment of functions to the modules
       • C) Describe the flow of information or control between modules
       • D) Choice of data structures.
       • Some elements between client - software provider should not be included in the SRS.
         • d) Software development methods
         • c) Denunciation procedures
         • e) Quality assurance
         • a) Cost
         • b) Delivery schedules
         • f) Validation and verification criteria
         • g) Acceptance procedures.
   • Embedding design in the SRS
     • 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
     • The introduction of the SRS should provide an overview of the entire SRS. It must contain the following subsections
       • References
       • Definition, acronyms and abbrevations
       • Reach
       • Porpuses
       • Overview