/note/tech

既存システムから分析する場合、まずはシステムの特徴を理解することが大事

仕様と実装といっても、仕様など明確になっていることはない

仕様は現場の規約、契約、意思決定条件、既存システム内の条件などから導き出される

規約、契約などで明文化されている場合はいいが、多くの場合、仕様として明確になっていない

@zenzengood

現場の意思決定(仕事の流れ)から仕様を考える例

開発時間がないのでここは手処理とした部分があり

そこにキャンセル処理などが発生した場合、手処理部分のリカバリーも手処理となり、そこでの判断は本来の仕様にはならない

単純に業務フローの分析を行うとこの見極めが難しい

ただ複雑なものに見える

@zenzengood

既存システムから分析する場合

まずはシステムの特徴を理解することが大事

・エントリー系:人事システムなど

・プロセス形成系:販売から納品までのシステム

・プロセス監視系:工場の操業管理など

・大量のデータ系:課金や給与などの大量バッチのシステム

システム特性から分析のアプローチが変わる

@zenzengood

仕様を明らかにするためにシステムを分析するときは、ソースコードではなく、システムを使った業務が回るための決め事を分析することが有効

そのためにはドメインの構造化とそれにともなうバリエーションの整備、状態の明確化が有効

@zenzengood

システムの特徴により、以下の3つの重要度が変わる

・ドメインの構造化

・バリエーションの整備(条件の整備)

・状態の明確化

上記の要素を組み合わせて仕様を語る

@zenzengood

1.ドメイン構造 2.状態の明確化 3.バリエーション・条件整備

・エントリー系: 1-3-2

・プロセス形成系:1-2-3

・プロセス監視系:1-2-3

・大量データ系: 3-1-2

どれも必要だがシステムの特徴によって分析の力点を変え、仕様の表現方法を変える

@zenzengood