docs

設計ドキュメントを管理する。

フォルダ階層

docs
├── 01_画面      # Figma、画面アクション
├── 02_WebAPI   # openapi.yaml、API処理設計
├── 03_データ    # erd.a5er（ERD）、区分値
├── ...
└── README.md

設計書

• 01_画面
• 02_WebAPI
• 03_データ

コード体系

機能IDのコード体系は以下に従う。

種別	種別	例	備考
UIS	通常画面	UIS01、UIS02	UI Standard から
UIM	モーダル画面	UIM01、UIM02	UI Mordal から
API	Web API	API01、API02
IFS	システムI/F 送信	IFS01、IFS02	InterFace Send から
IFR	システムI/F 受信	IFR01、IFR02	InterFace Receive から
BAT	バッチ	BAT01、BAT02	BATch から
RPT	帳票	RPT01、RPT02	RePorT から

コード体系について補足:

• UISであれば、 UIS(0[1-9]{1}|[0-9]{2} といったフォーマットに従うこと
• Future Muscle Partnerのプロダクト規模であれば、機能数が爆発しないという想定で2桁とする
  • 万が一あぶれた場合、16進数と見なしてA~Fを導入する拡張を行う

機能IDの採番について注意点:

• 採番後の変更は許可しない
• 連番とする（数字部分に新しい体系を作らない）

画面設計書の記載方針

• Web API の応答項目が、画面項目のどこにマッピングすべきかという情報は、多くの業務画面で重要である
  • 理由は、類似名称の項目がWeb API応答項目にも画面項目多く、紐づけの認識の齟齬が生じやすいからである
• future muscle partnerにおいては、項目数は多くなくFigmaを見れば自明であるため、画面項目定義を省略する