問題図
M. Jackson の問題-フレーム分析（PFA）で用いられる図である（PFAに関する最近の論文には，「幾つかの原則とアイデア」という論文 がある）．
例題（会議スケジュール管理システム）としては同じで，前回のPFAコンテキスト図から問題図を作る（下図を参照）．
M. Jackson氏の問題図
上記で，「スケジューラ」は，作るべきソフトウェア「機械」を示している．単一の縦線を含む「制約リポジトリ」は，設計する機械を示している．機械が操作する対象でもある．その他の矩形は，問題領域となる（ここでの問題領域は，通常とは少し違った意味で用いられている．問題に関係している実体 – 但し，ジャクソン法でいう – であろうか）．
重要なのは，点線で示される部分である（教科書では一点鎖線になっている．ここではオリジナルに合わせて，点線を用いる）．ここがソフトウェア「機械」に対する要求である．要求は，スケジューラを作ることではなく，「参加予定者にとって都合が良い，会議の日程・場所を定めること」である．通常見失いやすい，要求と仕様の違いである．
矢印付き点線は，制約を加えることを示している．ここでの要求は，まさに会議（日時・場所）を決定することにある．矢印のない点線は情報を取得することを示している．参加者から会議を計画するための必要な情報を得ることを示している．
上図における記号は，次のような意味を持っている．
問題図における記号の説明
| a |
IN! {meetingRequest} |
| b |
SCH!{meetingNotification} |
| c |
SCH!{collectedConstraints} |
| d |
SCH!{constraintsRequest, meetingNotification} |
| e |
PART!{constraintsSent} |
| f |
SCH!{determineDate, determineLocation} |
| g |
PART!{constrints} |
| h |
SCH!{Date, Location} |
例えば，aは，招待者（IN）から会議招集依頼（meetingRequest）が発行されるという意味である．！の記号は，CSPのように出力を表している．SCHは，スケジューラ，PARTは，参加者である．
問題フレーム分析（PFA）であるから，フレーム図というのも存在する．フレームとは，ある種の問題のパターンを表している．簡単な例が原書では示されているが，今回は省略する．
(nil)
対象としている問題のフレームと合致するほかの問題が数多くある場合，それらの問題に使えた手法と技術が，いま解こうとしている問題に適用可能であることが期待できる．このことが開発手法の要点である ．
ここでは，図式を用いた記述についての説明である．ときに半形式的と呼ばれる場合もある．自由な自然言語での記述から制約を加えていくと，自然とこの図式を用いた表現になる．
最初が，システム全体を示す図の紹介である．
コンテキスト図
20年ほど前に注目を浴びていた構造化分析手法におけるデータフロー図（DFD）を知っている人には，懐かしい言葉だと思う．階層に従って，様々なDFDが書かれるが，最上位のDFD.0が，コンテキスト図に相当する．DFD.1 以降は，システム内部の詳細化である．いまだと，最初のユースケース図が相当するだろうか（ちなみにDFDについては，数回後に紹介がある）．
コンテキスト図は，システム（DFDでは，通常プロセスと呼ぶ）と，そのシステムとデータをやりとりするエンティティとの関係を示している．ここでのエンティティには人も含む．会議スケジュール管理システムにおけるコンテキスト図は，以下になる．
構造化分析におけるコンテキスト図
システムが何かということを説明する前に，そのシステムが関与するコンポーネントを示すことは，システム境界を示すことでもある．Aというエンティティが，システムと情報をやりとりしているのであれば，Aは，システムの一部ではない．システムとコンポーネントAの間には，境界があるということになる．
次に，以前にも紹介したM.Jacksonの問題フレームワーク分析（PFA）のコンテキスト図である．これは，（同じコンテキスト図という名前を使っていても）構造化分析の表現とは異なる．
問題フレームワークのコンテキスト図
上記のコンテキス図は，会議スケジュール管理システムのものである．システム全体が中心ではない．ここでのメタファでは「機械」と呼ばれるアクティブな実体（ここでは，スケジューラ）が中心に来る．
制約リポジトリも（日程・場所）の衝突解析器（各参加者のスケジュールの調整を行う）は，機械に協力するコンポーネントである．
構造化分析のデータフロー図では（その名の通り）データの流れを示すために，流れる向きを記載する．機械とその協力者であるコンポーネントとの間では，（この段階では）相互の協力関係(shared phenomena)として，向きを示さない．
このように，PFAのコンテキスト図では，システム境界は意識されない．
(nil)
前回のテンプレートは，各要求にどういう属性を与えるかという点に着目している．今回は，要求文書全体の構造についてである．
文書のテンプレートと云うときに，常に引用されるIEEE 830 （ソフトウェア要求仕様書を記述するときの推奨） では，次のような例が示されている．
1. はじめに
1.1 目的
1.2 適用範囲
1.3 定義，頭文字及び略語
1.4 参照文書
1.5 （以降の記述の）概要
2. 概要の記述
2.1 製品の範囲
2.2 製品の機能
2.3 ユーザの特徴
2.4 制約
2.5 前提と依存
3. 要求
3.1 外部インターフェイス要求
3.1.1 ユーザインターフェイス
3.1.2 ハードウェアインターフェイス
3.1.3 ソフトウェアインターフェイス
3.1.4 通信インターフェイス
3.2 機能要求
3.2.1 サブシステム 1
3.2.1.1 機能要求 1.1
.
3.2.1.n 機能要求 1.n
3.2.2 サブシステム 2
.
3.2.m サブシステム m
3.2.m.1 機能要求 m.1
.
3.2.m.n 機能要求 m.n
3.3 性能要求
3.4 設計制約
3.5 ソフトウェアシステム属性
3.6 その他の要求
付録
索引
上記の例で，3章は，要求仕様の本体である．ここはソフトウェアの特性に従って，いくつものパターンが，ガイドラインでは，付録において示されている．
(nil)