物語指向要求記述
国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授 （前NTTデータ フェロー システム科学研究所長）山本 修一郎 今回は、ロールスロイス社のMarvinらが提案している安全要求を自然言語で記述するためのEARS（Easy Approach to Requirements Syntax、要求定義のための簡易構文）テンプレートを紹介する[1][2]。 この方法は、要求定義の専門家ではない発注者（ステークホルダ）が５種類のテンプレート構文を用いることにより、自然言語による要求定義が持つ曖昧性や検証不能性などの多様な問題を回避できるように考案されたものである。Marvinらは、この手法を航空機エンジン制御システムの要求記述に適用することにより、英語を用いた要求記述の多くの問題を解消できたと報告している。 以下では、まずEARSによる要求記述テンプレートを紹介する。次に、自然言語で記述さ
第38回：要求の曖昧さ(要求工学：Requirements Engineering)
前回、要求レビュについて解説した。そこで、要求の曖昧さをチェックすることが重要だとは述べたが、「複数の解釈ができることはないか？」というレビュ項目を示しただけで、要求レビュの具体的なやり方については説明しなかった。 今回は、要求仕様の曖昧さとは何か？それをどのようにして検出すればいいのか？について考えよう。 さて日常的な意味では、曖昧さというと、「ものごとがぼんやりしていて、何であるかはっきりしない様子」のことだろう。同じように、要求が明確に定義されていない（不明性）か、複数の意味に解釈できる（多義性）とき、要求が曖昧だと考えることができるだろう。 機能要求の構造と曖昧さ そもそも曖昧さはどのようにして発生するのだろうか？ 非機能要求については、本連載でもゴール指向要求工学などで定義する手法を何回か紹介しているので、ここでは機能要求の曖昧さについて考えていくことにする。 ソフトウェアの機能
要求に基づくテストの十分性
国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授 （前NTTデータ フェロー システム科学研究所長）山本 修一郎 今回は、テストの十分性について考察しよう。テストでは、ソフトウェアの実装が要求を満足することを示す証拠を確認できる必要がある。このためソフトウェアの実装が、要求を満足すると判断できるだけの根拠を示すためのテスト項目を要求から抽出できなければ、テストが十分ではないことになる。 テストの十分性を確認するためには、システムを必要とする発注者、システムを実装する開発者、実装されたシステムが要求を満たすことを確認する検証者との、テスト項目についての合意が必要である。 保証ケース（Assurance case）では、立証したい主張を証拠に基づいてステークホルダ間で議論することによって、主張についての合意を形成できる[1]。保証ケースはこれまで、テスト結果を証拠としてシステムの安
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bcm連載: UMLの基礎と応用
要求工学:Requirements Engineering(月刊ビジネスコミュニケーション)