Top / 機能設計

機能設計

目次 †

機能設計 †

• ＝FD
• ＝外部設計
  • プロジェクトや会社によって呼び名が異なる。
• ソフトウェアの開発工程の1つ。

FD仕様書 †

• FD仕様書を書くときは一般に全体→詳細の流れで書く。
• FD仕様書に図を入れる。文だけだとMK,IT仕様書作成のときに漏れることがある。
• 取得する情報と管理する情報をわけて書く。
• 判定ロジックがかかれていないとBDの域を超えない。
  • このロジックなら必ずこう決まるという確認にもなる。
    • 判定ロジックがあれば判定パターンが網羅されているかを確認しやすいため。
  • 判定ロジックにはフローチャートが有効。
• いきなり例ありきはだめ。
  • 手順または定義の後に例があれば理解が深まる。
• 「そして」「もし」は使わない。
  • 「そして」→「その後」
  • 「もし」は削除。
• 刻々変わる（生存時間が短い）情報（＝状態）はクライアントが持ち続けない。表示のたびにサーバーに取りに行く。
  • 生存時間が長い（クライアントが設定しない限り変更されない情報＝設定）はクライアントが管理することも可能。ただし、他クライアントで設定される可能性があり、同期処理が入るならさらに考察をする。
• 機能ベースで書く。
  • 表示項目と設定項目は分けてかく。
• データ構造で設定と状態をわけておくと、設定がわかったら状態がどうなるというのが直観的にわかりやすい。
• シーケンス図は通信相手や通信の流れ（タイミングなど）に注目することに使用し、フローチャートはロジックに注目するときに使用する。
• 1つのイベントに対して、1つのシーケンス図を描く。
  • 関連がない複数の流れを描くと、それぞれの流れが連続しているように思えてしまうため。
• ITでやることを書く。
  • 性能要件はITでできないためFDには書かない。その免責のためにFDの最初の方に、性能要件はFDで書かないことを明言する。
• エラーケースのシーケンス図を書くときに、エラーが引き起こす原因とは関係ないOPTを記述すると読みにくくなるため、工夫する。

FDにおける注目する観点 †

• どういうときに状態が変わるか？
• それぞれの状態の説明
• 状態が変わるロジック
• 状態が変わったときの処理
• 管理している情報
  • どのタイミングで情報を更新するか