タグ

*非機能要件に関するmasapon1967のブックマーク (6)

  • 書籍の案内 - 非機能要求仕様定義ガイドライン2008~要求仕様の記述についての改革への第1歩~

    発注のユーザー側と開発を受けてのベンダー側の接点は、要求仕様書(見積照会仕様書、RFP)とその回答である要件定義書です。 要求仕様書RFPの解説書は世の中に多少存在していますが、この両者を結び、システム開発におけるトラブルを回避するための記述方法を追究したガイドはありません。 2007年度は、2006年度に十分な議論ができなかった、非機能要件についての定義と検証・テスト方法について議論を重ねてきました。ユーザーの視点に立ち、必要な非機能要件を230項目にまとめ、�@確認すべき項目、�A確認すべきプロセス、�B検証方法、�C必要なドキュメントについて、検討を行いました。 その結果をまとめたものが「非機能要求仕様定義ガイドライン2008」です。 ユーザーからの非機能仕様の要求の仕方、受入検証の仕方、評価方法などが明確になり、この種の問題提言に役立つ一冊となりました。 要求仕

    masapon1967
    masapon1967 2008/07/22
    非機能要求仕様定義ガイドライン2008
  • 非機能要求

    1 はじめに システム開発における要求分析モデルとして、ユースケースを中心に説明してきました。 ユースケースはユーザの目的をモデル化したモデル要素であり、システムがユーザに提供する機能を表現するという意味で機能要求のモデルといえます。第1回では、図1[営業社員のシステム・ユースケース]に示すユースケースを用いた要求モデルを作成しましたが、これは機能要求ということになります。 しかし、要求仕様は機能要求だけで構成されるわけではありません。実際のシステム開発では「ユーザの目的」とは別の観点でさまざまな要求を定める必要があります。このような機能外の要求のことを非機能要求と呼びます。 今回は、この非機能要求について説明します。 2 ISO/IEC 9126(JIS X 0129) 非機能要求を考える上では、システムの品質という切り口が重要です。 ISO/IEC 9126は、ソフトウェア開発における

    masapon1967
    masapon1967 2008/07/03
    非機能要求
  • Webシステム開発でセキュリティが軽視される理由 - @IT情報マネジメント

    Webシステムでは、アプリケーションレベルでのセキュリティ対策が不可欠であるにもかかわらず、軽視されがちだ。この現状を改善する方法を考える。 昨今の個人情報などに対する不正アクセス関連事件では、Web経由で提供されているアプリケーション(ここではWebシステムと呼ぶ)のセキュリティ上の欠陥に付け込まれる例が多発している。この種の不正アクセスからWebシステムを守るには、ファイアウォールなどの事後的な、外付けのセキュリティ対策だけでは不十分である。システムを開発する時点で、セキュリティ上の欠陥が生じないようにしなければならない。 一般的なWebシステムでは、開発作業が外部に委託されるケースが多い。このため、開発提案を依頼する(RFP)段階において、セキュリティ対策を含めた提案をしてもらうべきである。セキュリティ対策が明示的な形でシステム要件に含まれないと、受注側で対策を施すインセンティブが働

    Webシステム開発でセキュリティが軽視される理由 - @IT情報マネジメント
    masapon1967
    masapon1967 2008/01/31
    Webシステム開発でセキュリティが軽視される理由
  • 非機能要求とISO9126 | オブジェクトの広場

    稿では、ソフトウェア要求とは何なのかを理解し、非機能要求に焦点を当て、ISO9126、要求定義プロセス、事例と解説していきます。 ※稿は、技術評論社刊『JAVA PRESS Vol.40』に掲載された記事「機能外要求と ISO9126」を加筆、修正したものです。JAVA PRESS 編集部の了承を得た上で転載しています。 ※一切の転載をお断りします。 はじめに 私達がソフトウェアを開発するためには、ソフトウェアに対する要求 (ソフトウェア要求) が必要です。 ソフトウェア要求がなければ、そのソフトウェアには当は必要のない機能を作ってしまったり、必要な機能を作っていなかったりするでしょうし、何よりもソフトウェアが完成したのかさえ評価できません。 そのためにも、私達ソフトウェアを開発する者は、ソフトウェア要求とは何なのかを正しく理解しておかなければなりません。 稿では、ソフトウェア要求

    非機能要求とISO9126 | オブジェクトの広場
  • 非機能要件を見極める【後編】:ひな型を使い漏れ防止

    非機能要件は,ユーザーの要求からは出てきにくい。エスエムジーの小森裕介氏(オブジェクトフレームワークディヴィジョン テクニカルコンサルタント)は「経験上,非機能要件の中でも,許容できるダウンタイムや操作性などはユーザーから比較的出てきやすい。しかし,信頼性や性能は意識的にヒアリングしないとあまり出てこない。拡張性に関してはほとんど出てこない」と指摘する。そのため情報システム部門側で主導的に洗い出す。ここからは事例を基にそのプロセスを見ていこう。 ◆どう洗い出すか? ひな型を使い漏れ防止 要件をテンプレート化しておく 非機能要件は機能要件と異なり,項目レベルで業種や業務による違いが少ない。「性能」「保守性」「拡張性」「セキュリティ」など,どのシステムでも同じような項目が並ぶ。そこでエスエムジーは要件定義のテンプレートを用意し,非機能要件として洗い出すべき項目を列挙した。SEはその項目を埋めれ

    非機能要件を見極める【後編】:ひな型を使い漏れ防止
    masapon1967
    masapon1967 2007/12/20
    非機能要件を見極める【後編】:ひな型を使い漏れ防止
  • 非機能要件を見極める【前編】:ヒアリングでは不十分

    「要件定義を難しくする」とクローズアップされてきたのが“非機能要件”の存在である。非機能要件とは,性能や信頼性,拡張性,セキュリティなど,機能要件以外のもの全般を指す。これらはユーザーへのヒアリングからだけでは洗い出しにくい。漏れがあると,稼働後のトラブルの種になる。こうした事態を未然に防ぐ,非機能要件の見極め方を探る。 旅行代理店のアールアンドシーツアーズは,今年10月末に予定しているホテル予約システムの稼働に向けて,今,開発の真っ最中だ。このシステムは,仕入れた航空券の在庫や宿泊の空室情報を管理するホストに,2次代理店からインターネット経由で送信されてくる予約データを受け渡すもの。 開発を主導する大平雅義システム部長は,「機能要件はほぼ固まったが,性能に関する非機能要件が懸案として残っていて悩ましい」と語る。 予約データはインターネットを介してやり取りされる。そこに含まれる顧客情報は暗

    非機能要件を見極める【前編】:ヒアリングでは不十分
    masapon1967
    masapon1967 2007/12/20
    非機能要件を見極める【前編】:ヒアリングでは不十分
  • 1