1: 2013-07-14 (日) 16:02:59 FujitaYutaka  |
現: 2013-07-22 (月) 04:52:52 ShioyaAtsuko |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| * 完全性 [#f4d6bb1f] | * 完全性 [#f4d6bb1f] | ||
| ** 参考定義 [#i670a3d8] | ** 参考定義 [#i670a3d8] | ||
| - | *** IEEE 830 [#ie374c3a] | + | *** IEEE std 830-1998 (Complete)[#ie374c3a] |
| An SRS is complete if, and only if, it includes the following elements: | An SRS is complete if, and only if, it includes the following elements: | ||
| + | |||
| a) All significant requirements, whether relating to functionality, performance, design constraints, | 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. | 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. | 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. | 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 | + | **** Use of TBDs [#gf969422] |
| 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 | 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; | 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. | 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). | + | *** IEEE std 830-1998 和訳例 [#z1313263] |
| - | 4.3.4.1 Internal consistency | + | SRSが、次をすべて含んでいること |
| - | 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. | + | ([[月刊「ビジネスコミュニケーション」（(株)ビジネスコミュニケーション社）の「要求工学」第3回「要求仕様」>http://www.bcm.co.jp/site/2004/2004Dec/04-youkyuu-kougaku-12/04-youkyuu-kougaku-12.htm]]による） |
| - | 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
Counter: 5236,
today: 1,
yesterday: 2