IEEE Std 830:1998 pdf free download

IEEE Std 830:1998 pdf free download.IEEE Recommended Practice for Software Requirements Specifications.
An SRS is an important part of the requirements process of the software life cycle and is used in design. implementation. project monitoring, verification and validation, and in training as described in lElil Std 1074-1997. The SRS should he unambiguous both to those who create it and to those who use it. However, these groups often do not have the same background and therefore do not tend to describe software requirements the same way. Representations that improve the requirements specification for the developer may be counterproductive in that they diminish understanding to the user and vice versa.
Subclauses 4.3.2.1 through 4.3.2.3 recommend how to avoid ambiguity.
4.3.2.1 Natural language pitfalls
Requirements are often written in natural language (e.g.. English). Natural language is inherently ambiguous. A natural language SRS should be reviewed by an independent party to identify ambiguous use of language so that it can be corrected.
4.3.2.2 Requirements specification languages
One way to avoid the ambiguity inherent in natural language is to write the SRS in a particular requirements specification language. Its language processors automatically detect many lexical, syntactic, and semantic errors.
One disadvantage in the use of such languages is the length of time required to learn them. Also, many iiontechnical users find them unintelligible. Moreover, these languages tend to be better at expressing certain types of requirements and addressing certain types of systems. Thus, they may influence the requirements in subtle ways.
4.3.2.3 Representation tools
In general. requirements methods and languages and the tools that support them fall into three general categories—object. process. and behavioral. Object-oriented approaches organize the requirements in terms of real-world objects, their attributes. and the services performed by those objects, Process-based approaches organize the requirements into hierarchies of functions that communicate via data flows. Behavioral approaches describe external behavior of the system in terms of some abstract notion (such as predicate calculus), mathematical functions, or state machines.
The degree to which such tools and methods may be useful in preparing an SRS depends upon the size and complexity of the program. No attempt is made here to describe or endorse any particular tool.
When using any of these approaches it is best to retain the natural language descriptions. That way. customers unfamiliar with the notations can still understand the SRS.
4.3.3 Complete
An SRS is complete if. and only if, it includes the following elements:
a) All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements imposed by a system specification should be acknowledged and treated.