ペロリ流 開発要件のまとめ方 - peroli Developer's Blog
2016 - 07 - 22 ペロリ流 開発要件のまとめ方 開発プロセス list Tweet こんにちは。開発部のマネージャーをやっている mizushimac です。 今回は開発するモノの要件のまとめ方についてペロリ開発部が実践している内容を少しご紹介したいと思います。みなさんの会社やプロジェクトではどうやって開発するモノの要件をまとめていますか？ パワポ ですか？ spreadsheet ですか？ 流れ行く slack や github issue で議論しながらコメントに埋もれていき誰かが箇条書きでまとめますか？ きっとカオスなことが多いかなと思いますのでこのエントリーが少しでもご参考になればと思います。 ちなみに、ペロリはカオスを楽しめる人を求めていますw 開発要件のまとめ方って色々あって難しい 私が学生の時に所属していた ベンチャー企業 では、数十MBもある パワポ に画面イメ
自宅サーバのインフラ設計書を公開します - @int128
自宅サーバのインフラ設計書を公開します。 Design paper of the home server（抜粋） 昨夜にTwitterで公開したら予想外に反響があったので、ちゃんとエントリに残すことにしました。クラックされるおそれがあるので、細かい部分は公開できないことをご了承ください。 内容はこんな感じ。 要件概要 機器仕様 ネットワーク設計 ソフトウェアスタック設計 共通基盤設計 サーバ詳細設計 上記にバックアップ設計や運用管理まわり*1を加えれば、インフラの設計書はだいたいこんな感じではないかと思います。 インフラの要件定義は難しい 一方で、インフラの要件定義は十分に標準化が進んでおらず、会社やチームによって文化がかなり違います。特に受託開発（SI）の場合は、お客様の中にインフラに詳しい人がいなくて調整に苦労することも多いと思います。費用と可用性のトレードオフの部分はなかなか伝わりづ
知るだけで天地の差が出る、テスト仕様書の必須項目＆表現方法
テスト仕様書で絶対に必要な項目リスト テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号（通し番号など） テストを実施した年月日 テストを実行した担当者 障害報告票番号（発生した障害の詳細を開発グループに報告する帳票の識別番号） まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。 なぜなら、
わかりやすい技術文章の書き方
誰が読むのか。 読み手にどんな感想を持ってもらいたいか。 読み手はどれくらいの予備知識を持っているか。 読み手はどんな目的で、何を期待して読むのか。 読み手が真っ先に知りたいことは何か。 レポート・論文とは何か 問いが与えられ、または自分が問いを提起し、 その問題に対して明確な答えを与え、 その主張を論理的に裏付けるための事実・理論的な根拠を提示して、主張を論証する。 標準的な構成要素とは何か レポート・論文の構成は、 概要 序論 本論 論議 という要素が標準的である。次にそれぞれの要素について簡単に見てみる。 概要 論文全体を結論も含めて、すべて要約する。 序論 本論で取り上げる内容は何か。 その問題をどんな動機で取り上げたのか。 その問題の背景は何か。 その問題についてどんなアプローチを取ったのか。 本論 調査・研究の方法・結論 論議 自己の議論・結論を客観的・第三者的に評価する。 そ
開発工程でSEが書く文書の基本 − ＠IT自分戦略研究所
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回
ひとつ上のヒューマンマネジメント 10年後も通用する文章術(1) 「駄目でない」文章を書くための9カ条
私は企業のIT企画部門の課長としてチームメンバーの文章をチェックしています。また，教育コンサルタントとしてビジネス文章を教えたり，国家試験科目の論文添削をしています。 異なる立場で非常に多くの文章を見てきたので，今では「どんな文章が駄目なのか」がよく分かるようになりました。ここから紹介するのは「よい文章を書く技術」です。 「よい文章」とは「駄目でない文章」 私は人に「よい文章を書くコツは何ですか？」とよく聞かれます。そのときにはいつも，「駄目な文章を書かないようにすることです」と答えています。 人が何をもって「よい文章だ」と感じるかどうかは，極めて主観的なものだと考えています。個人の受け止め方や感じ方に依存する部分が多いからです。 では，ビジネス文書でも「よい文章」を書かなくてはいけないのでしょうか。もちろん，それができるに越したことはありません。 しかし，どんな人でも「うまい」と言わせる
ウノウラボ Unoh Labs: テスト計画書のテンプレート
こんにちは！やまもと＠テスト番長です。 巷ではインフルエンザが流行っているようですが、皆さんお元気にお過ごしでしょうか。 さて、プロジェクトが立ち上がったとき、（特に受託案件の場合） テストのドキュメントはどうしようか？という話が出ると思います。 適当にやる訳にも行かないけれどIEEE829をベースにしたものだと重かったり、割と迷う部分です。 英語ですがテスト計画のテンプレートを配布しているサイトがあったので、ご紹介してみます。 Pragmatic Software http://www.pragmaticsw.com/ Software Development Templates http://www.PragmaticSW.com/Templates.asp テスト計画書 Test Design - http://www.pragmaticsw.com/Template_Te
ソフトウェア分野の研究開発 / RFC 5023 Atom Publishing Protocol 日本語訳 | Ricoh Japan
この文書は RFC 5023 The Atom Publishing Protocol を, BCP78によって付託された権利に基づいて日本語に翻訳したものです。 翻訳には誤りがある可能性があります。この翻訳の正確性は保証しません。 翻訳についてのお問合せ先：（SSL対応フォーム） （非SSL対応フォーム） 翻訳者一覧 株式会社リコー 山本陽平 日野原寛 高桑寿一 中川勝樹 沖田邦夫 井上浩一 兵清弘 リコーソフトウエア株式会社 福田朋紀 更新履歴 2008-01-07 日外アソシエーツ株式会社 久我様の指摘を受け 9.7 の訳文をわかりやすく、11.2 の抜けを修正 2007-12-06 9.6、9.7.1、9.7.2、10 の誤記、表記ぶれを修正 2007-11-08 エヌ・ティ・ティ・コミュニケーションズ株式会社 朝倉様の指摘を受け 9.3/9.4 の誤訳を修正 2007-11-0
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
マニュアル作成が１０倍楽になるソフトがありました｜WEBクリエイターの木
10分で作るRailsアプリ という動画がRuby on Railsのすばらしさを短時間に説明してくれましたが、動画の説明は何より説得力がありますよね。画面キャプチャを何枚も貼って文章で説明するよりも、目で見て、間を体験すると感じるものがあります。何より見る方は楽。 作る方も楽だったらなあとも思います。 以前自分の設計したWEBアプリのマニュアルを、パワーポイント 100ページ以上の膨大な資料としてまとめたことがあります作りながらも「こりゃあだれも見ないだろうなあ。自分でもみないもの」と思いながらも、提出義務があって仕方なく作っていました。印刷したお客さんからは「紙の無駄だ」と怒られわ、HTML化してWEBアプリに「ヘルプ」をつけても電話がかかってくるのが先でした。 しかしそんな苦労に遭わないように、最近お宝を発見しました その名も「Adobe Captivate2」 まあまあとりあえずア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
01.提案書トップ｜fude-bako.com
デザインパターン[モデリング] -TECHSCORE-
発注者のためのWebシステム／Webアプリケーション セキュリティ要件書｜脆弱性診断.jp
ほんのすこし書き方に注意すれば、あなたのドキュメントはさらに分かりやすくなる！
ちょっとした構成案を作れば、あなたのドキュメントはもっとわかりやすくなる！
『Linux標準教科書』開発プロジェクト - LPI-Japan - エルピーアイジャパン
実践的アプローチに基づく要求仕様の発注者ビュー検討会 - NTTデータ