System-analysis-and-design-planning

提供:Dev Guides
移動先:案内検索

システム分析と設計-システム計画

要件決定とは何ですか?

要件は、データの処理またはキャプチャ、ビジネスアクティビティの制御、情報の生成、管理のサポートなど、新しいシステムの重要な機能です。

要件の決定には、既存のシステムを調査し、詳細を収集して、要件とは何か、それがどのように機能するか、どこで改善を行うべきかを調べることが含まれます。

要件決定における主要な活動

要件の予測

  • 新しいシステムの特定の問題や機能、要件など、以前の経験に基づいてシステムの特性を予測します。
  • そうしないと、経験の浅いアナリストが気付かない領域の分析につながる可能性があります。 しかし、調査を実施する際にショートカットが取られ、バイアスが導入された場合、要件予測は中途半端になります。

要件調査

  • 現在のシステムを調査し、さらなる分析のためにその機能を文書化しています。
  • アナリストがファクトファインディング技術、プロトタイピング、コンピューター支援ツールを使用してシステム機能を文書化および説明するシステム分析の中心です。

要件仕様

  • これには、要件仕様を決定するデータの分析、新しいシステムの機能の説明、および提供される情報要件の指定が含まれます。
  • これには、事実データの分析、必須要件の特定、および要件達成戦略の選択が含まれます。

情報収集技術

事実発見技術の主な目的は、ユーザーが理解する正確なSRSを準備するためにアナリストが使用する組織の情報要件を決定することです。

理想的なSRS文書は-

  • 完全で、明確で、専門用語がないこと。
  • 運用、戦術、および戦略の情報要件を指定します。
  • ユーザーとアナリストの間で起こりうる紛争を解決します。
  • 理解と設計を簡素化するグラフィカルな支援を使用します。

さまざまな情報収集技術があります-

インタビュー

システムアナリストは、面接により個人またはグループから情報を収集します。 アナリストは、フォーマル、法的、政治的、または非公式のいずれかです。インタビューの成功は、インタビュアーとしてのアナリストのスキルに依存するためです。

それは2つの方法で行うことができます-

  • 非構造化インタビュー-システムアナリストは、システムの基本情報を取得するために質疑応答セッションを実施します。
  • 構造化されたインタビュー-クローズ(客観的)またはオープン(記述的)形式で回答する必要がある標準的な質問があります。

面接の利点

  • 多くの場合、この方法は質的情報を収集する最適なソースです。
  • 書面で効果的にコミュニケーションをとらない人や、アンケートに回答する時間がない人にとっては便利です。
  • 情報は簡単に検証され、すぐにクロスチェックできます。
  • 複雑なテーマを処理できます。
  • 意見を求めれば、重要な問題を簡単に発見できます。
  • 誤解のある分野のギャップを埋め、将来の問題を最小限に抑えます。

アンケート

この方法は、多くの人からシステムのさまざまな問題に関する情報を収集するためにアナリストによって使用されます。

アンケートには2種類あります-

  • 自由回答形式の質問票-簡単に正しく解釈できる質問で構成されています。 問題を調査し、特定の回答の方向に導くことができます。
  • クローズドエンドのアンケート-システムアナリストがすべての可能な回答を効果的にリストするときに使用される質問で構成されます。これらは相互に排他的です。

アンケートの利点

  • 同じ場所にいないユーザーの興味、態度、感情、信念を調査するのに非常に効果的です。
  • 特定のグループのどの割合が提案されたシステムの特定の機能を承認または不承認にするかを知ることは、状況において役立ちます。
  • システムプロジェクトに特定の方向性を示す前に、全体的な意見を判断することが役立ちます。
  • より信頼性が高く、正直な回答の高い機密性を提供します。
  • 事実情報を選択し、メールで送信して郵送できる統計データの収集に適しています。

記録、手順、およびフォームのレビュー

既存の記録、手順、およびフォームのレビューは、現在のシステム機能、その操作、またはアクティビティを記述するシステムへの洞察を見つけるのに役立ちます。

メリット

  • ユーザーが他の人に課す前に、ユーザーが自分で組織または運用に関する知識を得るのに役立ちます。
  • 手順マニュアルとフォームが現在のシステムの形式と機能を説明しているため、短時間で現在の操作を文書化するのに役立ちます。
  • 組織で処理されるトランザクションについて明確に理解し、処理のための入力を識別し、パフォーマンスを評価できます。
  • アナリストがサポートする必要のある操作に関してシステムを理解するのに役立ちます。
  • 問題、その影響を受ける部分、および提案された解決策について説明します。

観察

これは、人、イベント、オブジェクトに気づき、観察することで情報を収集する方法です。 アナリストは、組織を訪問して現在のシステムの動作を観察し、システムの要件を理解します。

メリット

  • これは、情報を収集するための直接的な方法です。
  • 収集されたデータの信頼性に問題がある場合、またはシステムの特定の側面の複雑さがエンドユーザーによる明確な説明を妨げる場合に役立ちます。
  • より正確で信頼性の高いデータが生成されます。
  • 不完全で古くなったドキュメントのあらゆる側面を生成します。

共同アプリケーション開発(JAD)

IBMによって開発された新しい手法であり、所有者、ユーザー、アナリスト、デザイナー、およびビルダーが、組織化された集中的なワークショップを使用してシステムを定義および設計します。 JADは、専門的なスキルを備えたワークショップのファシリテーターとして、アナリストを訓練しました。

  • JADの利点*
  • 従来のインタビューとフォローアップ会議の数か月を置き換えることにより、時間とコストを節約します。
  • 共同の問題解決をサポートする組織文化で役立ちます。
  • 複数レベルの従業員間の正式な関係を促進します。
  • それは創造的にデザインの開発につながる可能性があります。
  • 迅速な開発を可能にし、情報システムの所有権を改善します。

二次研究またはバックグラウンドリーディング

この方法は、収集された情報にアクセスして情報を収集するために広く使用されています。 これには、マーケティング担当者が内部または外部ソースから使用した以前に収集された情報が含まれます。

メリット

  • インターネットが利用できるため、よりオープンにアクセスできます。
  • 低コストと時間で貴重な情報を提供します。
  • 一次研究の先駆けとして機能し、一次研究の焦点を調整します。
  • 研究者は、使用する手順とそれらを収集する際に問題があるため、研究に価値があるかどうかを結論付けるために使用します。

実現可能性調査

実現可能性調査は、システムの調査が開発に適しているべきかどうかを経営者が決定するのに役立つ予備調査と考えることができます。

  • 既存のシステムの改善、新しいシステムの開発の可能性を特定し、システムのさらなる開発のための洗練された推定値を生成します。
  • 問題の概要を取得し、実行可能または適切な解決策が存在するかどうかを判断するために使用されます。
  • 実行可能性調査の主な目的は、問題を解決するのではなく、問題の範囲を取得することです。
  • 実現可能性調査の結果は、提案されたシステムの完全な性質と範囲を含む決定文書としての正式なシステム提案行為です。

実行可能性分析に含まれるステップ

実行可能性分析を実行しながら、次の手順に従う必要があります-

  • プロジェクトチームを編成し、プロジェクトリーダーを任命します。
  • システムのフローチャートを作成します。
  • 現在のシステムの欠陥を特定し、目標を設定します。
  • 目標を達成するために、代替ソリューションまたは潜在的な候補システムを列挙します。
  • 技術的な実現可能性、運用上の実現可能性など、各代替案の実現可能性を判断する
  • 各候補システムのパフォーマンスと費用対効果を重視します。
  • 他の選択肢をランク付けし、最適な候補システムを選択します。
  • 承認のために経営陣に最終プロジェクトディレクティブのシステム提案を準備します。

フィージビリティ分析

実現可能性のタイプ

経済的実現可能性

  • 費用/便益分析法を使用して、候補システムの有効性を評価しています。
  • これは、組織にとってのメリットとコストの点で、候補システムからの最終的なメリットを示しています。
  • 経済的実現可能性分析(EFS)の主な目的は、投資ファンドが提案にコミットする前に候補システムの経済的要件を推定することです。
  • 候補システムの開発に伴う最低レベルのリスクに加えて、早期かつ最高の資金回収により組織の純資産を最大化する代替案を好みます。

技術的実現可能性

  • 各実装の代替案の技術的実現可能性を調査します。
  • ソリューションを既存のテクノロジーでサポートできるかどうかを分析および決定します。
  • アナリストは、新しい要件を満たす現在の技術リソースをアップグレードするか追加するかを決定します。
  • 候補システムは、技術的な拡張をサポートできる範囲で適切な応答を提供します。

運用可能性

  • システムが開発および実装されると、システムが効果的に動作しているかどうかを判断します。
  • 管理者は、提案されたシステムと、現在の組織環境で実行可能なそのシステムをサポートする必要があります。
  • ユーザーが影響を受けるかどうかを分析し、システムのメリットに影響する可能性のある変更または新しいビジネス手法を受け入れます。
  • また、候補システムのコンピューターリソースとネットワークアーキテクチャが実行可能であることを保証します。

行動の実現可能性

  • 新しいシステムの開発に対するユーザーの態度または行動を評価および推定します。
  • システムが、ビジネスを行う新しい方法について従業員の職務状況を教育、再訓練、異動、変更するために特別な努力を必要とするかどうかを判断するのに役立ちます。

スケジュールの実現可能性

  • これにより、プロジェクトは所定の時間制約またはスケジュール内で完了する必要があります。
  • また、プロジェクトの期限が妥当かどうかを検証および検証します。