|
1: 2013-07-14 (日) 16:06:51 FujitaYutaka |
| + | * 一貫性 [#i29208ba] |
| | | |
| + | ** 参考定義 [#j9f859d5] |
| + | *** IEEE 830 [#d0d58e48] |
| + | 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). |
| + | **** Internal consistency [#m8fa158f] |
| + | 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. |