IEEE 1233-1998 pdf download IEEE Guide for Developing System Requirements Specifications
1. Overview
11 Scope
This guide provides guidance for the development of a set of requirements that, when realized, will satisfyan expressed need. In this guide that set of requirements will be called the System Requirements Specification (SyRS). Developing an SyRS includes the identification, organization, presentation, and modification ofthe requirements. This guide addresses conditions for incorporating operational concepts, design constraints.and design configuration requirements into the specification. This guide also addresses the necessary charac.teristics and qualities of individual requirements and the set of all requirements.
This guide does not specify industry-wide system specification standards nor state a mandatory SystemRequirements Specification. This guide is written under the premise that the current state of the art of systemdevelopment does not warrant or support a formal standards document.
2. References
This guide shall be used in conjunction with the following publications:IEEE Std 100-1996, IEEE Standard Dictionary of Electrical and Electronics Terms.IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans.IEEE Std 828-1998,IEEE Standard for Software Configuration Management Plans.IEEE Std 830-1998,IEEE Recommended Practice for Software Requirements Specifications.IEEE Std 1074-1997,IEEE Standard for Developing Software Life Cycle Processes.
ISO 9126:1991Information technologySoftware product evaluation-Quality characteristics and guide-lines for their use.
MIL-STD-490A,Specification Practices.
MIL-STD-498,Software Development and Documentation.
3.Definitions
The definitions listed below establish meaning in the context of this guide. Terms not defined in this guideare included in IEEE Std 610.12-1990.4
3.1 analyst: A member of the technical community (such as a systems engineer or business analyst, developing the system requirements) who is skilled and trained to define problems and to analyze, develop. andexpress algorithms.
3.2 annotation: Further documentation accompanying a requirement such as background information and)or descriptive material.
3.3 baseline: A specification or system that has been formally reviewed and agreed upon, that thereafterserves as the basis for further development and can be changed only through formal change control proce-dures.(IEEE Std 610.12-1990)
3.4 constraint: A statement that expresses measurable bounds for an element or function of the system. Thatis, a constraint is a factor that is imposed on the solution by force or compulsion and may limit or modify thedesign changes.
3.5 customer(s): The entity or entities for whom the requirements are to be satisfied in the system beingdefined and developed. This can be an end-user of the completed system, an organization within the samecompany as the developing organization (e.g., System Management), a company or entity external to thedeveloping company, or some combination of all of these. This is the entity to whom the system developetmust provide proof that the system developed satisfies the system requirements specified.
3.6 derived requirement: A requirement deduced or inferred from the collection and organization ofrequirements into a particular system configuration and solution.
3.7 element: A component of a system; may include equipment, a computer program, or a human.
3.8 end user: The person or persons who will ultimately be using the system for its intended purpose.
IEEE 1233-1998 pdf download
PS:Thank you for your support!
