ソフトウェア要件
システムの要件は、システムが提供するサービスを実行する必要があることの説明と、システムの操作に対する制約です。ソフトウェアエンジニアリング用語のIEEE標準用語集では、要件を次のように定義している[1]。
- 問題を解決したり、目的を達成したりするためにユーザーが必要とする条件または機能。
- 契約、標準、仕様、またはその他の正式に課された文書を満たすために、システムまたはシステムコンポーネントが満たす必要がある、または所有する必要がある条件または機能。
- 1または2のような条件または機能の文書化された表現。
ソフトウェア要件の処理に関連するアクティビティは、大まかに引き出し、分析、仕様、および管理に分類できる[2]。
聞き出し
[編集]聞き出しとは、利害関係者やその他の情報源からの要件の収集と発見のことである。共同アプリケーション設計（JAD）セッション、インタビュー、ドキュメント分析、フォーカスグループなど、さまざまな手法を使用する。聞き出しは、要件開発の最初の段階である。
分析
[編集]分析では、聞き出した内容を論理的に掘り下げる。分析を通して、各要件のより深く正確な理解を行い、複数の補完的な方法で一連の要件を表す。
要件トリアージまたは要件の優先順位付けは、多くの場合分析に続く別の活動である[3]。 これは、プランニングポーカーなどによる計画段階でのアジャイルソフトウェア開発に関連するが、プロジェクトの文脈と性質、要件、またはビルドされる製品/サービスによって内容が異なることがある。
仕様
[編集]仕様には、効果的なコミュニケーションと変更管理を容易にする、永続的でよく整理された方法で収集された要件知識を表現および保存することが含まれる。ユースケース、ユーザーストーリー、機能要件、および視覚的分析モデルは、要件仕様の一般的な選択肢である。
検証
[編集]検証には、プロジェクトのビジネス目標を満たすソリューションを構築するための正しい要件のセットが指定されていることを確認するための手法が含まれる。
管理
[編集]要件はプロジェクト中に変更され、多くの場合それらがあります。この変更の管理は、利害関係者のために正しいソフトウェアが構築されていることを確認するために最も重要になる。
要件エンジニアリングのツールサポート
[編集]要件の引き出し、分析、および検証のためのツール
[編集]これらの活動には、観察レポート（ユーザー観察）、アンケート（インタビュー、調査、投票）、ユースケース、ユーザーストーリーなどのアーティファクトが含まれる可能性がある。要件ワークショップ（シャレット）、ブレーンストーミング、マインドマッピング、ロールプレイングなどの活動、さらに、プロトタイピング [4]といった活動を支援するソフトウェア製品が使用できる。
FreeMindなどのマインドマッピングツールやConcordionなどのSpecification by Exampleツールを使用することもできる[5]。 さらに、これらの活動から得られたアイデアやステートメントは、ウィキやTrelloなどの他のコラボレーションツールを使用して収集、整理できる。実際に実装されている機能と標準への準拠は、製品ごとに異なる。
要件仕様のツール
[編集]ソフトウェア要件仕様書（SRS）は、ワープロやスプレッドシートなどの一般的なソフトウェアツールを使用して作成されるが、この活動を実行するための専用ツールもいくつかある。
これらのツールは、SRSドキュメントをインポート、編集、エクスポート、および公開できる。IEEE 2918-2011などの標準やReqIFなどに対応しているものもある。
要件文書検証のためのツール
[編集]この種のツールは、予想される構造または標準に従って、要件ドキュメントにエラーがあるかどうかを確認する。
要件比較のためのツール
[編集]この種のツールは、予想されるドキュメント構造と標準に従って2つの要件セットを比較する。
要件のマージと更新のためのツール
[編集]この種のツールを使用すると、要件ドキュメントをマージおよび更新できる。
要件のトレーサビリティのためのツール
[編集]この種のツールを使用すると、モデルやソースコードなどの他のアーティファクト（順方向のトレーサビリティ）、またはビジネスルールや制約などの以前のアーティファクト（逆方向のトレーサビリティ）まで要件をトレースできる。
モデルベースのソフトウェアまたはシステム要件エンジニアリングのためのツール
[編集]モデルベースシステムエンジニアリング（MBSE）は、システム要件、設計、分析、測定[6]、 検証および妥当性確認アクティビティをサポートするためのモデリングの正式なアプリケーションであり、概念設計フェーズから始まり、開発フェーズとその後のライフサイクルフェーズまで続く。要件エンジニアリングのいくつかの段階でモデルベースのアプローチを採用することも、他の段階ではより伝統的なアプローチを採用することも可能である。
形式性と複雑さのレベルは、関連する基礎となる方法論によって異なる（たとえば、 i*はSysMLよりもはるかに形式的であり、 UMLよりもさらに形式的である）。
一般的な要件エンジニアリングのためのツール
[編集]このカテゴリのツールは、前述の機能と、要件構成管理やコラボレーションなどの他の機能を組み合わせて提供する場合がある。実際に実装されている機能と標準への準拠は、製品ごとに異なる。
他の段階や活動をサポートする、さらに有能で一般的なツールがあります。それらはALMツールとして分類される。
関連項目
[編集]- 要件
- 要求工学
- ソフトウェア要件仕様（SRS）
- 包括的で堅牢な要件仕様プロセス
- 要件管理ツールのリスト
- 非機能要件
- ソフトウェアパフォーマンステストの対象となるパフォーマンス要件
- 安全要件
- セキュリティ要件
脚注
[編集]- ^ IEEE Computer Society (1990). “IEEE Standard Glossary of Software Engineering Terminology”. IEEE Standard.
- ^ “Guide to the Software Engineering Body of Knowledge”. IEEE Computer Society. 11 January 2013閲覧。
- ^ Davis, Alan Mark. (2005). Just enough requirements management : where software development meets marketing. New York: Dorset House Pub. ISBN 0-932633-64-1. OCLC 57211148
- ^ https://www.liquidplanner.com/blog/7-tools-to-gather-better-software-requirements/
- ^ Laplante, Phillip A. (2009). Requirements Engineering for Software and Systems. CRC Press.
- ^ Monperrus, M.; Baudry, B.; Champeau, J.; Hoeltzener, B.; Jézéquel, J. M. (2011). “Automated measurement of models of requirements”. Software Quality Journal 21 (1): 3–22. doi:10.1007/s11219-011-9163-6.
参考文献
[編集]- Wiegers, Karl; Beatty, Joy (2013). Software Requirements (3rd ed.). Microsoft Press. ISBN 978-0-7356-7966-5
- Cockburn, Alistair (2001). Writing Effective Use Cases. Pearson Education. ISBN 0-201-70225-8
- Leffingwell, Dean (2000). Managing Software Requirements: A Unified Approach. Addison-Wesley Professional. ISBN 0-201-61593-2
- Burek, Paul (2008). Creating clear project requirements differentiating "what" from "how". Conference Paper. Requirements Management, Business Analysis, Scope Management.
- Koopman, Philip (2020). Embedded Software Requirements. Fall Lectures.
- IEEE Xplore Search. "Software Requirements".