実践要件定義入門 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
明瞭な「提案依頼書（RFP）」の書き方
連載「エンジニアのためのビジネス文書作成術」は、書籍「外資系コンサルのビジネス文書作成術」（吉澤準特著 東洋経済新報社）を基に、出版社の許可を得て、筆者自身が＠IT読者向けに再構成したものです。画像はWindows 7 + Word 2013上のものです。機能はWord 2013、2016のいずれでも使用できます 連載「エンジニアのためのビジネス文書作成術」、第1回は「議事録」の書き方を、第2回は「要件定義書」の書き方を学びました。第3回は「提案依頼書（RFP）」をWordで作ります。 提案依頼書（RFP）とは、発注者（ユーザー）が、自分たちが提案してほしいことを具体的な「内容（要件）」にまとめた文書です。受注者（ベンダー）が「提案書」を作成するためのインプット（材料）になります。 RFPはシステムの「実装内容」だけでなく、自社とベンダーの「責任関係」を決める文書です。「役割分担」は、その
プログラム設計書の良い部分と悪い部分 - GeekFactory
設計書の定義は、おおよそ開発標準や慣例で決まっています。逆に言うと、設計書名やその中身を書くと社名がバレるかもしれません。だからみんな書きたがらないのでは。中でもプログラム設計書はベンダによる違いが大きく、結果的に技術力の差となることが多いです。 前回のエントリでは、プログラム設計書のすべてが不要と言っているわけではありません。 プログラム設計書には、良い部分もあります。内部設計では表現できない設計思想が書いてあるので、変更容易性が向上します。例えば、クラス図からは具体的にどんなデータを扱って処理しているのか読み取れます。そもそもの話ですがインタフェースが決まらないと分業ができませんので、他所と共有するメソッドは設計書に落ちている必要があります。小規模だと細かいメソッド名まで決めない場合もあるし、逆にprivateメソッドまで決めてから実装する場合もあります。 ただ、言語レベルの記述方法ま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
