タグ

documentに関するs17erのブックマーク (13)

  • 要件定義の勘どころ

    はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか?」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル? システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし

    要件定義の勘どころ
  • 「要件定義書のアウトライン作成」完全マニュアル

    他の文書と同様、要件定義書はまず文書全体のアウトライン(骨格、構成)をしっかり作り上げてから内容を記述します。今回は、読みやすく分かりやすい要件定義書にするためのアウトライン作成方法を紹介します。 階層構造で読みやすい文書にする 要件定義書を作るためには、全体を大見出し=中見出し=小見出し(章=節=項)の階層構造にします。 「大見出し」「中見出し」「小見出し」の数を、それぞれ5から10程度にするのは、前回(第3回「分かりやすい提案書はアウトラインが美しい」)紹介した提案書と同様です。見出しの数が多すぎると、読み手が文書の全体像を把握できなくなります。また、1つの項目の記述量を1ページ内に収めるようにします。 要件定義書を構成する項目 要件定義書に必要な大見出しの項目としては、次のようなものが挙げられます。 システムの概要/システムの構想 機能要求 入力要求と出力要求 システム導入後の業務フ

    「要件定義書のアウトライン作成」完全マニュアル
  • テスト仕様書の書き方 - LumberMill's Notes

    「仕様書の書き方」の一連のページをまとめて電子書籍化しました。 iBookstore で発売中です。 2015.05.11 この文章や、文章中で定義する用語は、株式会社ランバーミルの開発業務の中で蓄積されたノウハウを基にしています。業界一般や書籍等で定義されているものとは、必ずしもニュアンスが一致していない点に注意して下さい(業務の参考にはなるかもしれませんが、試験対策には使えません)。 テスト仕様書とは システムの振舞いを外部からチェックする手順を定めた仕様書です。システムの構築途中から、運用開始後に渡って少しずつ(後述するシナリオを)書き足されて行きます。”動作確認”という曖昧な作業の内容を可能な限り明確にし、迅速かつ確実なテストを実行できるようにすることが、この仕様書の目的です。 システムテストと単体テスト この仕様書がカバーするのは、所謂、「システムテスト」です。稼動環境に似せた

  • 知るだけで天地の差が出る、テスト仕様書の必須項目&表現方法

    テスト仕様書で絶対に必要な項目リスト テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号(通し番号など) テストを実施した年月日 テストを実行した担当者 障害報告票番号(発生した障害の詳細を開発グループに報告する帳票の識別番号) まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。 なぜなら、

    知るだけで天地の差が出る、テスト仕様書の必須項目&表現方法
  • Google の Design Doc について - フリーフォーム フリークアウト

    移転しました http://please-sleep.cou929.nu/20091116.html

    Google の Design Doc について - フリーフォーム フリークアウト
  • Googleのdesign docを眺めてみる - kenmazの日記

    http://steps.dodgson.org/?date=20090705より。 Google社員によるWebKitのWeb Socketに関するdesign docがchromeの開発ML上で公開されている事を知った。 WebKit Web Socket design doc http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh 鵜飼さんなど日Googlerによるdesign docらしい。 Googleの講演などでdesign docをよく書く文化があると言う事は知っていたが、実際に見るのははじめて。このdocの場合だいたい以下のような構成になっている。 目的 Web Socketでブラウザ=サーバー間双方向通信のための新しいAPIを定義するよー 背景 Ajaxとかでブラウザ=サーバーの双方向通信をよくやっているけど、httpを無理

    Googleのdesign docを眺めてみる - kenmazの日記
  • 42X3547_02.ps

  • 3.12.6 Documentation

    Python 3.12.6 documentation Welcome! This is the official documentation for Python 3.12.6. Documentation sections: What's new in Python 3.12? Or all "What's new" documents since Python 2.0 Tutorial Start here: a tour of Python's syntax and features Library reference Standard library and builtins Language reference Syntax and language elements Python setup and usage How to install, configure, and u

  • Python 2.7ja1 ドキュメント

    グローバルモジュールインデクス (全ドキュメントにすばやくアクセスできます) ライブラリリファレンス (枕の下にいつも置いておきましょう) Macintosh モジュールリファレンス (Macintosh を使っているならこれも) Python モジュールのインストール (管理者向け) Python モジュールの配布 (開発者,パッケージ作成者向け)

  • WhatTimeIsIt_Jp 機能仕様書

    これはソフトウェアマネジメントに関するサイトJoel on Softwareの機能仕様書サンプルです。教育目的で作られており、すべてがいかに馬鹿げているかお気付きにならない方のために申しますと、言及されているのは現実の製品ではありません。(特に頭の鈍い部類の)ベンチャーキャピタリストへの注意: この製品アイディアは、事前評価額2000万ドルに対する500万ドルの追加投資で構築することができます。 WhatTimeIsIt.com 機能仕様書 ジョエル・スポルスキ 最終更新日: 2000/9/27 - 極秘 - © 2000 Fog Creek Software, Inc. All Rights Reserved. 概要 WhatTimeIsIt.comはWeb上で現在時刻を人々に知らせるサービスである。 この仕様書は、いかに想像力をたくましくしようと、不完全である。すべての文言は完成までに

  • 開発工程でSEが書く文書の基本 − @IT自分戦略研究所

    「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回

    開発工程でSEが書く文書の基本 − @IT自分戦略研究所
    s17er
    s17er 2009/08/02
    要件定義書に書いた内容を、開発中に引っくり返す客もいるということを頭に入れておきたい
  • Joel on Software - やさしい機能仕様

    ジョエル・スポルスキは、ニューヨーク市の小さなソフトウェア会社  Fog Creek Software の設立者です。イェール大学を卒業後、マイクロソフト社、Viacom社、 Juno社でプログラマとして働きました。 このページは著者の個人的な意見を掲載したものです。 All contents Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved. FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky

  • 画面仕様書作成ツールとしてのExcel・Visio 7つのポイント - ウェブユーザビリティ.JP

    個人的には最近は、ペーパープロトタイピングやAxure、OmniGraffleなどのプロトタイピングツールに興味を持っていますが、それらはあくまでプロトタイピング段階の話で、仕様書としておこす場合には、ExcelやVisioなどのファイルに記述することになると思います。 業務でExcelやVisioを用いて画面仕様書や画面遷移図(サイトマップ)を作成する中で感じた良い点・悪い点などをまとめてみます。(PowerPointは少ししか使ってないのでおまけ程度に載せてみました。) 画面設計、画面仕様書作成ツールを検討する際の参考にして頂ければと思います。 Excel [Good]新たにツールを購入する必要がない ほとんどの企業で導入されているため、画面仕様書作成のために新しくお金をかけてツールを購入する必要が無いのは大きな利点である。 [Good]共有する際にそのまま送ってもほとんど問題ない 大

  • 1