タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

非機能要求に関するjanuaryのブックマーク (2)

  • [方式設計編]性能要件はユーザーが決めると思ってはいけない

    「ユーザーが要件を決めてくれないので…」「性能要件を出していただかないと機器が見積もれません,早く要件を出してください!」。要件定義フェーズのみならず,プロジェクトの様々な工程でよく耳にする言葉である。 非機能要件はユーザーにヒアリングして洗い出すのが,インフラ設計における一般的な手法だ。だが,インフラ設計者はヒアリングによって得られたユーザーの「要望」を絶対的な「要件」としてとらえてはいけない。非機能要件を洗い出すに際しては,要望の裏にあるリスクやそこから派生する制約を先読みすることが重要である。その思考を停止してしまうと,後工程で様々な問題が発生する。 今回は,非機能要件の中でも読者にとって最も身近だと思われる「(オンラインの)性能要件」を例に解説する。なお,現在のシステム構築では,現行システムが存在せずゼロから開発することはほとんどない。従って,ここでは現行システムで何らかの稼働統計

    [方式設計編]性能要件はユーザーが決めると思ってはいけない
  • 非機能要求は,検証できなければ意味がない

    JUAS(日情報システム・ユーザー協会)が,「非機能要求仕様定義ガイドライン」を発行した。このガイドラインは,JUASが2007年9月から2008年3月にかけて実施した「UVC(User Vender Collaboration)研究プロジェクトII」の成果で,ユーザー企業がベンダーに提示する要求仕様書(別の言い方ではRFP=提案依頼書)における非機能要求の定義方法をまとめたものである。 JUASは,2007年に「UVC研究プロジェクト」の成果として「要求仕様定義ガイドライン」を発行しているが,非機能要求については不十分だった。これを補うために,非機能要求に正面から取り組んだのがUVC研究プロジェクトIIであり,「非機能要求仕様定義ガイドライン」だ。 言うまでもなく,ユーザー企業がシステムの非機能要求を明確にベンダーに伝えることは非常に大切である。しかしこれまでは,どんな非機能要求を伝え

    非機能要求は,検証できなければ意味がない
  • 1