1: 2013-07-14 (日) 15:58:20 FujitaYutaka |
2: 2013-07-14 (日) 16:24:15 FujitaYutaka |
| * 無あいまい性 [#j3ebaca1] | | * 無あいまい性 [#j3ebaca1] |
| ** 参考定義 [#ld57da5a] | | ** 参考定義 [#ld57da5a] |
- | *** IEEE 830 [#rc658872] | + | *** IEEE 830 (Unambiguous) [#rc658872] |
| An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. As a | | An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. As a |
| minimum, this requires that each characteristic of the final product be described using a single unique term. | | minimum, this requires that each characteristic of the final product be described using a single unique term. |
| + | |
| In cases where a term used in a particular context could have multiple meanings, the term should be included | | In cases where a term used in a particular context could have multiple meanings, the term should be included |
| in a glossary where its meaning is made more specific. | | in a glossary where its meaning is made more specific. |
| + | |
| An SRS is an important part of the requirements process of the software life cycle and is used in design, | | 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 IEEE Std | | implementation, project monitoring, verification and validation, and in training as described in IEEE Std |
| **** Requirements specification languages [#z6222c2e] | | **** Requirements specification languages [#z6222c2e] |
| 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 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 nontechnical 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 insubtle ways. | | One disadvantage in the use of such languages is the length of time required to learn them. Also, many nontechnical 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 insubtle ways. |
| + | |
| **** Representation tools [#o1e432b5] | | **** Representation tools [#o1e432b5] |
| 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 ßows. Behavioral approaches describe external behavior of the system in terms of some abstract notion (such as predicate | | 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 ßows. Behavioral approaches describe external behavior of the system in terms of some abstract notion (such as predicate |
| calculus), mathematical functions, or state machines. | | 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. | | 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. | | 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. |