仕様と実装といっても、仕様など明確になっていることはない
仕様は現場の規約、契約、意思決定条件、既存システム内の条件などから導き出される
規約、契約などで明文化されている場合はいいが、多くの場合、仕様として明確になっていない
現場の意思決定(仕事の流れ)から仕様を考える例
開発時間がないのでここは手処理とした部分があり
そこにキャンセル処理などが発生した場合、手処理部分のリカバリーも手処理となり、そこでの判断は本来の仕様にはならない
単純に業務フローの分析を行うとこの見極めが難しい
ただ複雑なものに見える
既存システムから分析する場合
まずはシステムの特徴を理解することが大事
・エントリー系:人事システムなど
・プロセス形成系:販売から納品までのシステム
・プロセス監視系:工場の操業管理など
・大量のデータ系:課金や給与などの大量バッチのシステム
システム特性から分析のアプローチが変わる
仕様を明らかにするためにシステムを分析するときは、ソースコードではなく、システムを使った業務が回るための決め事を分析することが有効
そのためにはドメインの構造化とそれにともなうバリエーションの整備、状態の明確化が有効
システムの特徴により、以下の3つの重要度が変わる
・ドメインの構造化
・バリエーションの整備(条件の整備)
・状態の明確化
上記の要素を組み合わせて仕様を語る
1.ドメイン構造 2.状態の明確化 3.バリエーション・条件整備
・エントリー系: 1-3-2
・プロセス形成系:1-2-3
・プロセス監視系:1-2-3
・大量データ系: 3-1-2
どれも必要だがシステムの特徴によって分析の力点を変え、仕様の表現方法を変える