要件定義と基本設計で決めなきゃいけないこと

突然要件定義と基本設計で決めなきゃいけないこと洗い出してーと言われて困ってしまった。
僕はその工程の経験ないんだけど・・・とも言えずに付け焼刃的に勉強した内容をまとめてみる。

個人的に今後ブラッシュアップできればいいなあと思う記事。
必要なドキュメントの洗い出しや自分の作業漏れのチェックに使っていきたい。

要件定義

システム化する業務の背景や現状などなど。
例えば、ニーズも高まっているし、経営戦略の一つとして、なんちゃら管理システムを刷新したいみたいな。
いわゆる導入部分。でもここがちゃんとしていると途中からプロジェクト入ってきた人でも話が頭に入ってきやすい。

システム化対象の業務が抱える課題
例えば、この業務自動化すると楽になって、別の業務に集中できるようになる。発注管理を楽にして接客に集中とか、
画面の文字ちっちゃくておじさんには読みにくいんだけどとか

システム化する目的や解決方針、こんなシステムを導入して、日頃の業務を楽にしちゃいたい！とか、
おじさんにもわかりやすい画面にしたい

システムの概要や特徴、こんなふうに自動化するよとか、センサーや機器導入してこうなるよとか

システムが持つ機能の概要のこと。教科書的な表現をするなら機能要求と非機能要求も決めておく。
例えば、アマゾンのレコメンド機能つくるぜとか、レスポンスはこれくらいのスピードでとか。

システム化する業務や機能の範囲、こっから先はコンピュータよりおじさんの方が効率的だからシステム化しないよとか
なんかここは明らかに揉めそうなので、しっかり決めておこう。

システムで用いるユーザーインターフェースのイメージ
デザインはこんな基準で作るよ

システムの色々な構成、ハードウェア、ソフトウェア、ネットワークなどなど
フレームワークこんなん使うよとかサーバー構成こんなんだよとか残さないと開発メンバーが消え失せたあとが地獄。

システムの導入時期や既存システムの移行方法、いつごろまでにシステムリリースするよとか決めておくとよい。

システムの運用や保守の体制や方法など、何時くらいまでにこの機能を停止するよ動かすよとか、障害発生した時はどうするよとか

使用策定、設計、開発、テスト、導入などの主要な作業の完了時期。
これも、いつごろまでに何を終わらせるよ系統の話だね。この時点ではもちろんあんまり細かく引けないだろうけど

開発をすすめる際の人的体制や作業環境などをどこの誰がやるか

顧客に納入する文書やプログラムの一覧を決めておくといいんじゃないかと、設計書やソースはもちろん、
マニュアルとか作る作らない決めておこう。

開発フローやルールなど、作業が標準化されているのは個人的に心地よいので、
この時点ですでに詳しく決まっているといいなぁと思う。

テスト方法やバグ発生の収束を判断する基準など

業務の流れとシステム化範囲を見極める、アクティビティ図のイメージなのだろうかね

分割した機能の一覧、このシステムにざっくりどんな機能があるのかな？とかわかるようにする
サブシステム分割して分担して設計開発するためにも必要かも

画面が果たす業務内容、UIのざっくりしたイメージじゃなくもう少し細かい見た目

画面同士の移り変わりを見るために必要だよね

帳票もお客さんに見てもらう必要はあるよね。個人的には帳票設計は結構好き

コードや区分の意味などを整理する。この一覧は保守でよく使うから絶対作って欲しいんだがね。
一覧作らない場合はしっかり共通化したりソース設計しておいてほしいところ。

テーブルのリレーションを整理する。最近ER図がないプロジェクトにアサインされ驚愕している。
一体これ作らないでどうやってシステム作ったんだよ・・・

このテーブルはいつどんな感じで使われるかを整理する、あとあとの影響調査のインプットにも使えるよね
あとはサブシステム分割とかに使えるらしいけど、イメージわかないなぁ。

外部システムと連携するためのファイルとか
他のシステムにも迷惑かかるから早めに決めておきたい

詳細設計については特に記載していない。多分使う技術によって違うだろうからね。
あとはドキュメントで詳細設計資料管理するか、ソースをきれいに書いて設計書のメンテをしないかなど
方針も結構別れるような気がするので、標準化は難しそうだ。