要求仕様書の規約IEEE830で、困る点（その１） - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 昨日のブログで書いた、要求仕様書の規約IEEE830だが、実際の仕様書に起こそうとすると、こまることがある。ざっと考えて以下の３点 １．この順番で書くと、機能を理解するために、膨大な用語定義を見ないといけない ２．機能の定義の仕方が、オブジェクト指向などと合わない可能性がある →オブジェクト指向では、このフォーマットだと書きにくい ちょっと、かえればいいだけなんだけどね。 ３．外部設計の規約IEEE 1016と、あわせてつかうと、へなちょこになる →つーか、IEEE1016が、へなちょこ！ で、今回は、「１．この順番で書くと、機能を理解するために、膨大な用語定義を見ないといけない」について。 で、この話をする前提として、IEEE830の内容は、このページを参考にしています。 １．
要求仕様（要求工学：第3回）
概 要 今回はIEEE830[１]に基づいてソフトウェアに関する要求仕様の標準的な構成例を紹介しよう。立命館大学の大西教授と山梨大学の郷助教授による「要求工学」[２]の第４章でもIEEE830が解説されている。 IEEE830では表1に示すように要求仕様を、目次、はじめに、要求仕様の一般的な説明、要求仕様の具体的な説明、付録、索引から、構成することを推奨している。 IEEE830 では、ソフトウェアをシステムの一部であるとしており、システムの要求仕様とソフトウェアの要求仕様を区別するためソフトウェア要求仕様（ Software Requirements Specification）を略してSRSと記述する。これに対してシステム要求仕様をSyRSと略記する[３]。本稿ではSRSについて解説する。 表1 IEEE 830 による要求仕様の構成 SRS 第1章「はじめに」 「はじめに」ではSRS
IEEE830-1998 — MetaMetaWeb
Table of Contents (目次) 1. Introduction (はじめに) SRSの「はじめに」では、SRS全体の概要を書く。 1.1. Purpose (目的) この小節では SRSの目的を描写する SRSが意図する聴衆を指定する 1.2. Scope (範囲) この小節では これから作るソフトウェア成果物に名前を付ける このソフトウェア成果物が何であるか(必要ならば、何でないか)を説明する 指定されたソフトウェアの適用について、対応する利点、目的、目標を含めて記述する もし上位レベルの仕様書(例えばSyRS)があれば、同様の記述と矛盾がないようにする 1.3. Definitions, acronyms, and abbreviations (定義、略語、短縮形) この小節では、このSRSを解釈するのに必要となるすべての用語、略語、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
【楽天市場】エラー
http://www.xart.co.jp/07netbusiness/chishiki_b019.htm