1: 2013-07-14 (日) 16:02:59 FujitaYutaka  |
|||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | * 完全性 [#f4d6bb1f] | ||
| + | ** 参考定義 [#i670a3d8] | ||
| + | *** IEEE 830 [#ie374c3a] | ||
| + | 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. | ||
| + | b) Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values. | ||
| + | c) Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure. | ||
| + | |||
| + | 4.3.3.1 Use of TBDs | ||
| + | Any SRS that uses the phrase "to be determined" (TBD) is not a complete SRS. The TBD is, however, occasionally necessary and should be accompanied by | ||
| + | a) A description of the conditions causing the TBD (e.g., why an answer is not known) so that the situation can be resolved; | ||
| + | b) A description of what must be done to eliminate the TBD, who is responsible for its elimination, and by when it must be eliminated. | ||
| + | 4.3.4 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 (see 4.3.1). | ||
| + | 4.3.4.1 Internal consistency | ||
| + | An SRS is internally consistent if, and only if, no subset of individual requirements described in it conflict. | ||
| + | The three types of likely conflicts in an SRS are as follows: | ||
| + | a) The specified characteristics of real-world objects may conflict. For example, | ||
| + | 1) The format of an output report may be described in one requirement as tabular but in another as | ||
| + | textual. | ||
| + | 2) One requirement may state that all lights shall be green while another may state that all lights | ||
| + | shall be blue. | ||
| + | b) There may be logical or temporal conflict between two specified actions. For example, | ||
| + | 1) One requirement may specify that the program will add two inputs and another may specify | ||
| + | that the program will multiply them. | ||
| + | 2) One requirement may state that "A" must always follow "B," while another may require that "A and B" occur simultaneously. | ||
| + | c) Two or more requirements may describe the same real-world object but use different terms for that object. For example, a program's request for a user input may be called a "prompt" in one requirement and a "cue" in another. The use of standard terminology and definitions promotes consistency. | ||
- 完全性 のバックアップ一覧
- 完全性 のバックアップ差分(No. All)
- 1: 2013-07-14 (日) 16:02:59 FujitaYutaka
- 2: 2013-07-14 (日) 16:21:40 FujitaYutaka
- 現: 2013-07-22 (月) 04:52:52 ShioyaAtsuko
Counter: 5227,
today: 1,
yesterday: 0