要件定義、要件定義書作成、基本設計、レビューの仕方、テストの仕方などの記事まとめ紹介
これまでシステム開発における要件定義、要件定義書作成の方法、要件定義と基本設計の違い、設計レビューの仕方、テストの仕方などの解説記事を投稿しており、沢山の方に読んでいただいております。
ここではこれらの記事のまとめ、ダイジェスト版を紹介した上で、もっと詳しく知りたい方にそれぞれの項目にリンクできるようにしました。お役に立てば幸いです。
目次
1．要件定義とは何か？MECEとの関係や、要求定義との関係を解説した記事
要件定義とは何か？をまずはきちんと説明しています。また要件定義を緻密に行なうための方法として、MECEという考え方について解説しています。
要件定義という言葉において、”要件”とは何かという言葉の定義にも拘って説明してます。
さらに、要件定義と別に要求定義という言葉が有り、非常に紛らわしく、混同している方も多い中で、要求定義と要件定義の違いについて解説しています。
詳細は以下をご覧ください
↓
2．要件定義の流れと、要件定義書の作成の仕方を解説した記事
この記事では、要件定義の流れと、要件定義書の作成の仕方について解説します。要件定義を進める流れを解説した中で、要件定義書の作成について解説しています。
要件定義書の位置づけ、及ぶ範囲、記述する内容として、大きく業務要件、機能要件、非機能要件の3つあることを解説しています。それぞれの3つの要件の内容も詳しく解説しています。
詳細は以下をご覧ください
↓
3．システム開発での要件定義と基本設計の違い及び要件定義の作業内容について解説した記事
この記事では、わかりにくいと言われる要件定義をわかりやすく解説すると共に、要件定義の次の工程として位置づけられる基本設計との違いを解説していきます。
要件定義、要求定義の意味を説明した上で、なぜ要件定義がわかりにくいかといったことに触れています。
かつ要件定義という仕事がこの30年間くらいで明確なフェーズとして定着してきたことについても解説しております。
さらに要件定義と次の工程である基本設計の違いについて説明しています。
そして、要件定義で行なうべき作業 および 基本設計で行なうべき作業について解説しています。
詳細は以下をご覧ください
↓
4．システム開発において要件定義、設計と共に重要なテスト計画、テストの進め方について解説した記事
この記事では、システム開発におけるテストに関する考え方と、テストの進め方について解説します。
テストに関する基本的な考え方について５つの基本的な考え方として、
1）テストは、発注者側＝商品を発売する側も必ず行うこと
2）商品、システムを使う人の立場に立ったテスト=ブラックボックステスト＝システム（総合）テストを必ず行うこと
3）元々の発注側からの要求仕様を満たしてるかの確認は必ず行うこと。
4）ブラックボックステストにおいては、通常の使い方に加えて、準正常系、異常系のテストも行うこと。
5）開発委託側は、発注側にシステム（総合）テストを行ってもらうために、単体テスト、結合テストを十分に行うこと
を解説しています。
また、発注側で行うべきテスト、委託側で行うべきテストの区分けを行なっています。
次に、テスト計画の立案＝テスト計画の設計のための３つのステップを記しております。
ステップ１：テストの目的を明確にする＝テストの内容を定義する
ステップ２：テストの目的を達成するためにはどのように行っていくかを考える→テストアプローチの策定
ステップ３：テストアプローチを実現するために必要な体制とテストスケジュールを立案する
さらにテストケースの作成＝テスト仕様設計の作成の仕方を説明しています。
詳細は以下をご覧ください
↓
5．システム開発設計全体の流れ～要件定義、設計、実装、テストまで～および発注側と開発委託会社の役割分担について解説した記事
この記事では、そういったシステム開発設計の流れの基本を紹介すると共に、システム開発においては一般に発注側と開発委託会社に別れると思いますので、それぞれの役割分担について解説します。
まず、システム開発設計におけるV字型モデルを示しています。
実際には一番左上の要求仕様から始まり、要件定義、基本設計、詳細設計、実装と進んだ後、単体テスト、結合テスト、総合テスト、受入テストといったテストのフェーズを経て商品を出荷するというのがシステム開発設計の一連の流れになります。
V字型モデルで無く、それぞれの工程を下へ下へと表す開発設計の流れ図もあります。それは滝のように流れる、という意味でウォーターフォールモデルと言われており、このモデルの方が一般には有名です。
そのうえで、開発発注側と開発委託会社の役割分担について解説しています。
発注側の役割は要求仕様を作ることと、総合テスト、受入テストを行なうのがメインとなります。
ただし、要件定義、設計、実装、単体テスト～結合テスト については何も行なわずに開発委託会社に任せっきりで良いか？と言えばそんなことなくて、レビューが大切だと言うことも解説しています。
詳細は以下をご覧ください
↓
6．システムの要求定義～開発設計におけるレビューの重要性について解説した記事
この記事はレビ重要性重要性について解説しています。
レビューに関しまして、結構学問的に、理論的に記述された文献などはあるのですが、意外なほど開発設計現場に密着した形で書いているものが少ないので、この記事では、できる限り現場目線で、開発の各フェーズでレビューをどのように行なえば良いのかについて解説しています。
レビューの詳細の前に、開発設計全体において、開発委託先側、発注者側それぞれが行なうことを記します。
開発委託先側が行なうべきこととしては、開発スケジュールにおいて、要件定義⇒基本設計（システム設計）⇒詳細設計⇒実装⇒単体テスト⇒結合テストまでは間違いなく開発委託先側行なうべき業務となります。
開発発注者側が行なうべきこととしては初めの要求仕様の提示から始まり、要件定義内容の承認を経て、最終的にシステムが出来上がってきたときの総合テスト、出荷などが開発発注者側の役割で有ることは間違いありません。
さらには要件定義～結合テストにいたる工程において丸ごと開発委託先にお願いして何も行なわないのでなく、開発委託先が行なう設計やテストの内容についてレビューを実施し、その工程の成果について検収することが極めて重要になります。
開発発注側がその分野の専門家でなかったり経験が浅かったとしてもレビューを行なうことが重要であることを説明しています。
そのうえで、レビューとは何かと言うことで、設計フェーズにおいて各フェーズ毎に、そのフェーズで行なうべき作業が完了したかどうかを、設計ドキュメントなどに基づいて設計者から説明を受け、その内容について質問や指摘をしてた上で、次のフェーズに移って良いかを見極めること と定義しています。
詳細は以下をご覧ください
↓
7．システム開発の要件定義～開発設計におけるレビューの具体的なやり方について解説した記事
この記事では、システム開発において、要件定義から開発設計におけるレビューの具体的なやり方について紹介しています。
以下のフェーズそれぞれでレビューを行なうことが必要であると説明しています。
・要件定義フェーズ
・基本設計フェーズ（システム設計フェーズ）
・詳細設計フェーズ
・単体テストフェーズ
・結合テストフェーズ
またレビュー全般について以下の3つが重要であることを記しています。
1）レビューのためのチェックリストを作り、チェックリストに基づきレビューを行なう。
2）レビューのたびに、必ず議事録を作る
3）レビュー後のアクションアイテムを明確にすること
ハートテクノロジーズ株式会社では、システム開発・要求仕様・要件定義・設計などについてのお困りごとをお聞きする30分～60分くらいのオンライン無料相談会を実施しております。
もしご希望の方は、以下の問い合わせフォームの”問い合わせ”欄に【無料相談会希望】と書いていただき、かつ可能であれば現在のお困りごとを書いていただければ幸いです。折り返しご連絡させていただきます。以下をクリックしてお申し込みくださいませ。
関連記事
↓
関連記事
↓