ずっと受けたかったソフトウェアエンジニアリングの授業〈2〉 ...第9章を読んでみた

システム要件定義

①内容まとめ

システム要件定義を行い、システム要件定義書を作成するための方法

②認識のズレ、印象

認識のズレで大きかったのは、開発計画書の存在について。顧客とベンダは対等で、協働してシステムを作り上げる立場にあるはず。本来はそうなのだ

割と当たり前のことができていないことってあるんだろうなと反省した。特に、「ユーザーや顧客の立場を考えること」「まずは聞き役に徹すること」が私の課題点のように思える

③不明ワード

【ユーザー要求書】(p80)

実際にそのシステムを使う人が何をして欲しいのか、何に困っているのかの話を聞いてまとめたもの

【システム要件定義】(p81)

ユーザーの要求を分析し、システム化の対象となる範囲を決定すること

具体的にはユーザーをとりまくビジネス環境の定量的および定性的分析に始まり、ユーザーの困りごとを抽出する。その中でシステム化することにより収益の向上が予測される範囲をシステム化の対象となる範囲として決定する

【システム要件定義書】(p81)

システムのスコープを決定し、これをまとめたもの。システム化によって現行の業務がどのように変わるのかを示した業務フロー図や機材、コスト、大まかな導入スケジュールなども記載する

→【システム提案書とシステム要件定義書の違い】

システム提案書は顧客の困りごとに沿った具体的な「提案をするため」の文書

システム要件定義書は、顧客とベンダとの間で明確な「認識のすり合わせを行う」ための文書。外部設計書、内部設計書の基になる文書。

【アクティビティ図】(p82)

ある作業の開始から終了までの機能を、実行される順序どおりに記述した図

参考: https://cacoo.com/ja/blog/what-is-activity-diagram/

【開発計画書】(p83)

ベンダが顧客からのシステム化の依頼を受注して良いかの判断を行うための資料。5W2Hで記載する。システム提案書の逆。ベンダ側に受注の選択権がある

【5W2H】(p83)

Why(なぜ受注するのか)、

What(何を作成するのか)、

 Where(どこで作業するのか)、

Who(誰が担当するのか)、 

When(どのようなスケジュールで進めるのか)、

How(どのように進めるのか)、

How Much(いくらかかるのか)