昨今はオブジェクト指向による要求分析や設計の手法がメインストリームとして流行っていますが、古典的構造化手法の定義をそのまま解釈するなら、これらオブジェクト指向による手法も構造化手法の一種に分類されます。
しかしながら、デマルコやコンスタンチン以降のいわゆる構造化手法を構造化手法とするなら、明らかに異なったものになります。こちらの構造化手法の特徴は、以下のものになります:
- データフローダイアグラム（Data Flow Diagram: 略称 DFD）によるデータの流れと処理の手順
- データディクショナリーによるデータの論理形式定義
- ミニスペックによる各手続き（function）の処理内容記述
- モジュール構造図による各手続きのモジュール構造記述とシステム全体のモジュール構造記述
データと機能に焦点を当てて、要求や設計を行っていくのが特徴でしょうか。個人的には、実装における関数プログラミング言語との親和性が高いと思っています。ですので、長所も短所も関数プログラミング言語と同様なものが現れている気がします。
長所ですが、以下でしょうか:
- 機能限定で見るなら、分かりやすい（素人にも分かる = ソフトウェア開発の素人の顧客にもわかる）
- 上記にあるような道具が単純にできているため、道具自体の理解は容易
- 具体的実現可能性※ 検討前の段階の機能要求分析であるならきわめて強力
※具体的実現可能性：私が勝手に作った言葉ですが、システムのプラットホーム(例えばどこそこのサーバコンピュータ上の Windows OS であるとか、データベースが Oracle であるとかなど）などまで踏み込んだ、顧客の予算と結びつきそうな段階のシステムの実現可能性です。これとは別に、原理的に実現可能なシステムであるか？の検討とか、原理的には大丈夫だけれど、実際のところその方式で計算可能な計算量に収まっているのか？という検討は、これより前にしているはずです。
短所は、以下になるでしょうか:
- システムの本質的複雑さが高い場合、記述が困難になってくる
- 外界からのインタラクティブな操作など、外とのやり取り手順のようなものが要求として重要（ある種のワークフローに制限されるような状況）になると、その手の手順の表現が無いため適用が困難になる
- 上記の性質があるため、タイミング制御などが重要なシステム制御ソフトや組み込みソフトの設計では単純に適用することは困難
上記のような短所があるため、現代的な複雑な PC アプリや機器組み込みソフト開発では、UML を駆使するオブジェクト指向手法に株を奪われている。
しかし、そうは言っても単純で分かりやすいので、要求まとめの初期段階では、下手に UML だけをいじるよりよっぽど良いと思います。もっと言えば、UML と組み合わせればよい。例えば、各ユースケースごとに DFD を描き、データディクショナリーを書いていけば分かりやすくなると思います。
ことにデータディクショナリーは重要。