知の冒険 @ Windfall - 要約文章を分かりやすく書く10か条
AFTERTOUCH surreal SxGx maniac cinema&book; review *めぐりあうたびに溺れて 見失うたびに胸焦がしてた* InverseDiaryFunction SxGx ｷｪｪｪｪ Ｎ山家の人々 Dairy ☆質問ﾀﾞｲｱﾘｰ☆ ネタ帖 むらみぃ 世の中とあたしの繋がり GOOBERS ++今日のechiko++ ロストマインドガール * mayumi blog * モウソウｔagebuch 読書感想日記☆ネタバレ注意警報！ 癌と煙草と酒と 俺の道 toro's bｌog. ++ torog ++ ココアシガレット・アンダーグラウンド Deportare gorf net AFTERTOUCH surreal ２ちゃんねるの超怖い話 maniac cinema&book; review CARLTON1976 平凡な日々 秘密のホンネ ゴリラ秘話。 Ｌ
ドキュメントレビューに役立つ40のチェックポイント ― 1/3 ― ＠IT情報マネジメント
プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基本的なチェックポイントを紹介する（なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい）。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物（ドキュメント）を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 （1）題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”
HTMLの基本構造 - 仕様書に見るHTML(1)
3.3 属性リスト宣言と実体宣言 また、DTDでは要素タイプがどんな属性を持つのかも定義します。属性は、<!ATTLIST で始まる宣言文で、属性名、属性値のタイプ、省略時の扱いについて定義します。 さらにDTDでは、さまざまな名前や値の別名を定義しておき、個々の宣言ではこの別名を使うのが普通です。この別名の定義を実体宣言といい、<!ENTITY で始まる宣言で定義しています。 仕様書の3.3ではこれらについても詳しく説明されています。それほど複雑ではないので、できればひととおり目を通して、DTDの読み方を身につけておきましょう。 4 HTML文書の構造 では、HTML4の仕様書のさまざまな要素タイプの定義の中から、注目しておきたい部分を拾い読みしていきます。HTMLを書くときに、「ここはどうなっているんだろう」と疑問に思うような点の多くは、実は仕様書できちんと解説されているものなのです。
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
メタ情報とサマリーで「伝わる」ビジネス文 ― ＠IT自分戦略研究所
コミュニケーションスキルの土台となる図解言語。だが筆者によると、実はその裏に隠れた読解力、国語力こそがITエンジニアにとって重要なのだという。ITエンジニアに必須の国語力とはどのようなものだろうか。それを身に付けるにはどうしたらいいのか。毎回、ITエンジニアに身近な例を挙げて解説する。 ビジネスやエンジニアリングの世界では、実務的な国語力＝「情報を整理整頓して分かりやすく他人に伝える能力」が不可欠である。しかし困ったことにその実務的な国語力を学校ではなぜか教えてくれない。典型的な失敗を学び、そこから実務的な国語力を養おう。 ■実務的な国語力が必要とされている 20年前、高校生だった私が最も嫌いな教科は国語だった。 その私がいまでは国語教育の改革の必要性を訴えて旗を振っているというのも妙なものだが、私の理屈は首尾一貫している。要するに「無駄な教育はやっても無駄、まともに意味のある教育をしよう
わたしが知らないスゴ本は、きっとあなたが読んでいる: 画面仕様書を「作らない」リスク
IT Pro の開発ドキュメントの最適化で笑わせていただいた。これ書いた人は画面仕様で酷い目に遭ったことがないんだろう。笑った箇所は次の通り。 画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は，HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても，ドキュメントよりは実際の画面で確認した方が分かりやすいので，手戻りが減る。これは帳票にも同じことが言える。 あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」じゃねぇ！ボタン配置や文字色を目の前で変えられるものだから、いつまでたっても顧客は「ちょっとコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要
いまさら聞けない要求管理の基本
なぜ、要求を管理する必要があるのか なぜ、要求を管理するのでしょうか？ 一言でいうと、要求を管理することが、プロジェクトの成功を大きく左右するからです。まず、一般的なプロジェクトのゴールを考えてみましょう。次のような定義を見てください。 「顧客の真のニーズを満たす」「高品質」「期間内」「予算内」という4つのキーワードが出てきますが、どれも要求管理と大きくかかわってきます。まず、「高品質」な製品を作るためには、要求管理において、信頼性やスループットといった製品の機能面以外の要求も確実に把握することが重要です。また、「期間内」「予算内」で製品を開発するには何が問題でしょうか？ プロジェクトは、時間と予算とリソースが制限された状態で製品を開発しなければなりません。与えられた時間、予算、リソースを用いてどれくらいの作業ができるか考慮して、製品の要求仕様の範囲を、作業が可能である範囲に抑えねばならな
急がば回れ──質の良い仕様書の作り方
前回は、自社の業務に必要なシステムの要件の定め方について触れた。今回はその次のフェイズ──仕様決定について考えていこう システムの要件が決まったら、これを具体的なシステム仕様書に落とし込んでいく必要がある。システム仕様書とは、要件を満たすための具体的なシステムの機能・性能に対する要求事項を文書化したものだ。 ソフトウェアの場合、要件定義や仕様書の段階で発見された不備を是正するコストと、運用段階に入ってからのそれとでは、実に200倍の差があるという説がある。また、NASAの記録では、最初の20％の工程に、全体の作業時間の15％を投入することで、プロジェクトの成功確率が80％にまで高まるという。 「早く、安く、最小の投資で最大の効果を生むシステム構築をする」には、システム仕様書の作成に手を抜いたり、他人任せにすべきでない。「急がば、回れ！」である。 質の高い仕様書とは 要件を満足するための、必
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Joel on Software - やさしい機能仕様