完全性 |
機能実現 |
要求されたすべての機能が正しく実現されていること (ロジックをトレースしながら要求機能を満足するかを確認する) (例:上位仕様書の目次の最小単位に対応する詳細仕様内のモジュールの機能が論理的に正しく実現するかをチェックする) |
|
機能表現 |
すべてのモジュール記述は、解釈が一意に決まるような表現になっていること |
|
データの出所 |
すべてのデータやその出所が定義され、初期設定されること (外部からの入力、データファイルから読み込み、計算結果) |
|
|
すべて定義されたデータが使われていること |
|
|
デフォルトのデータが使われる場合、それらは正しいこと |
|
判断点 |
すべての条件・処理が各判断点に対して定義されていること |
|
|
すべてのケースは、ELSEまたはDEFAULTの条件を含めて、IF ELSEIFまたはCASEブロックにおいてカバーされていること |
|
|
すべてのCASEステートメントはデフォルトを持っていること |
|
パラメータ |
定義されているパラメータと呼び出されているパラメータがすべて一致していること (インタフェース用に定義されたパラメータは全て使われること) (数、順、データタイプ等は正しいこと) |
|
開始・終了処理 |
ファイルI/O、初期値およびループ内での加減算値の設定、終了処理が正しいこと |
|
|
ファイルのアクセス前に、その存在についてチェックされること |
|
|
外部の機器アクセスには、タイムアウトまたはエラートラップをするようになっていること |
|
|
ファイルと機器はプログラム終了時に、正しい状態にされること |
|
|
待ち処理は必ず解決されること |
|
割り込み制御 |
制御タイミングの分析がなされること (タイムチャートによるタイミングの分析) (割り込み制御の順序を考慮すること) |
|
|
処理上、どこで割り込まれても良い設計にすること |
|
|
不当な割り込みがないこと |
|
|
ある種の同期を取らなくてよいか考慮されること |
追跡可能性 |
要求機能 (下向き) |
基本仕様書中にあるすべての要求が詳細仕様書の中にあること (詳細設計のすべての部分は上位の設計や要件から追跡できる) (詳細設計は上位の設計を全て実現している) (例:上位仕様書の目次の最小単位の各要素が詳細設計のどこに盛り込まれているかを調べる) |
|
|
各モジュールの外部仕様、詳細設計、すべてのロジックは検証が可能であること |
|
要求機能 (上向き) |
余分な要求が詳細仕様書中に含まれていないこと (例:詳細仕様書の目次の最小単位の各要素が上位仕様書のどこから導出されているかを調べる) |
|
員数チェック |
設計工程で必要なドキュメントをすべて作成していること |
無矛盾性 |
機能実現 |
すべての機能実現に矛盾がないこと 基本仕様と詳細仕様間の矛盾がないこと |
一貫性 |
設計標準 |
設計標準が設定され、守られていること |
|
|
擬似コードまたは他の表現の方法は詳細レベルが一貫していること |
|
パラメータの引き渡し順序 |
パラメータの引き渡し順序に関する規定が設定され、守られていること |
|
入出力規定 |
入出力規定(方法、フォーマットなど)が設定され、守られていること (呼出しプロトコルはプロジェクト標準に従っていること) |
|
エラー処理規程 |
エラー処理規程が設定され、守られていること |
|
データ使用規定 |
データ使用規定が設定され、守られていること (データ要素名と型はプロジェクトデータディクショナリに対応する) |
|
ネーミング規定 |
ネーミング規定が設定され、守られていること (最低でも変数名、プロシージャ名、モジュール名、テーブル名、ファイル名、データ名はカバーしていること) |
|
|
モジュール、テーブル、ファイル、データの各名称変更時の方法が明確化され、その結果が記録されること |
自己記述性 |
変数名 |
変数名は物理的あるいは機械的特性を表現していること |
|
図番およびタイトル |
図番およびタイトルが図の内容をよく表していること |
|
コメント |
必要かつ十分なコメントがついていること ○例:以下の項目がわかるよう記述されている ・データのチェック方法および処理方法 ・コードの意味および処理方法 ・計算内容 ・更新処理方法 ・集計やプリントを行う場合のコントロール ・出力帳票については、詳細な印字方法 |
|
|
モジュール、テーブル、ファイル、バッファ、メモリそれぞれにレイアウト、サイズ、構造、名称、形式の記述があること |
|
|
未使用エリアの記述があること |
|
|
各インジケータ名称の記述があること |
|
|
各モジュール、テーブル、ファイル、バッファ、タスク、メッセージ、インジケータ間の生成、参照、更新、消去インタフェース、排他、共用インタフェース、アクセス権、アクセスタイミングの記述があること |
|
|
各モジュール、テーブル、ファイル、バッファ、タスク、メッセージ、インジケータなどの相互にインタフェースがある場合には、それが記述されていること |
|
|
レジスタの記述があること |
計算正確性 |
計算精度 |
計算精度や制御精度は定義された精度に従っていること (計算や制御の精度の分析がなされること) |
|
|
演算での丸め、切捨て、四捨五入を考えていること |
|
データの属性 |
入出力データおよび定数の属性(種類・桁数・量等)が定義されていること |
データ共通性 |
変換標準 |
表現間の変換標準が設定され、守られていること |
|
データの互換性 |
他システムとのデータの互換性が検討されていること (データ共用できるように、記述方法を統一する) ・データ変換則が定められ、守られている ・データ変換が不可の時の約束が定められ、守られている ・データの順序の約束が定められ、守られている ・アドレスづけがユニークに定められ、守られている ・データの定義が定められ、守られている ・データ例外の定義が守られている |
通信手段共通性 |
プロトコル標準 |
プロトコル標準が設定され、守られていること ・プロトコル(通信規約)、初めと終わりの合図が定められ、守られる ・障害発生を知らせたり認識する約束が決められ、守られる ・障害回復条件が決められる |
|
インタフェース標準 |
インタフェースについての標準が設定され守られていること (標準(法規制など)に規定された外部仕様に適合すること) |
|
|
標準に規定されていないものについての処理を定めること (この場合、将来の変更に対処できるように設計する) |
アクセス制御性 |
アクセス制御 |
権限が与えられた者のみが、システム内の対象へ直接アクセスができるように定義されていること(パスワードチェック) (不当アクセスについて記録をとるべきである) |
|
フロー制御 |
正当なアクセス権をもつ主体によって、権限を持たない主体にデータが漏洩したり破壊されたりすることが防がれるよう定義されていること (例:機密度レベル(極秘、部外秘、一般等)を設定し、機密度の低い情報記録物への転写が禁止されること) (例:著作権あるデータを勝手にコピーできないこと) |
|
|
情報を破壊、盗難した相手がわかること (履歴をとる。) |
|
|
情報の破壊に対して、事前に情報が保存されること (ファイルの二重管理など) |
|
推論制御 |
特定の個人に関する秘密データが推論されることが阻止されるよう定義されていること (例:関連した統計的諸性質(総数、平均、最小値)に関する正当な問い合わせを重ねることにより、その情報の値が推論されることを阻止する) |
|
暗号化制御 |
必要に応じてデータの暗号化が定義されていること |
|
機密の保護 |
異常処理時にセキュリティに対する考慮があること |
アクセス監査性 |
アクセス記録 |
機密情報へのアクセス記録をとることが定義されていること (機密情報へのアクセス制御が正しく行われているかを定期的に調べる) |
堅固性 |
入力データの許容範囲 |
入力データや引数の値の範囲がチェックされていること(桁数チェック含む) |
|
操作員による入力ミス |
操作員の誤操作に対する処置が記述されていること 防止方法:誤った操作や入力を不可にする 予防方法:誤らないように、わかりやすくし、気づかせる 検知方法:システム側あるいは人間側で誤りを発見できる 回復方法:操作による回復またはシステム側で自動回復する |
|
|
システム停止要求といった影響の大きな処理に対して問い合わせ応答形式の再確認を求めること |
|
ハードウェア故障からの回復 |
ハードウェア故障からの回復の規定が存在すること (故障に対する安全確保や故障からの回復が可能であること) (ハードウェア装置、測定機器等とインタフェースを行うプログラムにのみ適用) |
整合性 |
障害対策 |
計算や制御障害からの回復の規定が存在し、守られていること (境界値や限界値、検知、回復、エラー処理、記録、エラー表示、例外処理の明確化) (オーバーフロー、アンダーフロー、ゼロ割りでの障害からの回復) |
計測性 |
計測機能 |
使用率やエラーの発生回数を測定する機能が盛り込まれていること |
|
履歴機能 |
デバッグ機能、トレース、ロギングなどの障害診断用の記録や、ダンプ解析などの障害解析の記録をとる機能が明確であること |
モジュール性 |
モジュールサイズ |
モジュールの大きさが妥当であること(コードにした時50~100ステートメント程度)(過度に複雑なモジュールは、再構造化するか、複数のルーチンに分割すること) |
|
モジュール強度 |
モジュール強度は強いこと (全ての機能は論理的に独立させ、モジュール機能の関連を単純にする)(「補足資料4」参照) |
|
モジュール結合度 |
モジュール結合度は弱いこと (モジュール間の変数やりとり、インタフェースを単純にする) (「補足資料4」参照) |
|
|
各インタフェースは、最小のデータで渡されること |
|
|
グローバルなシステムデータの追加や挿入は最小になっていること |
|
階層構造 |
階層構造になっていること (わかりやすい、保守管理しやすい、テストしやすい、モジュール共用しやすい、適切な人員配置ができる構造になっていること) |
製品管理性 |
管理性 |
モジュールの変更管理・構成管理しやすいこと (版がわかる、識別できる) |
単純性 |
トップダウンの設計 |
トップダウン方式による設計になっていること (下位レベルのモジュールが上位レベルのモジュールを呼んでないこと。モジュールの呼び出し順序が正しいか調べる) |
|
重複機能 |
重複機能がないこと (モジュール内の機能に、同じ処理を行うものが複数個存在しない。) (異なった方法やサブルーチンを用いても、同じ処理を行っている場合は注意する) |
|
モジュール記述 |
各モジュール記述は入力、出力、処理および制限事項を含んでいること |
|
|
モジュールの出入り口が明確であること (ルーチンの入り口は1箇所であること) |
|
読みやすさ |
各機能が読みやすく、理解しやすいいこと (ロジック、アルゴリズムはわかりやすいこと) |
|
モジュールフロー |
モジュールフローがトップからボトムへ流れていること |
|
|
モジュール間やタスク間の制御の流れが記述されていること |
|
ブール表現 |
肯定のブール表現あるいは単純なブール表現を使っていること |
|
ループ |
各ループは1つの入り口と1つの出口をもつこと |
|
|
ループ終了条件が明らかで、どのような場合でもループの終了あるいは抜けることができること(無限ループにならない) |
|
|
インデックスまたはサブスクリプトは、ループに入る前に、適切に初期設定されること |
|
|
インデックス変数をループ中や外で取り扱わないようにすること |
|
モジュールの自己修正 |
モジュールは自己修正されないこと (自分で自分の処理ロジックを修正する能力を無くすこと) |
|
ラベル |
すべてのラベルが参照されること(必要なラベル以外は避ける) |
|
ネスティング・レベル |
ネスティング・レベルが少ないこと |
|
分岐 |
不必要な分岐がないこと |
|
GOTO |
認められている以外のGOTOがないこと |
|
クローバル変数 |
不必要なグローバル変数がないこと |
|
サブルーチン |
サブルーチンは単一機能であること |
簡潔性 |
機能 |
機能の記述は簡潔でわかりやすいこと ○ガイド例 ・1ページにおさまっている ・所定の記号を用いている ・書き方が煩雑でなく読みやすい |
|
入出力 |
表現が簡潔で的を得ていること |
表現性 |
応答 |
応答が親切かつ適切であること ○チェック観点例 ・理解しやすいか ・量は適切か ・量をユーザが調節できるか |
|
シンボル等 |
シンボルやアイコンは他人が見て意味がわかること (アイコンの表示、図表化、概念図) |
比喩性 |
比喩の利用 |
機能、特徴を別の事に比喩してわかりやすくしていること |
階層性 |
利用の階層構造 |
利用を適切に階層化すること。 |
|
|
情報表示は特徴を持ち、段階表示されてわかりやすい |
統一性 |
入力方法 |
入力方法は統一的な規則になっていること |
|
キー割り当て |
キーの割り当てが適切であること 作業に統一性を持たせて使いやすくする。 |
完備性 |
マニュアル |
ユーザがシステムを理解しやすいようにマニュアル(利用説明書、運用説明書)が用意されていること (例示があり、視覚化されること) |
|
応答 |
指示やガイダンスが出て、選択できる |
|
画面操作 |
スクロールなどの画面操作ができる |
|
HELP |
作業に応じたHELPが使えること |
|
|
HELPは例示があり、視覚化されること |
誘導性 |
類推のしやすさ |
覚えたことをもとに類推して使っていけること (ユーザが使うコマンド等を系統づけておくなど) |
|
画面の表示順序 |
画面の表示順序はユーザの作業の流れと一致していること |
適量性(記憶性) |
情報量 |
人間の記憶の限界が考慮されていること。 (必要なときに必要な情報を表示する、コマンドの構文を覚えやすくするなど) |
|
レベルに応じた学習 |
ユーザの知識に合わせて学習していけること |
省力性 |
オペレーション |
オペレーションの簡略化の工夫がある |
|
打鍵キーの数 |
一度に入力する打鍵キーの数が少ないこと |
|
重複入力 |
同じ入力を何回もやらなくて済むこと |
|
起動操作 |
プログラムの起動のための操作が容易であること (例:打鍵キーが少ないこと、操作に必要な情報が与えられること等) |
適時性 |
指示のタイミング |
実行の完了を待たずに次の指示がだせること (時間のかかる作業を行う場合、その裏で別の作業を行える。) (次の作業指示、処理の過程が表示され、コマンド入力等の先取り処理が考慮される) |
選択性 |
説明 |
説明にレベルが設定され、選択できる |
|
ユーザレベルへの対応 |
ユーザの行動特性に応じて入力方法が選択できること (例:熟練者は近道をしたり、機能を追加したりすることができる) |
環境適合性 |
使用用語 |
入出力には、業種に合った用語を使用していること 専門用語は必要なときだけ使う |
説明性 |
状態表示 |
作業の流れの中での現在の処理進行状態や位置や結果情報が常に明確になること (メッセージ、画像、リスト、ランプ・・) (例:待ち状態の発生箇所においては、作業中であることを示すようになっている) |
|
エラーメッセージ |
エラーメッセージが適切であること 異常検出時には、ただちに警報機能や通報機能があること ○チェック観点例 ・問題点が明らかにされているか ・ユーザが次に行うべきことを示しているか ・メッセージは「ですます調」で書かれているか |
|
|
エラーの表示やその後の処理の指示があること |
安全性 |
試行錯誤 |
試行錯誤的に使っていけること ○準備例 ・破壊的な操作が適切にふさがれている ・利用できる機能が強調等によって示される |
|
ユーザレベルへの対応 |
入力ミスに対する安全が利用者の特性に応じて保たれていること |
|
再確認 |
重要なものは再確認ができること (例:ファイルSAVE) |
|
入力ミスの修正 |
入力ミスの修正、キャンセルは簡単にできること (前オペレーションに戻れる等の操作が可能) (再入力可能である) |
|
継続再開 |
作業を中断しても、中断箇所から継続再開できること |
注目性 |
画面表示 |
画面表示のレイアウト、色、強調部分が適切で工夫があること (アクセントや変化がある、形が変わっている、特異な音が出る) |
実行効率性 |
割り込み処理 |
一回の割り込み処理が長くないこと |
|
処理方法 |
効率のよい処理方法であること |
|
|
メモリ資源や入出力資源やCPUや回線処理能力に余裕があるときの高速処理や多重処理ができること |
|
|
特定の機能について高速処理や多重処理ができること |
|
|
CPUを必要としないとき、保持する資源数を最小にする |
|
最適化処理 |
CPU使用特性に合わせてスケジュールができること(並列処理) |
|
|
ユーザ要求やデータ量に応じた処理の最適化ができること(最適アルゴリズムの選択) |
|
回線効率 |
同一アドレスで多重使用ができること |
|
|
異なるアドレスからの通信に対応できること |
|
|
必要なときのみ通信できること |
|
入出力装置 |
同一特性での要求を連続して処理をすること(プリンタ出力特性の保持) |
|
|
CPU割り込みの無いか少ない形での入出力要求を出すこと |
|
|
入出力装置の特性、性能に適合した入出力要求を出すこと(バッファリングサイズや回転待ち時間の調整や準備完了までの初期動作時間の調整など) |
資源効率性 |
メモリ容量 |
各モジュールの占有メモリは見積り所要値を満たしていること (見積もり値が更に正確になるようアップデートされていること) |
|
|
ストレージ(メモリ、記憶装置など)の使用は効率的であること |
|
|
必要時に最小必要量をとり、不要になったらすぐ解放すること |
|
|
不連続領域でも良いように処理すること |
|
|
バウンダリ調整は小さな単位で行うこと |
|
外部装置 |
必要時に最小資源で行い、不要になったらすぐ解放すること |
|
ファイル容量やデータ |
ファイル容量が見積り値を満たしていること (見積もり値が更に正確になるようアップデートされていること) |
|
|
ブロッキングなどにより、無効データを作らないやり方とすること |
|
|
データ圧縮機能により効率を上げること |
|
|
アクセス頻度の高いデータ、ファイルはメモリ常駐あるいはディスクキャッシュに取り込む使い方をし、不要なデータ、ファイルはメモリに常駐させないこと |
|
|
データ、ファイルの特性に合わせたアクセス機能があること |
拡張性 |
追加機能に対する配置 |
追加機能、移植に対する配慮がなされていること (構造、テスト、ドキュメント準備など) (拡張が予定されている機能対象) |
|
|
一つの変更に対して多数の箇所を変更せずにすむこと |
|
|
変更に対応したパラメータ化をすること |
|
ハードウェア拡張 |
ハードウェア拡張に対する配慮がなされていること (拡張が予定されているハード対象) |
|
テーブル等の拡張 |
制御テーブル、インジケータ等は拡張を配慮して余裕があること (拡張が予定されている制御テーブル、インジケータ対象) |
ソフトウェアシステム 独立性 |
ソフトウェア環境への依存度 |
ソフトウェア環境(OS、ユーティリティ、入出力ルーチン等)に対する依存度が小さいこと (ソフトウェア変更が必要無く、追加、改造、入れ替えで移植できる) |
|
|
データやファイルの属性、構造に対する依存度が小さいこと (コンバータによる変更か、論理的対応付けだけで移植ができる) |
マシン独立性 |
ハードウェアへの依存度 |
ハードウェアへの依存度が小さいこと (ハード変更が必要無く、追加、改造、入れ替えで移植できる) (将来の使用メモリ、CPU、周辺機器、入出力装置の変更に耐えうる) |
データ独立性 |
データへの依存度 |
データ構造への依存度が小さく、データが汎用的に使えること データに関しても移植が容易であること |
アクセス可能性 |
パターン化/ パッケージ化 |
装置利用やデータ管理や処理のロジックを、処理ロジック単位でパターン化/パッケージ化していること |
伝達性 |
モジュールの参照 |
モジュールが、他のモジュールに参照されることを考慮していること (他のモジュールの参照モジュールとなることを考慮して一般性を考慮する) |