ソフトウェアエンジニアリングより

ソフトウェアエンジニアリング (Object Oriented SELECTION)

この本は、ソフトウェアエンジニアリングをオブジェクト指向に沿って記述し直した本なので、比較的受け入れやすい内容です。

要求分析

2段階に分けて要求分析を扱っている点が興味深いです。

1. 顧客要求（C-要求）
2. 開発者要求（D-要求）

1.は、主要な読み手は顧客、次の読み手が開発者。2.は、主要な読み手は開発者、次の読み手が顧客とターゲットを明確に分けて記述します。

要求分析を記述する成果物：ソフトウェア要求仕様書

SRS:Software Requirement Specification
要求分析は、顧客と開発側との合意事項なので、顧客、開発側（上層部）に理解できる形式で書かれます。
章節構成
1. はじめに
2. 全体の記述
3. 具体的な記述（特定要求）
4. 関連情報
このうち、1.と2.がC-要求、4はD-要求。3.はその中間になります。

C-要求は、顧客の持つ無意識・不完全な動作ビジョン（コンセプト）を明確化するために、ユースケース、データフロー、状態遷移などの手法を適切に組み合わせて表現します。ユーザーインタフェースは設計で実施してもよいが、顧客がGUIを見ることによりアプリケーションを具体的に想像できるので、この段階でGUIのスケッチを利用するとよいでしょう。

D-要求は、開発側の仕様記述となり、機能要求、非機能要求、禁止要求を記述します。

アーキテクチャ設計

設計は、アーキテクチャ設計と詳細設計に分けています。アーキテクチャ設計では、アーキテクチャの選択を行います。設計目標に優先順位をつけて、その順位について最良の選択を行います。
アーキテクチャは、アプリケーションがどのように動くかというメンタルモデルをいくつかのコンポーネントで構成したものです。ゼロから考えることもありますが、アーキテクチャ・パターンのようにすでに開発されたアーキテクチャも有用です。
日本語で読めるアーキテクチャパターン本は以下のものがあります。

古典的なデータフローアーキテクチャ、クライアント/サーバアーキテクチャ、イベントシステム、バーチャルマシーン、レイヤー、などなど紹介されています。

設計を記述する成果物：ソフトウェア設計ドキュメント

SDD:Software Design Document
章節構成
1.序論
2.参照
3.分解に関する記述
4.依存に関する記述
5.インタフェースに関する記述
6.詳細設計

アーキテクチャ設計のレビュー

アーキテクチャは重要な決定なので、選択肢を十分検討し（開発し）、それらを比較します。比較項目としては、IEEE982からのメトリクスを勧めています。
選択したアーキテクチャ上でユースケースを実行する検討によって要求が適切に実現できるかを検討します。

ドキュメント

ソフトウェア開発に関するドキュメンテーション標準としては、IEEE830-1993が制定されています。しかし、古いのでオブジェクト指向やインターネット問題への対応ができていません。この書籍では、IEEE標準をオブジェクト指向にそって修正／追加して対応するという方針をとっています。

オブジェクト指向の取り込みの趣旨

この書籍では、オブジェクト指向を、要求の変化にソフトウェアの管理と適応が容易に対応できる仕組みとして取り入れています。つまり、要求となる実業務における概念やルールなどの要素とソフトウェアを構成する単位であるモジュールとのマッピングがしやすいという点です。
※要求とモジュールが良好にマッピングされるには、それなりに設計で苦労する必要があると思うけれど

構造化アプローチでは、機能をルーチンに分解していくが、ルーチン間のデータはグローバル変数となることが多いため、要求の変更に対応するのが難しいという問題が指摘されています。