331
330

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

要求定義と要件定義の違いを考える

Last updated at Posted at 2016-11-02

要求定義と要件定義についての記事というのは需要があるようですね。
検索されるだけなのか?そもそも話し合いの中では、その「定義」を確定して、話しておくことが大事なのですよね。言語を学ぶ上で、まずはひらがなからカタカナからそしてローマ字など文字を学ぶように、プログラミング用語や現場で使う単語などというのは意識して使っていかないと追いつけなくなってしましますからね。
役割分担、期日を決めるなどマネージメントの方もプロジェクト進行では、考えていきたいですね。

最近の近況

バーチャルな世界に興味があり、バーチャルSNSなどにも顔を出しながら作業してます。

はじまり

はぁ…

なんでシステム開発が失敗するんだろう…

仕様の変更が多くて…

言った言ってないのトラブルから避けたい…

システム動かしてみても全然使えない…

実は..

事業運用をオペレーションレベルに展開しないままに、
システム開発をしてしまうところに原因があります。

入力画面や出力を決めても…
それを使って、いかに日々の仕事をこなすのか?

オペレーションレベルまで突き詰めた創りこみをしないで、専門家だから、プロだからと...コンピュータの専門家に、業務運用の仕組みまで丸投げにしてしまうことが問題になります。

要求定義と要件定義の違いについて

 ・ビジネス
============
事業運用オペレーション
ユーザーインタフェース
============

要求定義
・「〜したい」と利用者側の希望、ビジネスで何が必要なのかなどを記載したもの

 ・システム
============
アプリケーション
パッケージ
データベース/通信/...
============

 ・IT技術
============
データベース/通信/...
OS
ハードウェア
============

要件定義
・「〜が必要」システムの仕様書、システムが何をしなければならないかなどを記載したもの

要求定義と要件定義の違いを考える

どの会社でも、コンピュータのシステムを導入しています。
実績のあるパッケージソフトの導入なら問題ありませんが、自社のシステムを開発するとなると失敗などがあります。

特に、経験の少ないSEが担当した場合や無理な要求をした場合に失敗する可能性が高まります。

その原因は何なのでしょうか?

そこで重要となるのが、システム化の「要求」を正しくSEに伝えるということです。

SEは、エンドユーザーの要求を正しく掴まないと...
要求を出発点とするシステム開発を成功させることができません。
システム開発には、ユーザーの要求を正しくつかみ、技術者が開発のために必要な要件定義を作成することが大切です。

開発には、要求を「どんな資料で、どうまとめる」のでしょうか?
要求定義と要件定義の関連は、どこにあるのでしょうか?

●要求定義

  • 「~がしたい」 利用者の希望
  • ビジネスで何が必要かを記述したもの
  • 事業運用をオペレーションレベル考えそれを実現する
  • コンピュータシステムへの要求

●要件定義

  • 「~が必要」システムの仕様書
  • システムが何をしなければならないかを記述したもの
  • システムの機能やDB・通信などの利用方法

要求定義が変更されると要件定義の変更が必要となります。

事業の方針が変わると、オペレーションが変わります。
オペレーションが変わるということは、画面や帳票などの
インターフェースの変更が必要となります。

ですから、システム開発をする時は...
具体的なオペレーションレベルで、作業の「仕組み」を捕えていないと、
「要求定義」が抽象的なものになります。

業務の運用の仕組みが抽象的なままだと..
担当SEの、その業務経験や能力、得意・不得意で、作成する「要件定義」が違ってきます。

ここが問題なのですね。
システム成功の要件は、担当SEの経験と能力任せ..
これでいいのでしょうか?

システム開発を3つの区分に分けると考えやすくなります。

  • ビジネス
  • システム
  • IT技術

システム開発の現場では、この3つのレベルを一緒に論じがちです。
これは、全く別の能力です。全てに精通する人はいません。

「要求・要件」を追跡できる仕組みが必要

ビジネスの運用方針が変わった変わった..

  • システムのどこを修正すべきか?

システムに問題が出た..

  • その問題は、ビジネスのどこに影響があるか?

ビジネス環境は変化しています。
システムの開発環境も変化しています。

今、最良と思えるシステム開発ができたとしても、
そのまま使い続けることはできません。
常に改良を加えていく必要があります。

その時に...

要求と要件を追跡する仕組が無いと..
プログラムのソースリストを追いかけることになります。
途方もない労力がかかります。
そして、成功率はかなり低くなります。

開発ドキュメントには2つ必要です。

  • ビジネスの構造をオペレーションレベルで示すもの
  • システム開発を行うSEが利用するもの

※ 両方をそろえることがこれからの開発には必要です。

要求定義

(利用者が求めるシステムの機能)

###ビジネスの「要求」
ビジネスの基本設計
ビジネスの詳細設計
(ビジネスのオペレーション)

要件定義

(開発されるシステムの機能・仕様)

システム開発の設計仕様

  • システムの基本設計書
  • システムの詳細設計書

ソフトウェア

ビジネスの要求によって変化しやすいソフトウェアの要件を追跡管理していく環境を築く

文章から双方向で追跡できる環境を築く

方針決定
開発の範囲や手順

導入例・開発例の意見の一致

システムの品質 をよくしていくことにもつながります。

関連情報

関連サイト


投稿情報

投稿日 2016年11月02日
更新日 2021年04月17日
確認日 2022年11月02日

  • NEWS 227625 views
  • 2021 祝17万pv突破しました。
  • 2021.4.17 祝19万pv突破しました。
  • 2021.6.22 祝20万pv突破しました。
  • 2025.6.6 祝24万pv突破しました。

めっちゃみてくださってますね。
ありがとうございます。

関連記事


制作チーム:サンストライプ

sunstripe_logo.png
http://sunstripe.main.jp/

331
330
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
331
330

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?