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
業務システム設計に関する本 - プログラマの思索
業務システムの要件を定義して設計する手法は、プログラミング手法とは大きく異なる。 プログラミングはオブジェクト指向がベストプラクティスだが、要件定義や設計の手法は日本独自のDOA(データモデリング)の方がやりやすいような気がしている。 特にRailsという優れたWebフレームワークが出現して、データモデリングの重要性が増してきたように思う。 理由は、テーブル設計さえできれば、マイグレーション機能によってDBスキーマを一発で生成できるし、scafold機能によってテーブルのCRUD画面はあっという間に実装できるからだ。 つまり、テーブルさえ作れれば、業務システムをWeb上で動かして簡単に理解できるようになってきた現状があるからだ。 僕が今まで読んできた本の中で、自分が役に立ったと思う本を列挙しておく。 【1】グラス片手にデータベース設計編 グラス片手にデータベース設計~販売管理システム編 (
アーキテクト解体ショー（前編） | オブジェクトの広場
1. はじめに アーキテクト解体ショーとはアーキテクトの頭の中で行われている設計プロセスを解体して見える化し、設計プロセス自体やノウハウの共有などに役立てるための手法です。 本稿は前後編に分けてアーキテクト解体ショーを紹介します。 前編ではアーキテクト解体ショーの基本概念や表記法、単純な事例、利用場面を解説します。 後編では複雑な事例を用いて表記法を掘り下げて解説し、またアーキテクト解体ショーの様々な Tips を紹介します。 2. アーキテクト解体ショーの基本概念 アーキテクチャ設計には、(1) 仮説としてアーキテクチャを設計し、(2) プロジェクトの要求と制約に照らし合わせて、(3) 仮説のアーキテクチャを採用するか否か判断を下す、というプロセスがあると仮定し、アーキテクト解体ショーではこのプロセスに合わせ「設計（結果）」「要求と制約」「設計判断」を見える化します。 3. 用語の定義
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://local.joelonsoftware.com/mediawiki/index.php/%E3%82%84%E3%81%95%E3%81%97%E3%81%84%E6%A9%9F%E8%83%BD%E4%BB%95%E6%A7%98_%E3%83%91%E3%83%BC%E3%83%881:_%E3%81%AA%E3%81%9C%E3%82%8F%E3%81%96%E3%82%8F%E3%81%96%E6%9B%B8%E3%81%8F%E5%BF%85%E8%A6%81%E3%81%8C%25