これはなに
上流工程(要求/要件定義、設計)、わからんので色々調べて腹落ちするところまで持って行った。そのアウトプットとして、まとめる。
ログは下記。
まとめ
要求定義、要件定義の枠組み
一般的な説明だと、要求定義は顧客のやりたいことを出すもので、要件定義はそこから対応できるものを出す作業。 これをもうちょい精緻に考えると、要求定義と要件定義は以下のような要素に分解できる(らしい)。
- 要求定義
- 「要求開発(Requirements Development)」
- 要求開発は要求を確定するプロセスであり、最終的に要求を明確にした「要求仕様書(SRS:Software Requirements Specification)」という文書をアウトプットする。
- さらに以下の要素に分かれる
- 「要求管理(Requirements Management)」
- ベースライン要求に対する追加や変更を管理するだけでは足りない。要求の適正な実現が進んでいるかも追跡しなければならない。
- 要件定義
- 下調べ
- 段取り
- 分析
- 定義
- ここまでが一般的な要件定義
- 承認と合意
- 管理と維持
- 要求定義における要求管理
(参考: 『生き残るために「要求エンジニアリング」を学ぶ』、『図解即戦力 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書』) ここで分かるのは、要求/要件定義のうち、概要で出てきたような作業は一部で、わりと他のタスクも付随すると考えられていること。 つまり、要求定義、要件定義、システム設計とほかの技量と境界を共有していて、明確に割り切れるものではないということ。
要求定義、要件定義、設計と隣接領域
上で分かったこととして、要求/要件定義には以下の隣接領域があること。
- プロジェクトマネジメント
- 要求管理とかがまさにそれ
- 開発手法
- WFかアジャイルか、みたいなのに影響を受ける。あとどういう契約でやってるかとかも。受託かインハウスかとか。
- アーキテクチャ
- これは後述。けど設計タスクでアーキテクチャの理解が求められるというのは想像に難くないとおもう
で、上流工程について学ぶとき、ここら辺をひっくるめた解説が多いように思う(個人の感想)。そうなるとスコープが広くなって、互いの位置関係も分かりにくくなるし、なにかとよくない。(おれ個人の話だけど、要件定義についての本を読んでなんかピンとこないことがおおいのはここら辺が理由として大きそう。なんでいまこの話してるの? となりがち) そういう余分なところを削ぎ落として、おれが(短絡的に)知りたいと思う上流工程のタスクについて解説したのが次の書籍。
わたしたちの知りたい上流工程
ソフトウェアソリューションはドメイン要件とアーキテクチャ特性からなる 『ソフトウェアアークテクチャの基礎』 第4章の冒頭
これは「機能要件と非機能要件」とも言い換えられる。おれが知りたい上流工程の技法って、このドメイン要件の整理方法だとおもう。
この3冊。シリーズもの。 はじめよう!プロセス設計はじめよう!要件定義はじめよう!システム設計
やっているのはプロセス設計(業務設計)、要件定義、システム設計。それぞれ書籍の感想を交えつつ雑に紹介すると、
- プロセス設計
- 仕事の設計
- どんな仕事が存在してて、どんなアウトプットを出すために、どんなインプットを、どう変換するのか? みたいなことをやっていく
- 仕事というのが本質的にどういうかたちの行為なのか? と整理されていて現実がきれいに整理されていく快感があった
- 要件定義
- 整理されたプロセスをプロセス単位ごとにITシステムにおこす
- 具体的にはIFDAM図と呼ばれる画面遷移図を書いて整理する
- DB定義とか機能の整理とかはあくまでおまけ、UI設計こそが要件定義だ! と言ってるのが面白かった
- システム設計
- IFDAM図ででてきた処理をアーキテクチャに適切に配置する
- これはわりとおまけのような内容。アーキテクチャスキルアッププロジェクトでやった内容を勉強した方が良い
- が、アーキテクチャと要件定義の関連性を知れてよかった
面白くてわりと軽く読めるので是非読んでもらえるといいんだけど、まあそんな感じです。
NA
- 次はアーキテクチャ
- とりあえずアーキテクチャの勉強をするモチベーションが上がったので、やりたいなとおもいました
- エアプ勢
- 色々かいたけど結局おれは上流工程エアプ勢だし、本物のアウトプット(製品)出してなんぼなので、やっていきたいなとおもいました
- みんなでやっていけたらもっといいなとおもいます
- (NAじゃないな? どうすればいいのかな?)