要件定義、基本設計、詳細設計の流れを総復習
はじめに 📘 この記事は ラクス Advent Calendar 2023 の7日目の記事になります。 要件定義から基本設計、さらに実装や保守運用に至るまでの一貫した経験を何度か積んできましたが、毎回 「要件定義って具体的に何の項目が必要だっけ？」 「基本設計との違いって何だったっけ？」 「基本設計と詳細設計の区別って？」 といった疑問が頭をよぎってきました。 そんなわけで、これまでの経験を振り返りつつ、開発プロセスについて１からまとめていくことで頭の中の大掃除を行なっていきたいと思います🧹 この記事の対象者 🎯 開発プロセスについて学びたい方 要件定義の基本を学びたい人 要件定義と基本設計の違いがわからない人 一緒に開発プロセスについて復習したい方 前提 記事中の一部（特に要件定義や基本設計、詳細設計のサンプル）を自動生成で作成してます。一貫性の無い内容があるかも知れませんが、あく
『はじめよう！ 要件定義』（とそのシリーズ）を読んで、はじめよう！UIデザイン｜金 成奎
『はじめよう！ 要件定義 ～ビギナーからベテランまで』はそのタイトル通り、ソフトウェア開発に携わるエンジニアやPM向けに、要件定義の進め方について優しく解説してくれる書籍です。かわいいイラストと平易な文章がとっつきやすく、するすると読めてしまいますが、要件定義って何をどうやったらいいの？とお悩みの方に対して、まずはこれだけやっておくべき基礎知識を得ることができる、とてもわかりやすい内容になっています。 そしてそして、ここからが本noteの主な趣旨ですが、この3部作はデザイナー目線で読み解くと、極めて明瞭で本質的で実践的な、ユーザー体験設計とUI設計の進め方について学べるデザイン教則本と言えるのです。 以下、その理由と、本シリーズを使ってUIデザインを進めていく方法を実例を踏まえて解説していきます。 要件定義とはUI・機能・データを決めることいきなり『はじめよう！ 要件定義 』のキモ・コンセ
実践要件定義入門 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
要件定義における成果物一覧と書き方（要件定義書サンプルあり） | 若手エンジニアの羅針盤
システム開発の上流工程である要件定義では、顧客が抱える課題に対してどのようなシステムを作るのかを概要レベルで決定する。 要件定義が必要なのは「作ったはいいが使えないシステム」という状況を防ぐためで、システム開発におけるW...
【入門】要件定義
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい
[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita
下記ドキュメントバージョンに関する注意点です。 バージョン番号のルールを定める：バージョン番号は、どのようにつけるかルールを定め、チーム全員が同じ理解で使用するようにする必要があります。たとえば、変更内容によって数字がどのように増えるか（major, minor, patch）、何桁で表現するかなど、具体的に決めておくことが重要です。 変更履歴を明確にする：どのような変更があったのか、それがどのバージョンで実施されたのかを明確にすることが必要です。これにより、何らかの問題が発生した場合に、どのバージョンから問題があるのか特定することができます。 ドキュメントの保存場所を一元化する：ドキュメントのバージョン管理には、ドキュメントを保存する場所を一元化することが重要です。それにより、異なるバージョンのドキュメントが、複数の場所に分散してしまい、誤ったバージョンが使用されることを防ぐことができま
![[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/d7d131e38e26f54466aece3306435a4c09990de8/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCRG9jJTVEJTIwJUU4JUE2JTgxJUU0JUJCJUI2JUU1JUFFJTlBJUU3JUJFJUE5JUU2JTlCJUI4JUUzJTgzJTg2JUUzJTgzJUIzJUUzJTgzJTk3JUUzJTgzJUFDJUUzJTgzJUJDJUUzJTgzJTg4JUUzJTgzJUJCJUU4JUE2JTgxJUU0JUJCJUI2JUU1JUFFJTlBJUU3JUJFJUE5JUU2JTlCJUI4JUUzJTgxJUFFJUU2JTlCJUI4JUUzJTgxJThEJUU2JTk2JUI5JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz01MjE0ZDhhMTY1ZjE1ODIxNGE5NzU4Njc3MTNjOTBmNg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzeWFudGllbiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MTc4MmM0MTlmNzhiYTJjNTk0ODYwZmExZDc0OWYzNjQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Db088349e276a1ebcdb9dcf1e2d753094)
Agile and Requirement : アジャイルな要件定義について考える
アジャイルマニフェストとユーザーストーリーマッピングのお話です。
システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
ビジネスロジックのモデリングと実装 - ソフトウェア設計を考える
ビジネスロジック（ドメインロジック）をどうやってモデリングして、どうやって実装するかの実践例を公開しました。 RDRA 2.0 ハンドブックの図書館システムの実装例 (github) ビジネスロジックのもとになる業務モデルやビジネスルールのモデリングは、 モデルベースの要件定義手法 RDRA2.0 を使っています。 RDRA 2.0 ハンドブック (Kindle Unlimited会員は無償です) 実装技術は、Java/Spring Boot/MyBatis/Thymeleafを使っています。 JIGという設計の可視化ツールを使って、ソースコードからパッケージ関連図やクラスの一覧を自動生成しています。 JIGリポジトリ 利用方法 RDRA 2.0 ハンドブックを入手 リポジトリRDRA 2.0 ハンドブックの図書館システムの実装例をクローン Gradleタスク bootRunを実行(アプリ
PlantUML で始めるリレーションシップ駆動要件分析 (RDRA) - Qiita
はじめに ソフトウェア開発において、エンジニアが開発対象のドメインの業務に精通していない場合、書く内容やかける時間に程度はあれど 業務分析 や 要件定義 が必要になります。しかし、要件定義の方法論についての話題がネット上に上がることも少なく、書籍などもあまり話題になっていない印象があります (私の観測範囲では)。なので、私の場合、要件定義の実務では公の方法論を体系的に学ばずに、実務で見てきたものを自分なりにアレンジして対応してきました。 そんなとき、モデルベースの要件定義の方法論として リレーションシップ駆動分析 (RDRA) というものがあることを知りました。モデリングはずっと取り組んできていることなので、興味が湧いて少し調べてみると PlantUML でも表現できるというではありませんか！ PlantUML Example for RDRA 2.0 ハンドブック そこで、RDRA2.0
PlantUML Example for モデルベース要件定義テクニック - Qiita
PlantUMLはテキストの記述でUMLの図を描くことができます。オプション機能や組み合わせで色々な表現をすることができるので、UML を拡張した図が使われるモデルベース要件定義テクニックの書籍からいくつかのモデルを記述します。 書籍にはモデルの着眼点や解説が丁寧に記載されています。図の背景に興味がある方は合わせてお読みください。 コンテキストモデル ユースケース図でシステムの関係者を整理します。 left to right direction を利用すると図の方向を左から右に変更できます。 left to right direction actor 経営者 rectangle システムに直接関わる人 { actor 顧客 actor 営業 actor 物流 actor システム部門 actor オーダー部門 経営者 -- 営業 経営者 -- 物流 顧客 -- (商品販売サイト) 営業 -
PlantUML Example for モデルベース要件定義テクニックの記事のリンク - プログラマの思索
@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になるので、リンクしておく。 以下は、論理的でないラフなメモ書き。 【参考】 PlantUML Example for モデルベース要件定義テクニック - Qiita akipiiさんのツイート: "この発想は面白いな。RT @ogomr: PlantUML はテキストだけど意外と表現力があって モデルベース要件定義テクニック のUMLを拡張した図も描ける。GitLab なら RDRA をブラウザで表示できて便利 https://t.co/IpCRFQ4XDu" akipiiさんのツイート: "後で試す。RT @zenzengood: PlantUML Example for モデルベース要件定義テクニック https://t.co/IpCRFQ4XDu #Qiita テキストベース
私が本当に業務で行った要件定義の作成手順 - 前編 - Qiita
はじめに もともとは新規Webサービスを立ち上げる際に１からつくったもので、業務の中でドキュメントを作成しました。 再利用性を求めてフォーマット化しましたので、二次利用に使うなり、勉強資料などに役立てらればとおもいます。 今回は前編、中編、後編の３部で記載しておきたいとおもいます。 今回は、前編となります。 前提 要件定義を作成する上で、企画書や仕様書など記載する上での前提の資料が必要になってくるかと思います。 図を作成する上で、Caccoを利用しております。 前編の概要 要件定義をドキュメント化する最大の目的は、サービスやシステム概要を記載することも大事ですが、「なぜシステムを作るのか、なぜサービスを作るのか、サービスを作ると本当に利益があげられるのか」などを明確にしておくことです。 なぜなら、もしサービスを作っていく上で息詰まったり、サービスとは関係なさそうな要求がきたりなどした場合に
【地雷だらけ】“要件定義”とはそもそも何をすることか？【5分で理解】
政府CIO補佐官。ITプロセスコンサルタント。 元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員。 立教大学経済学部経済学科卒業後、NECソフト株式会社（現NECソリューションイノベータ株式会社）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エム株式会社にて、システム開発・運用の品質向上を中心に、多くのITベンダと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行なう一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は９割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年よ
第1回 三部作の表紙がつながるってすごいよね | gihyo.jp
2018年1月に羽生章洋著『はじめよう！ システム設計 ～要件定義のその後に』が発刊され、2015年から続く『はじめよう！ 要件定義 ～ビギナーからベテランまで』『はじめよう！ プロセス設計 ～要件定義のその前に』の上流工程三部作[1]が完結しました。今回から5回に分けて、著者である羽生章洋氏に三部作の執筆の裏側についてお話を伺います。 ――今日は羽生さんの「三部作」について、お話を……。 羽生：（唐突に）IT業界には、ちゃんと取材して、ちゃんと記事を書ける人が圧倒的に足りないと常々思ってるんですよ。どうみても「お前、技術知らないじゃん！」っていう感じの人が、思いつきで書いている感がすごいじゃないですか。 ――そ、そうですね……。大森（敏行）さん[2]が「技術を理解しようとしない記者はいずれ駆逐される」という記事を書いてましたね。でも、記者がITの専門家である必要はないので、なかなか難し
システム開発文書品質研究会 - 要求仕様書のサンプル
ソフトウェア要求仕様書のサンプル 人材育成部会では，経営者・管理者・技術者の啓蒙と育成を目的として，資料作りを行なっています． このページでは，その成果の一部として，文書品質を考えながら作成したソフトウェア要求仕様書のサンプルを公開します．私たちは，まず，「ムーブレボ」という仮想の電動一人乗り移動体（自動走行も可能な高機能な車椅子）を想定しました．そして，その移動体に搭載される複数の組込みシステムの一つとして，異常が発生した時にヘルプセンターへ知らせる「通報システム」を想定し，そのソフトウェア要求仕様書を書きました． 部会メンバが一人一人書き，ミーティング時に議論を重ねて書きなおしました．公開は，作者の自己判断で，順次行います．皆様のご参考になれば，幸いです． 実は，この活動を通じて，育成されているのは，この文書を書いたり，議論をしてきた人材育成部会のメンバ自身であることを強く感じています
【第3回】敏腕SIプロマネが語る -プロジェクト終盤・プロジェクト炎上時の打開策-｜プロジェクト管理・工数管理「クラウドログ」
社内プロジェクトマネージャーで、数々のプロジェクトを率いてきた経験を持つ佐藤誠氏が語る、三回にわたって掲載する「プロジェクト管理の極意シリーズ」の最終回です。 プロジェクト管理と一言で言っても、やるべきことは多くありますが、今回のシリーズでは受託開発のプロジェクトに焦点を当てて、それぞれのタスクごとにポイントをご紹介していきます。 最終回では、プロジェクト終盤やプロジェクト終了時にやるべきことや、プロジェクトがトラブル・炎上に陥った場合の対策についてのインタビュー記事を掲載します。 とりわけ、プロジェクト炎上時はマネージャーとして手腕を発揮するべきポイントですので、マネージャーとしての資質が問われるでしょう。 プロジェクト終盤 品質問題 プロジェクトも終盤戦に差し掛かると、品質の問題が気になってくることがあります。 時として、「機能的には問題ないけど、品質がいまいちだよね」などといった会話
【第2回】敏腕SIプロマネが語る -メンバー調整方法のポイント3つ-｜プロジェクト管理・工数管理「クラウドログ」
社内プロジェクトマネージャーで、数々のプロジェクトを率いてきた経験を持つ佐藤誠氏が語る、三回にわたって掲載する「プロジェクト管理の極意シリーズ」の第二回目です。 プロジェクト管理と一言で言っても、やるべきことは多くありますが、今回のシリーズでは受託開発のプロジェクトに焦点を当てて、それぞれのタスクごとにポイントをご紹介していきます。 第二回目では、協力会社も含めたプロジェクトメンバーの調整方法についてのインタビュー記事を掲載します。 メンバーいかんでは、プロジェクトの成否も変わってくるので、マネージャーとして重要な任務であるメンバー調整を、いかに行っているのか紹介していきます。 1.協力会社との契約交渉＝信頼関係の構築がポイント 協力会社との契約は、プロジェクトを円滑に進めていく上で、マネージャーの大きな役割の一つとなります。 基本的には、それまでにお付き合いのある既存の協力会社の中から面
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
要件定義とはそもそも何か
