詳細設計はプログラム作成するための資料だから、プログラムっぽく書けばいいよね？ どんなことに注意して書けばいいんだろう？   こんにちは、古賀です！   本記事では、 ... Copyright © 2024 Koga Masao's LifeBlog All Rights Reserved.

この基本ができてないのに、アジャイルやるぞーって言った次の言葉が「何やればいいですか？」とか言うので、きほんをゆるく書きます。 1. 戦略書今回は省略。どこかで日記にします。 2. PJ計画書・PJ憲章今回は省略。どこかで日記にします。 3. 要求仕様書温度を測定するソフトウェアを例にして記述していきます。 何を作りたいのか？を列挙します。 また、ソフトウェアを作ることで、何が変わるのか？Before/Afterを明記します。 基本的には素人→ITに口頭で依頼されることがあるので、言われたことを取りこぼしなく列挙していきます。 3.1. 要求仕様書の記述例・目的 温度を測って、PCのエクセルに記録しているのが、めんどくさいから、機械で記録までして欲しい。 ・背景 利用者がめんどくさい。手間が掛かる。と言っている。 このソフトウェアによって、利用者の手間が減ることで、コスト削減できる。また、

Web開発の現場で、設計書がほとんどない開発が多かったので、直近の現場で得た設計書作成方法を備忘録としてまとめました。 設計書の分類 設計書は大きく分けて以下のような分類となります。 00.管理 スケジュール 体制図 議事録 QAシート 10.要件定義 要件定義書 20.基本設計 システム設計書 DB定義書 画面設計書 バッチ設計書 30.詳細設計 〇〇バッチ設計書 △△画面設計書 40.製造 ソース ストアド、ジョブ、バッチ DDL・DML 50.単体テスト 単体テスト仕様書 単体テストエビデンス 単体テスト障害管理 60.結合テスト 70.総合テスト 80.移行設計 移行設計書 移行手順書 90.運用設計書 設計書の作り方 基本的にExcelで作成し、印刷設定を考慮して作成していく。 設計書には共通して、下記のシート、ヘッダーを作成する。 設計書は基本的にセル幅、セル高さを揃えておき、

目的 現場で詳細設計を作成する機会が増えた為、「詳細設計の役割って何？」「分かりやすい詳細設計書の書き方は？」ということをまとめて、自分の理解を深めると共に、研修を終えて現場に出たエンジニアの方に少しでも詳細設計についての知識を共有できればと思い投稿しました。 詳細設計とは システム開発の上流工程は 「要件定義」→「基本設計」→「詳細設計」の流れに従って進められていきます。 その中で詳細設計は 「基本設計で決められた動きをどうやって実現するかを決める」 役割を担っています。 要するに前工程である「要件定義」「基本設計」までで決められたシステムの実現の為に「どう実装するか」というところまで落とし込む工程と言えます。 故に、詳細設計を見る人間はお客様ではなくプログラマーであり、「分かりやすい詳細設計」＝「実装しやすい設計書」とも考えられます。 分かりやすい詳細設計の作成方法 ポイントは ・認識

前置き 自分のこれまでの知識や経験から、要件定義や設計書作成時に決めるべき内容を整理する。 一般的なものではないが、自分のこれからの開発に生かしたい。 自分の知識や経験は以下である。 大学生のときに学んだベンチャー時代のソニーのプロジェクト管理手法 Web系ベンチャー企業での開発経験 大企業での分析システムの開発経験 以下では「要件定義」「基本設計」「外部設計」「内部設計」の4フェーズに分けているが、どのように分けるか、どのような言葉を使うかは組織や状況によって異なる(詳細設計とか)。ちなみに、「外部設計」「内部設計」という言葉を使用するメリットは、「外設(ガイセツ)）」「内設(ナイセツ)」と略せること、外部と内部が対になることだろう。 要件定義の目的 要件定義の目的は、開発する対象物および、それが外部に与える影響を明確化することであると僕は考える。 例えばソニーがカラーテレビを開発したと

設計書を「使える化」するために 背景 今のままでは設計書は不良債権と化してしまう。 なんとか設計書を「使える化」しないといけない。 すでに設計書はあるが、よくわからない状態を想定しています。 哲学 何か聞くにしても設計書を自分で書く 君が書いたものが設計書なんだよっていうようなことを教えてもらったことがあります。 そこからお客さんに見せる設計書ができるかどうかはわかんないです。 そこにとらわれると何もできなくなってしまうと思います。 今回は詳細設計が終わって以降残骸のような設計書をなんとか「使える化」 する話です。 作るもの 実行計画・・・設計書一覧のこと 機能一覧・・・本当の一覧でいいと思います。 画面遷移図・・・あり物の図をパワーポイントに貼り付ける。無ければ四角をつなぐぐらいで作る。 状態図・・・全て網羅を考えず、主要なものを1つ2つ作る 主要テーブル・またはER・・・処理系・非処理

システム開発に関わる機会が多くなってきたので、仕様書作成に関して色々とメモ。 ウォーターフォールモデルでの上流工程について記述していく。 上流工程は 「要件定義」→「外部設計」→「内部設計」の流れに従って進められていく。 要件定義 開発するシステムに求められている機能などの要件をまとめる事。 例えば 「パスワード認証」「データベース内検索」などの機能要件 「入力データ」「出力データ」の仕様 「保守性」「操作性」などの非機能要件 業務フロー などが挙げられる。 RFP(提案依頼書)作成や事前調査などを行って、本当に必要な要件をじっくりと精査していく。 ココでまとめた内容を元に開発が進められる為、洗礼された要件定義を行うことで見落としによる仕様変更の回数を減らす事が出来る。 要件定義時に扱うのは必ず保証しなければならない項目が中心であり、UIデザインなどのデベロッパー側が決めても構わない部分は

この記事では、基本設計フェーズで作成する各種のドキュメントの中で、特にビジネスロジックに関する基本設計書に関して、よりよいドキュメントを作成したい方のためのノウハウを提供します。 1. はじめに 1.1. 基本設計書は大切なドキュメント 「基本設計」という言葉は、ITシステムに関する仕事をされている方においては、知らない人がいないであろう言葉だと思います。 そしてこの基本設計における各種のドキュメント、特にビジネスロジックを記載した基本設計書（以下、基本設計書）は、業務を担当するユーザ側担当者（以下、ユーザ）とシステムを構築する設計担当者（以下、設計者）の心の架け橋となる、大切なドキュメントです。 1.2. うまくいかない基本設計 しかし世の中のシステム構築の現場では、この基本設計書がうまく書けていないがためにユーザと設計者の間で心が通わず、結果的に完成したシステムがユーザが予想していたも

突然要件定義と基本設計で決めなきゃいけないこと洗い出してーと言われて困ってしまった。 僕はその工程の経験ないんだけど・・・とも言えずに付け焼刃的に勉強した内容をまとめてみる。 個人的に今後ブラッシュアップできればいいなあと思う記事。 必要なドキュメントの洗い出しや自分の作業漏れのチェックに使っていきたい。

要件定義、基本設計、詳細設計の各フェーズで、何を目的に作業するのか、その作業によりどんなメリットがあるのか、設計におけるポイントは何か、といったことを整理するために記事を書きました。 エンジニア1年目の設計初心者が書いたものですので、間違いやご指摘がありましたら教えていただけますと嬉しいです。 要件定義とは、システムやソフトウェアの開発において、実装すべき機能や満たすべき性能を明確にする作業のことです。 開発対象となる機能の一覧を作成する作業と説明しているものもありました。 要件定義の目的 要件定義の目的は、次のようなものかと思います。 要求や要件の漏れによる大幅な手戻りを防ぐ システムで実現できること・できないことを明確にして関係者間で同意を得る 要件を明確にすることで実装やテストをスムーズに進める 要件定義のポイント 要求や要件の漏れを防ぐ 要求や要件に漏れがあることが後になってわかる

はじめに IT企業に転職し、開発に携わる機会が増えてきたのでシステム開発の工程の一つである 『外部設計』と『内部設計』について調べたので記事にします。 システム設計の流れ 基本的な流れとして最初に要件定義を行い、次に外部設計を行い、外部設計を基に内部設計を行う。 要件定義とは クライアントが求めている機能に対して、システムの使用や範囲を決める。 例として、必要な機能、性能、要求されている信頼性や保守性などクライアントの要望に合わせ要件定義書を作成する。要件定義書の精度が高ければ、外部設計が行いやすくなる。 一言まとめ クライアントが求めてる機能を、要件定義書に起こす。 要件定義で定義した、機能、性能、制約条件を基にシステム設計を行う。 主に、UIなどユーザーから見える部分の仕様を決定したり、セキュリティ、運用規定、システム開発のスケジュール、費用などの設計を行う。 一言まとめ ユーザー側の

背景 今まで携わったプロジェクト、人によって、「仕様書」、「設計書」と意味合いが違った呼び方されている。自分の見解を示す 辞書（weblio）を引いて比べてみましょう 仕様書とは ① やり方や、その順序を記した文書。 「作業の－」 ② 建築・機械などで、注文品の内容や図などを書いた書類。 設計書とは 建築物やシステムに関する構造、形、機能などを定義したもの。図面で表したものを設計図という。 自分の見解 辞書を引いて読むと違いは明確になりますね 仕様書は、こう有るべきという仕様（決め事）を記載する書類です。 設計書は、その仕様を実現する為に、「どのようなシステム構成にするか？」、「どうやって作るか？」という実現方法を記載した書類です。 例（ユーザーがWEB掲示板の製造をシステム開発会社に発注した場合） 以下の様な決め事を記載した書類が仕様書です。 WEB掲示板にアクセスするときには、ログイン

前回公開したエントリ「開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経」へのフィードバックで、保守には設計書が必要なのではないか、というものがあった。その点については思うことがある。というわけで、保守という観点でソフトウェア設計書に関する考えをまとめてみた。ソフトウェア構築時に必要とされる設計書と、保守の際に必要とされるものは異なるのではないかと考えている。 議論の前提：仕様書と設計書 再掲になるけれども、ここでは仕様書と設計書という用語を以下のように定義する。 仕様書 … 開発者とユーザー(仕様決定者)が、ソフトウェアの振る舞いや動きに関してコミュニケーションするために必要な文書類のこと。 設計書 … 開発者どうしがソフトウェアを作成するにあたっての、構造や仕様についてコミュニケーションするために必要な文書類のこと。 そして、改めて説明する必要は無いと思うけれども仕様書は保守

プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基本的なチェックポイントを紹介する（なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい）。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物（ドキュメント）を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 （1）題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”