仕様書を作る際に参考になりそうなページ ［ during Job and Life ］■System Requirements Specifications ■要求仕様（要求工学：第3回） ■システム仕様書の書き方 - システムとは何か？ (システムとは何か？様) 要求仕様書の不備は、 以下のプログラミング作業に大きな影響を与えます。 手を動かしたい気持ちを押さえて、 ここを整えることは、気持ちよいコーディングをするために必要です。
System Requirements Specifications
システム要求仕様書の書き方 IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specificationより Table of Contents (目次) 1. Introduction (はじめに) SRSの「はじめに」では、SRS全体の概要を書く。 1.1. Purpose (目的) この小節では SRSの目的を描写する SRSが意図する聴衆を指定する 1.2. Scope (範囲) この小節では これから作るソフトウェア成果物に名前を付ける このソフトウェア成果物が何であるか(必要ならば、何でないか)を説明する 指定されたソフトウェアの適用について、対応する利点、目的、目標を含めて記述する もし上位レベルの仕様書(例えばSyRS)があれば、同様の記述と矛盾がないようにする 1.3. Def
要求仕様（要求工学：第3回）
概 要 今回はIEEE830[１]に基づいてソフトウェアに関する要求仕様の標準的な構成例を紹介しよう。立命館大学の大西教授と山梨大学の郷助教授による「要求工学」[２]の第４章でもIEEE830が解説されている。 IEEE830では表1に示すように要求仕様を、目次、はじめに、要求仕様の一般的な説明、要求仕様の具体的な説明、付録、索引から、構成することを推奨している。 IEEE830 では、ソフトウェアをシステムの一部であるとしており、システムの要求仕様とソフトウェアの要求仕様を区別するためソフトウェア要求仕様（ Software Requirements Specification）を略してSRSと記述する。これに対してシステム要求仕様をSyRSと略記する[３]。本稿ではSRSについて解説する。 表1 IEEE 830 による要求仕様の構成 SRS 第1章「はじめに」 「はじめに」ではSRS
システム仕様書の書き方 - shingotadaの日記
自分なりにまとめたシステム仕様書の書き方を書いておきます。 表紙 表紙は1枚でまとめる。 ・システム名 ・版数 1.00からスタート。改訂するごとに1.10、1.20と増えていく。細かい修正などは1.01などとする。 ・仕様書の枚数 変更履歴 変更履歴は新規作成時、変更毎に記入する。1枚でまとめる。 ・システム名 ・版数 ・変更区分（新規 or 更新） ・変更したページ番号 ・変更内容 ・作成者＆作成日 ・承認者＆承認日（押印等） はじめに この仕様書の意味を記述する。この仕様書が、誰に対して、何を実現するシステムの、何に関して記述しているのかを記述する。必要であれば、お客様のどの要望を、どのように解決するのかも記述する。またシステム固有の専門用語が出てくる場合はその説明も付け加える。1枚程度でまとめる。 目次 番号体系が3層になるように記述する。以下に例を示す。 1 業務要件・・・・・・
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
