プロジェクトの炎上を防ぐためにSEが「要件定義」で気をつけたい4つのこと - paiza times
Photo by Amtec Photos こんにちは。倉内です。 システム開発の上流工程の1つに要件定義という工程があります。 要件定義はプロジェクトの成功・失敗を左右すると言われるほど重要な工程で、炎上したプロジェクトをあとで振り返ってみると「要件定義が甘かった……」と思い当たることが多いです。 要件定義が難しいのは、ユーザーの漠然とした課題や要望を引き出してシステム要件として定義するという性質上、プロジェクトごとの違いが大きく、明確な正解というものが存在しないことにあると思います。 しかし、要件定義をおろそかにするとシステムで何を実現しなければならないかがはっきりしないままプロジェクトを進めることになり、設計・開発・テスト…あとのすべての工程で困ることになります。 そこで今回は、なんとなくでやる要件定義はやめて、プロジェクトを炎上させない要件定義を実施するために気をつけたいことをお伝
機能要件設計書だけで20種類
意図が伝わる設計書を作るには，前提として「それぞれの設計書がどういう役割を担うか」「それぞれの設計書が相互にどういう関係にあるか」を正しく理解しておくことが重要である。豊富なサンプルとともに，設計書の役割と関係，さらには書き方のコツを解説する。 石川貞裕 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 担当本部長 向坂太郎 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 「基本設計書」と聞いて，どんなものをイメージするだろうか。業務フロー図や画面レイアウト，E-R図など様々だろう。大規模，高品質のシステムを開発するなら，図1に示すような多くの設計書を作成することになる。 中心となる機能要件設計だけでも20種類。それぞれの役割や関係をきちんと理解し，過不足なく設計情報を盛り込むことが求められる。 難しいのは，設計書の読み手が開発者だけではないことだ
要求仕様（要求工学：第3回）
概 要 今回はIEEE830[１]に基づいてソフトウェアに関する要求仕様の標準的な構成例を紹介しよう。立命館大学の大西教授と山梨大学の郷助教授による「要求工学」[２]の第４章でもIEEE830が解説されている。 IEEE830では表1に示すように要求仕様を、目次、はじめに、要求仕様の一般的な説明、要求仕様の具体的な説明、付録、索引から、構成することを推奨している。 IEEE830 では、ソフトウェアをシステムの一部であるとしており、システムの要求仕様とソフトウェアの要求仕様を区別するためソフトウェア要求仕様（ Software Requirements Specification）を略してSRSと記述する。これに対してシステム要求仕様をSyRSと略記する[３]。本稿ではSRSについて解説する。 表1 IEEE 830 による要求仕様の構成 SRS 第1章「はじめに」 「はじめに」ではSRS
要件定義書の作成手順を学ぶ！アイデアを形にするプロセスとは
Webサービスやアプリを複数人で開発する上で大事なのが要件定義。その作成手順についてシミュレーションしながら紹介しています。アイデアをどういう流れでワイヤーフレームに落とし込み、形にしていくのか理解できるでしょう。 テックアカデミーマガジンは受講者数No.1のプログラミングスクール「テックアカデミー」が運営。初心者向けにプロが解説した記事を公開中。現役エンジニアの方はこちらをご覧ください。 ※ アンケートモニター提供元：GMOリサーチ株式会社 調査期間：2021年8月12日～8月16日 調査対象：2020年8月以降にプログラミングスクールを受講した18～80歳の男女1,000名 調査手法：インターネット調査 本稿は、Smashing magazineのブログ記事を許可を得て日本語翻訳し掲載した記事になります。 本記事は、モバイルアプリ開発の会社のCEO Eduard Khorkov氏に
System Requirements Specifications
システム要求仕様書の書き方 IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specificationより Table of Contents (目次) 1. Introduction (はじめに) SRSの「はじめに」では、SRS全体の概要を書く。 1.1. Purpose (目的) この小節では SRSの目的を描写する SRSが意図する聴衆を指定する 1.2. Scope (範囲) この小節では これから作るソフトウェア成果物に名前を付ける このソフトウェア成果物が何であるか(必要ならば、何でないか)を説明する 指定されたソフトウェアの適用について、対応する利点、目的、目標を含めて記述する もし上位レベルの仕様書(例えばSyRS)があれば、同様の記述と矛盾がないようにする 1.3. Def
「要件定義書のアウトライン作成」完全マニュアル
他の文書と同様、要件定義書はまず文書全体のアウトライン（骨格、構成）をしっかり作り上げてから内容を記述します。今回は、読みやすく分かりやすい要件定義書にするためのアウトライン作成方法を紹介します。 階層構造で読みやすい文書にする 要件定義書を作るためには、全体を大見出し＝中見出し＝小見出し（章＝節＝項）の階層構造にします。 「大見出し」「中見出し」「小見出し」の数を、それぞれ5から10程度にするのは、前回（第3回「分かりやすい提案書はアウトラインが美しい」）紹介した提案書と同様です。見出しの数が多すぎると、読み手が文書の全体像を把握できなくなります。また、1つの項目の記述量を1ページ内に収めるようにします。 要件定義書を構成する項目 要件定義書に必要な大見出しの項目としては、次のようなものが挙げられます。 システムの概要／システムの構想 機能要求 入力要求と出力要求 システム導入後の業務フ
Borland Caliber DefineIT
設計、コーディング、テストなど、システム開発は急ピッチで効率化が進められてきた。だが、最後まで残っているのが「要件定義」だ。あいまいで不十分な要件は、「作業の手戻り」、「プロジェクトの遅延」、「予算オーバー」、「機能不足」、「使い勝手の悪さ」の問題を引き起こし、失敗プロジェクトに直結する原因となる。さらに、要件の間違いは手戻り作業を引き起こす最大の原因であり、手戻り作業がプロジェクト全体における開発作業の40%にまで及んでいるという。 開発側、それを使うユーザー側、投資を判断する経営側。それぞれのコミュニケーションギャップがプロジェクトの失敗に直結している。日本語のあいまいさ、誤解に基づいた仕様定義、分厚く難解な仕様書……、そして最後には言った言わないのなすりあいが始まる。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
