並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 35 件 / 35件

新着順 人気順

要求仕様書の検索結果1 - 35 件 / 35件

  • イチから全部作ってみよう(9)ジャンケンで理解する要求仕様書作成の難しさ

    イチから全部作ってみよう(9)ジャンケンで理解する要求仕様書作成の難しさ:山浦恒央の“くみこみ”な話(178)(1/3 ページ) ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第9回は、「ヒアリング」した内容をまとめる「要求仕様書作成」について、情報工学専攻の大学3年生でも悩む「ジャンケンの要求仕様書」を例にその難しさを解説します。

      イチから全部作ってみよう(9)ジャンケンで理解する要求仕様書作成の難しさ
    • イチから全部作ってみよう(3)MINORIに学べ、全ての悪は要求仕様書から生まれる

      今回は、要求仕様フェーズを進める時の問題点を解説します。ソフトウェア開発の全ての悪は、要求仕様書から生まれます。「パンドラの箱」のようなものですが、ちゃんと「希望」も残っています。 ⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 2.要求仕様フェーズでは何をするのか 図1に、新しいソフトウェアのアイデアを思い付き、それを製品化するまでの流れを示します。 2.1 要求仕様フェーズ ソフトウェア開発の最初の工程が「要求仕様フェーズ」で、頭の中のアイデアを具体的に記述する工程です。製品にできることや機能を細かく書いた要求仕様書を作ります。「要求仕様書」と聞くと、「大統領所信表明書」のように物々しく感じますが、電気製品を買うと付いてくる「製品取扱説明書」と完全に同じものです。 取扱説明書は、一般ユーザー向けのドキュメントで、そこには「(1)以下の部品がそろっていることを確認してください……、(

        イチから全部作ってみよう(3)MINORIに学べ、全ての悪は要求仕様書から生まれる
      • 「要求を仕様化する技術・表現する技術」から学ぶ要求仕様書作成テクニック - RAKUS Developers Blog | ラクス エンジニアブログ

        こんにちは、west-cです。 業務にて要件定義を行う機会があり、その成果物である要求仕様書の書き方を学ぶために『【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術』という書籍を読みました。今回はその内容をご紹介します。 【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術 ~仕様が書けていますか? 作者:清水 吉男技術評論社Amazon ◆ 関連ブログ 仕様書 とは 【まとめ】 おすすめの読者層 要求仕様書の目的・ゴールが曖昧な方 自身が作成した仕様書において、仕様漏れや仕様の衝突が後工程で発生したことがある or 発生しないか不安を抱えている方 依頼者から要求を引き出す方法の糸口を掴みたい方 要求仕様書とは 書籍では、要求仕様書を「要求について、関係者がその内容について認識を特定できている文章」と定義しています。 要求(今回の機能で実現したいこと)は曖昧なものを含

          「要求を仕様化する技術・表現する技術」から学ぶ要求仕様書作成テクニック - RAKUS Developers Blog | ラクス エンジニアブログ
        • 要件定義書と要求仕様書の違いを解説!誰が作るのか、進め方も解説

          要件定義書と要求仕様書の違いとは?システム開発プロジェクトに加わると、「要件定義書」や「要求定義書」、時には「要求仕様書」といった言葉を聞く機会が増えます。では、「要件定義書」や「要求仕様書」は何の目的で作成され、両者にはどういった違いがあるのでしょうか? システムエンジニアを目指す方は、それらの目的や意味、違いをしっかり押さえておく必要があります。ここでは「要件定義書」と「要求仕様書」の違いを題材として、システム開発の基本について解説していきます。

            要件定義書と要求仕様書の違いを解説!誰が作るのか、進め方も解説
          • イチから全部作ってみよう(7)正しい要求仕様書の第一歩となるヒアリングの手順

            1.はじめに 山浦恒央の“くみこみ”な話の連載第170回から、入門者をターゲットとして、「イチから全部作ってみよう」というシリーズを始めました。このシリーズでは、多岐にわたるソフトウェア開発の最初から最後まで、すなわち、要求仕様の定義、設計書の作成、コーディング、デバッグ、テスト、保守までの「開発フェーズ」の全プロセスを具体的に理解、経験することを目的にしています。第170回を読んでいない方は、以下のリンクから一読することをおススメします。

              イチから全部作ってみよう(7)正しい要求仕様書の第一歩となるヒアリングの手順
            • イチから全部作ってみよう(12)要求仕様書の異常系を階層構造を使って洗い出す

              上記では、例えば、「不良品を作った場合」「火傷をする」といった場合も考察しています。実際の「たこ焼き模擬店」の運営では、「異常系は、あらかじめ対処法は決めず、実際に発生してから、常識と良識で臨機応変に(あるいは、テキトーに)対応する」ことになるでしょう。 正常ケースでも、日常生活では、毎日、毎時、毎分、細かい判断をしています。朝起きて学校へ行くまで「目覚まし時計が鳴って、あと1分だけ寝ていようか?」「どのシャツを着ようか?」「歯磨きは十分か?」「髪形は見苦しくないか?」「バスの時間が迫っているので、走ろうか?」「前から来る歩行者を右に避けるか、左に避けるか?」「この地下鉄の車両は満員なので、隣の車両から乗ろうか?」など、無意識のうちに大量の判断をしています。プログラミングでは、この全ての判断を考慮しなければなりません。異常が発生した場合も同様です。そう考えると、朝、起床して学校へ行くのは、

                イチから全部作ってみよう(12)要求仕様書の異常系を階層構造を使って洗い出す
              • 要求仕様書とはなにか|daiki nishioka

                ※この記事は hey アドベントカレンダー2020 9日目の記事です。 STORES でプロダクトマネージャーとして働いている西岡(@nishiokadaiki1)と申します。 プロダクトマネージャーの重要な仕事である要求仕様書についてnoteをかきます。過去何度も要求仕様書らしいものは書いてきたのですが、最近の開発プロジェクトの中で書く意味や内容が、ようやく腹落ちした感覚があったので、hey アドベントカレンダーという良い機会にアウトプットしてみます。 要求仕様書とは最初に、要求仕様書とは何かを簡単に説明します。 要求仕様書とは、開発をする前にプロダクトマネージャーが、機能を実施する背景や内容、目的をまとめたものです。開発チームで実際につくる機能を議論していく土台となります。必要となる情報が欠けていたり、論理構造が破綻していると、議論が中々前に進まず、開発スピードが落ちてしまう原因になり

                  要求仕様書とはなにか|daiki nishioka
                • ソフトウェア技術者のためのバグ百科事典(7)要求仕様書がバグってる

                  1.はじめに このバグ百科事典では、筆者が気になったバグを紹介し、読者の方々に「バグの早期発見」と「バグの未然防止」に役立てていただくものです。本コラムによって、より良いソフトウェア開発のお役に立てればと思います。 ⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 2.要求仕様フェーズ ソフトウェア・ライフサイクルの中で最も重要なフェーズは、もちろん、要求仕様フェーズです。このフェーズでは、顧客が求める「機能」をキチンと聞き取り、要求仕様書にまとめます。例えば、エアコンのソフトウェアの場合、「機能」には、「室内を冷やす」「室内を暖める」「除湿する」「除菌する」などがあります。 要求仕様書をしっかり作成しないと、その後のフェーズでさまざまな問題が発生し、プロジェクトの進行に大きく影響します※1)。今回は、全工程の「最重要フェーズ」である要求仕様書のバグを取り上げます。 2.1 要求仕様が凍

                    ソフトウェア技術者のためのバグ百科事典(7)要求仕様書がバグってる
                  • 苦労せずにプロダクト要求仕様書を作成する方法 - Qiita

                    (原文) How to Write a Painless Product Requirements Document ドキュメントの大部分は初期段階で作成されますが、実装段階はUXデザインプロセスの中で最も重要な段階の一つです。 リサーチ、分析、デザインの各段階で多くのコンセプトを練ってきましたが、いよいよ重い腰を上げる時が来ました。ドキュメントが必ずしも製品と一致するわけではないことを理解しているので、ここでは必要なものだけを紹介します。 この記事では、Product Huntのプロダクト要求仕様書をベストプラクティスとして取り上げ、あなたのものにする方法を説明します。ぜひ無料のPRDテンプレートを使ってみてください。 プロダクト要求仕様書の作成方法 「試作」段階に入ると、それまでのリサーチやプロトタイピングによって、チームは製品についてのハイレベルな理解を得られるはずです。企業によって

                      苦労せずにプロダクト要求仕様書を作成する方法 - Qiita
                    • Notionで製品要求仕様書(PRD: Product Requirement Docs)を作成する方法

                      プロダクトマネージャーは、Notionのフォーマットを使って製品要求仕様書(PRD)を作成してみてはどうでしょうか。チームメンバーとより良いコラボレーションができ、部門を超えたコミュニケーションを実現できます。

                        Notionで製品要求仕様書(PRD: Product Requirement Docs)を作成する方法
                      • USDM-23. XDDPと「変更要求仕様書」|Kouichi Akiyama

                        2024年のアドカレです。 前回は「特定し、紐づけし追跡できるように要求と仕様にはIDを振る」という話を書きました。 データに識別子をつけることは、データをコンピュータで扱うときの基本中の基本なので「いまさらなにを」と思った方も多いと思います。 でも、やってみると「機能を表す記号」は何文字にしようか?とか、数字に意味を持たせるのはどうか?とか、「REC.03.02」の「03」部分は数字ではなく大分類を表す英文字とするのはどうか?とか、「02」と頭ゼロを付けるの?「2」じゃだめ? 等々、一人でUSDMを書いているのであれば好みで自然と決まるものも複数人でUSDMを書くときには事前にルールを決めておく必要があったりと……、なかなかやっかいなものです。 さて、今回はXDDPの話です。 キャッチイメージを再掲します。 XDDPとUSDMとPFDの関係XDDPはソフトウエアエンジニアリングの教科書に

                          USDM-23. XDDPと「変更要求仕様書」|Kouichi Akiyama
                        • USDM(要求仕様書を作成する時のお作法)の概要と、要求・理由・説明・仕様の書き方について、まとめてみました - Qiita

                          1.はじめに どうも、ARIの名古屋支社に勤務している愛知県民こと、 新藏(にいくら)と申します♪ (/・ω・)/ 突然ですが、某日に私は 「自分は社会人5年目で、基本設計、詳細設計、単体テスト、結合テスト、移行、保守等々は やったことあるけど、ばっこり要件定義をやったことはないな・・・」と考えていました。 何かしら勉強してみようということで、 今回はUSDMの概要や書き方について記事にしたいと思います! 要件定義、USDM等について勉強中の方の参考になれば幸いです。 (*^^)v ちなみに、12月はARIのアドベントカレンダもやっていますので、 もしよろしければ、こちらも応援お願いします♪ 2.USDMとは まずは、USDMの定義やメリット等について記載します。 USDMとは、「Universal Specification Describing Manner」の略で、 要求仕様を定義す

                            USDM(要求仕様書を作成する時のお作法)の概要と、要求・理由・説明・仕様の書き方について、まとめてみました - Qiita
                          • 要求仕様書とは? RFP・要件定義書との違いを解説 | 情シスBlog

                            要求仕様書と似ている言葉として、要件定義書、提案依頼書(RFP)があります。それぞれの文書がもたらす意味や目的などは、大幅に異なりますので違いを説明していきましょう。 提案依頼書(REP)のサンプルをご用意しております。ダウンロードの上、ぜひご活用ください。 RFP(提案依頼書)サンプル 要件定義書とは、システム開発において、顧客やユーザーのニーズやビジネス上の要求を具体的に整理し、それを実現するための機能や性能を明確にした文書です。この文書は、プロジェクトの初期段階で作成され、開発チームとクライアントの理解を一致させるための重要な役割を果たします。要件定義書には、ユーザーが望むシステムの機能、システムが満たすべき性能基準、操作性、セキュリティ要件、法的および規制上の制約などが含まれます。 要件定義書の作成は、システム開発プロジェクトにおいて成功の鍵となるものです。作成により、開発者は具体

                              要求仕様書とは? RFP・要件定義書との違いを解説 | 情シスBlog
                            • PRD一部Contents解禁!楽楽精算のPRD(製品要求仕様書) Agenda - RAKUS Developers Blog | ラクス エンジニアブログ

                              皆さん、こんにちは!もしくはこんばんは! 楽楽精算プロダクトマネージャーの@wekkyyyyです。 前回は「PdMとPMMの役割分担・連携」というテーマで記事をかかせていただきました。 tech-blog.rakus.co.jp 今回は、楽楽精算のPRD(製品要求仕様書) Agendaというテーマでブログを記載します。 目次は以下となります。 対象読者 前提 楽楽精算のPRD(製品要求仕様書) Agenda(一部) 一番重要と考えるAgenda Contentsサンプル ラクスのPdMとして活躍してみませんか? 対象読者 PRD(製品要求仕様書)を作成する、PdM(PM)・プランナー・PjM等の方々 前提 あくまで楽楽精算ではこうです。のサンプルですので、これが絶対!というものではございません。 会社・プロダクトごとにPdM(PM)等の役割定義は様々です。そのためどこまで書くかはそれぞれで

                                PRD一部Contents解禁!楽楽精算のPRD(製品要求仕様書) Agenda - RAKUS Developers Blog | ラクス エンジニアブログ
                              • PRD(プロダクト要求仕様書)をエンジニアが書く!エンジニアとPdMの分業体制|Cloudbase

                                クラウドセキュリティ製品 Cloudbaseでプロダクトマネージャーをしている大峠 (@0meo)です。 Cloudbaseでは、ソフトウエアエンジニアが “プロダクトエンジニア” として機能設計の上流から関わります。 本記事では、弊社が1つの機能を開発着手可能にするまでに実施するドキュメンテーション手法のノウハウと、プロダクトエンジニアとPdMが分業しながら権限委譲を進めた過程についてご紹介します! この記事を書いた人 大峠 和基(おおたお かずき) Cloudbase 株式会社 PdM 筑波大学大学院卒。学生時代からスタートアップ企業で研究論文の執筆や特許の出願に関わる。自動生成動画AIのサービスを開発して起業し、未踏事業スーパクリエータ認定及び未踏アドバンスト事業イノベータ認定を受ける。 2023年1月よりCloudbaseにジョイン。プロダクトマネージャーとして、データ分析やユーザ

                                  PRD(プロダクト要求仕様書)をエンジニアが書く!エンジニアとPdMの分業体制|Cloudbase
                                • PRD(製品要求仕様書)を常に最新の状態に保つ

                                  PRD (Product Requirements Document : 製品要求仕様書) は常に最新の状態に更新し続けましょう、という話をご紹介します。 PRD (Product Requirements Document : 製品要求仕様書) とは? PRD の書き方については、本記事では触れませんので以下の記事を読んでください。 スタートアップのための製品要求仕様書(MRD & PRD)の書き方 | by Hiroki Shimada | Medium 初めて書くPRD(プロダクト要求仕様書)|94|note PRD はプロダクト開発の道標 PRD はプロジェクト開発における道標だと考えており、作成・共有して、それを最新状態に更新し続けることが大切だと考えてます。 私自身、PRD を書いたことは以下のようなフローで進めていました。 (前提条件: スタートアップ企業での経験です) PR

                                  • 要件定義書と要求仕様書の違いを解説!誰が作るのか、進め方も解説

                                    要件定義書と要求仕様書の違いとは?システム開発プロジェクトに加わると、「要件定義書」や「要求定義書」、時には「要求仕様書」といった言葉を聞く機会が増えます。では、「要件定義書」や「要求仕様書」は何の目的で作成され、両者にはどういった違いがあるのでしょうか? システムエンジニアを目指す方は、それらの目的や意味、違いをしっかり押さえておく必要があります。ここでは「要件定義書」と「要求仕様書」の違いを題材として、システム開発の基本について解説していきます。

                                      要件定義書と要求仕様書の違いを解説!誰が作るのか、進め方も解説
                                    • 【悲報】NHK、営業基幹システム移行をIBMに依頼するも、要求仕様書では把握できない複雑構造が判明し大喧嘩に発展 : IT速報

                                      2025年2月4日、日本放送協会(以下、NHK)より、日本アイ・ビー・エム株式会社(以下、当社)に対し、営業基幹システムの開発・移行業務(以下、本プロジェクト)に関する業務委託契約の解除に伴う既払の代金の返還及び損害賠償を求める民事訴訟を東京地方裁判所に提起したこと、およびこれまでの経緯が公表されました。 当社は、本日時点において訴状を受領していないことから、NHKによる請求内容に関するコメントは差し控えますが、経緯に関する当社の見解についてご説明いたします。 本プロジェクトは、NHK指定の移行方針のもと営業基幹システムを新しい基盤へ移行するものであり、プロジェクト開始後に現行システムの解析を実施の上、移行方針及びスケジュール等を確定するという契約に沿って検討を進めてまいりました。 現行システムの解析を進める中で、提案時に取得した要求仕様書では把握できない、長年の利用の中で複雑に作り込まれ

                                        【悲報】NHK、営業基幹システム移行をIBMに依頼するも、要求仕様書では把握できない複雑構造が判明し大喧嘩に発展 : IT速報
                                      • USDM-12. 要求仕様書を“作るための文書”と定義する|Kouichi Akiyama

                                        2024年のアドカレです。 前回は「要求仕様書は、まず書いてみる。上手くいかなかった個所に気が付く。間違えた個所に戻って直していくといったツールである」という話を書きました。 今回の「要求仕様書を“作るための文書”と定義する」は前回と同じ話といえなくもないのですが、USDMの使い方を間違えないために書きます。 USDMの目指すところについて、ボタンの掛け違いがあるといけませんので、切り口を変えてしつこく書いておきたいのです。 「要求仕様書を“作るための文書”と定義する」という文に情報を補足して書き直すと、「USDMは、“システムを作るための文書”と定義する」となります。これは、清水さんの宣言であり自信の表れだと思います。 USDM本では、「5.3.2 「作るための文書」であることの好都合」に書いてあります。原文はちょっと長いので下記に要約します。 さてここで、“requirement”を“

                                          USDM-12. 要求仕様書を“作るための文書”と定義する|Kouichi Akiyama
                                        • 苦労せずにプロダクト要求仕様書を作成する方法

                                          (原文) How to Write a Painless Product Requirements Document ドキュメントの大部分は初期段階で作成されますが、実装段階はUXデザインプロセスの中で最も重要な段階の一つです。 リサーチ、分析、デザインの各段階で多くのコンセプトを練ってきましたが、いよいよ重い腰を上げる時が来ました。ドキュメントが必ずしも製品と一致するわけではないことを理解しているので、ここでは必要なものだけを紹介します。 この記事では、Product Huntのプロダクト要求仕様書をベストプラクティスとして取り上げ、あなたのものにする方法を説明します。ぜひ無料のPRDテンプレートを使ってみてください。 プロダクト要求仕様書の作成方法 「試作」段階に入ると、それまでのリサーチやプロトタイピングによって、チームは製品についてのハイレベルな理解を得られるはずです。企業によって

                                            苦労せずにプロダクト要求仕様書を作成する方法
                                          • 大手メーカでSEを担当、コーディング経験はほぼありません。設計等もほとんど外注で要求仕様書でさえ適当に書いている状態です。今後のため転職したいのですが、スキルを独学で身につけてからのが良いでしょうか?

                                            回答 (20件中の1件目) 大手インフラ関係の会社でSEを担当、40歳を超えているものの役付きではなくコーディングから設計から要求仕様から要件定義からリードの脇や陰でやっている状態です。将来のために現実の一つをお伝えしたいと思ったので回答してみます。 自分の周りをよく見てみてください。なりたい姿には今の環境でもなれます。 「環境が人を作る」と言われます。これは事実そうだと思います。するとご質問のように転職で環境を求めるという考え方になるのも頷けます。環境を求めて転職していく人も周囲にはいました。 ただ…私は虚しく思ってしまうのです。ご質問のように考える人が「技術的なスキルを活かす道...

                                              大手メーカでSEを担当、コーディング経験はほぼありません。設計等もほとんど外注で要求仕様書でさえ適当に書いている状態です。今後のため転職したいのですが、スキルを独学で身につけてからのが良いでしょうか?
                                            • KDDI、バックボーンネットワークの処理容量が最大614.4Tbpsの次世代分散型大容量ルーター開発に向けた要求仕様書を完成|BUSINESS NETWORK

                                              KDDI、バックボーンネットワークの処理容量が最大614.4Tbpsの次世代分散型大容量ルーター開発に向けた要求仕様書を完成 KDDIグループ キャリアインフラ ルーター/スイッチ KDDIは2021年6月8日、米Facebookが推進するTelecom Infra Project (以下、TIP) において、バックボーンネットワークの通信制御を担う次世代分散型大容量ルーターのハードウェアおよびソフトウェアの要求仕様書の作成を今年4月に完了したと発表した。 KDDIは、2020年3月に設立したTIP Open Optical Packet Transport (OOPT) プロジェクト内の新たなサブグループDisaggregated Open Routers (以下、DOR) の議長として、通信事業者のバックボーンネットワークにおけるルーターのホワイトボックス化に向けた技術開発を進めている

                                              • 要求仕様書記述手法「USDM」について思う - ヒャッハー!ふっくら太郎です。

                                                こんちは。志望校がふっくら太郎になる。 ふっくら太郎です。 今回は、USDMについて、ちょろっと勉強する機会があったので、感想を書きます。 USDMは、普段の業務の中で触れてはいるのですが、仕様書のフォーマット程度の認識 しかなく、こんなかっこいい名前があることすら知りませんでした。 先日、ある方に教えてもらう機会があり、興味を持ち勉強した次第です。 USDMって何や? USDMは、「Universal Specification Describing Manner」の略語で、要求と仕様の記載方法を定義したもの 株式会社システムクリエイツの清水 吉男さんが提唱している。数冊本が出てます。 [改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか? 作者: 清水吉男 出版社/メーカー: 技術評論社 発売日: 2010/05/01 メディア: 単行本(ソフトカバ

                                                  要求仕様書記述手法「USDM」について思う - ヒャッハー!ふっくら太郎です。
                                                • イチから全部作ってみよう(3)MINORIに学べ、全ての悪は要求仕様書から生まれる

                                                  3.顧客からのヒアリング 本シリーズでは、ECサイトを例に、要求仕様、設計、コーディング、デバッグを実際に進めます。最初の要求仕様フェーズの目標は、顧客と協議し、顧客が求めるECサイトをヒアリングし、要求仕様書を作成することです。 上記のように、要求仕様書とは、「カゴに商品を入れて、購入ボタンを押すと注文処理を行う」といった「ECサイトでできることの一覧」で、「こんなこともしたい」「これも盛り込んでほしい」という顧客の意見を聞きながら、ECサイトの機能を決めていきます。簡単な例を下記に示します。 顧客の要求例:会員のためのログイン機能をつけたい 要求仕様書:IDとパスワードを入力し、ログインボタンを押下すると、ログイン処理を行う 顧客の要求例:商品点数が多いため、検索する機能をつけたい 要求仕様書:検索キーワードを入力し、検索ボタンを押下すると、ヒットする商品を表示する これらは要求仕様の

                                                    イチから全部作ってみよう(3)MINORIに学べ、全ての悪は要求仕様書から生まれる
                                                  • PRD(プロダクト要求仕様書)とPoCを自動作成するプロンプトとGPTs|IT navi

                                                    ChatGPTの最新モデルのGPT-4oは、簡単なプロンプトでプロダクト開発プロジェクトに必要なPRD(プロダクト要求仕様書)やPoC(概念実証)を作成することができます。 今回は、これらを作成するためのプロンプトとGPTsについて解説します。 1.PRDとPoC(1) PRDとはPRDは「Product Requirement Document」の略で、プロダクト要求仕様書と訳されます。これは、プロダクト開発プロジェクトにおいて、プロダクトの要件や仕様を明確に記述した文書です。PRDは、開発チームやステークホルダーが共通の理解を持ち、プロジェクトをスムーズに進行させるために重要です。以下はPRDの主な構成要素とその内容です。 1. 目的と背景 目的: PRDの作成目的や、プロダクトが解決する問題、ターゲット市場などを記述します。 背景: 市場の現状、競合分析、ユーザー調査結果など、プロダ

                                                      PRD(プロダクト要求仕様書)とPoCを自動作成するプロンプトとGPTs|IT navi
                                                    • 要求仕様書|VBAで人の為に作る開発ドキュメント - ゆんの業務改善ブログ

                                                      この記事は非エンジニアの会社員で現業を持ちながらVBAでたまに自動化ツールを作っているというような方を読者として想定しています。 目次 非エンジニアに必要な開発ドキュメント3つのうちの要求仕様書 要求仕様書とは VBA開発に詳細な要求仕様書はいらない 要求仕様書の目的を意識する 要するに何が必要なのかを記述する VBA開発における要求仕様書の作成手順 非エンジニアに必要な開発ドキュメント3つのうちの要求仕様書 会社員がVBAで自動化するのに必要な開発ドキュメント3点で解説した通り、非エンジニアがVBAで他人が使うことを全停止としたツールを開発をするには要求仕様書、仕様書、チェックリストの3つの開発ドキュメントを用意すべきです。 今回はそのうち、要求仕様書について解説します。 要求仕様書とは 要求仕様書とはユーザーがソフトに要求する機能を記した開発ドキュメントです。細かく言えば要求仕様書の中

                                                        要求仕様書|VBAで人の為に作る開発ドキュメント - ゆんの業務改善ブログ
                                                      • バックボーンネットワークの処理容量が最大614.4Tbpsの次世代分散型大容量ルーター開発に向けた要求仕様書が完成 | KDDI News Room

                                                        KDDI株式会社 KDDIは、Facebook, Inc. (本社: メンローパーク カリフォルニア州、CEO: マーク・ザッカーバーグ) が推進するTelecom Infra Project (以下 TIP) において、バックボーンネットワーク (注1) の通信制御を担う次世代分散型大容量ルーターのハードウエアおよびソフトウエアの要求仕様書の作成を、2021年4月に完了しました (注2)。これにより、開発パートナー・ベンダーは既存の製品から約3倍となる最大614.4Tbpsの処理が可能なルーターの開発が可能となり、通信事業者の5G設備の構築に貢献します。 <大容量ルーターのイメージ> KDDIは、2020年3月に設立したTIP Open Optical Packet Transport (OOPT) プロジェクト内の新たなサブグループDisaggregated Open Routers

                                                          バックボーンネットワークの処理容量が最大614.4Tbpsの次世代分散型大容量ルーター開発に向けた要求仕様書が完成 | KDDI News Room
                                                        • イチから全部作ってみよう(11)たこ焼き屋模擬店の要求仕様書を抜け漏れなく作る

                                                          今回は、前回作成したたこ焼き模擬店の要求仕様書をより詳細化します。 3.たこ焼き模擬店で考える要求仕様書の問題点 理想的な要求仕様書は、正常時だけでなく、異常時、限界時も含めて、発注側の要求事項を漏れなく明確にまとめ、見聞きしたことがない人にも伝わる文書とすることです。しかし、これは簡単なことではありません。前回のたこ焼き模擬店の要求仕様書から発生し得る問題点を考えます。 ソフトウェアの開発は、人類が作る人工物の中で、圧倒的に高難度です。これには、(1)規模が大きい、(2)適用しなければならない自然界の法則がない(考え方さえ正しければ、何でもOKの「芸術」を工学的に作るようなものです)、(3)目に見えない、(4)異常処理、境界処理、特殊条件が多過ぎる、という4つの理由があります。 (4)に関して、人間は一切間違えず、悪意満載の行為もせず、全ての機器が正常に動作するならば、世の中の処理や作業

                                                            イチから全部作ってみよう(11)たこ焼き屋模擬店の要求仕様書を抜け漏れなく作る
                                                          • PRD(プロダクト要求仕様書)とは

                                                            製品ビジョンの共有に必要となり、密なコミュニケーションとチームに合ったドキュメントが必要となる 製品を作るために必要な全ての工数を記載する また、プロジェクトの背景などもあれば記載し、複数名でも共有可能なものとする 最大の目的は、ユーザが製品をどのように利用するのかのストーリーを伝えることであり、技術的な詳細はあまり書かれない Product Requirements Document : 製品要求仕様書 一言で表すなら、開発関係者でプロダクトの前提や認識を合わせ、意思疎通するためのもの 役割として大事な部分は認識を揃えること 大きくは Why: なぜ開発するのか What: 何を開発するのか How: 開発をどうやって実現するのか Why: なぜ開発するのか プロダクトの目的や意義、背景となり、そもそもなぜ開発をするのかを明確にする ターゲットユーザー プロダクトのユーザーは誰か どんな

                                                              PRD(プロダクト要求仕様書)とは
                                                            • 競争を制する!ユーザー要求仕様書が叶える新規事業の要件定義 - ROUTE06 Professional Services

                                                              新規事業を成功に導くためには、迅速な意思決定と柔軟な対応が欠かせません。しかし、プロジェクトの初期段階で多くの不確定要素に直面し、要件定義に時間がかかりすぎることが課題となります。これを解決する手段として注目されているのが「ユーザー要求仕様書」です。本記事では、その基本的な役割から具体的な活用方法までを解説し、新規事業における要件定義を成功に導くヒントを提供します。 徹底した顧客分析と競合リサーチで要件の土台を作る 新規事業の成功を支える要件定義の鍵は、顧客分析と競合リサーチにあります。これらは単なるデータ収集ではなく、顧客が本当に求める価値と競争市場における自社の立ち位置を明確にするプロセスです。以下の詳細な視点から、それぞれの重要性と実践方法を解説します。 顧客インサイトを深掘りして隠れたニーズを発見する 顧客インサイトを引き出すことは、効果的な要件定義の出発点です。顧客が抱える課題を

                                                                競争を制する!ユーザー要求仕様書が叶える新規事業の要件定義 - ROUTE06 Professional Services
                                                              • USDM-11. 要求仕様書は仕様を決定する過程を表現したもの|Kouichi Akiyama

                                                                2024年のアドカレです。 前回は「不完全な仕様が与えられたときには要求を想像して、要求を立ててから、立てた要求の正しさを確認する」という話について書きました。 「言うは易く行うは難し」ですが、第13回で示すUSDMのテンプレートを使用すると、要求と仕様の対応チェックは楽になるので「要求の記載が足りない」ことまでは気が付きます。 ここから、適切な要求を想像し、確度の高い仮説が立てられるかどうかは経験によります。清水さんの言う通り「観察力と洞察力を日々鍛える」ことは大事かなと思います。 今回の「要求仕様書は仕様を決定する過程を表現したもの」と次回の「要求仕様書を“作るための文書”と定義する」は、「そもそも要求仕様書とは、何だろう?」という問いです。 USDMのテンプレートの意味になります。 USDM本に以下の記載があります。 要求を仕様化するということは、仕様を「決めていく」作業でもあるので

                                                                  USDM-11. 要求仕様書は仕様を決定する過程を表現したもの|Kouichi Akiyama
                                                                • 【プラント設計の失敗事例】顧客からの要求仕様書を読まずに受注して大変なことに! | プラントエンジニアは語る

                                                                  みなさんこんにちは、プラントエンジニアのヤンです。 前職では顧客向けにプラントを設計製作納入する仕事をしていたので、自社の設計基準+顧客の設計基準の両方を適用する必要がありました。 ですので、時には数百ページに及ぶ設計基準書から適用されるところを抜粋して、仕事を進めていく必要がありました。 非常に時間のかかる作業でしたが、これを怠り顧客の設計基準を満足できない、つまり顧客要求を満足できないと、プラントとしての能力は問題なくても納入できない恐れがあります。 もちろん、プラントとしての能力が発生できなければ大問題です。 すこし古い話ですがこのような事例もあります。これはかなり極端な事例だと思いますが。 住友重機、焼却灰施設を巡る紛争の全貌京都地裁での判決は2016年の5月27日に出ているようですが、この後どうなっているんですかね? ここで、僕がどんなトラブルに遭遇して来たかを書くことで「顧客満

                                                                    【プラント設計の失敗事例】顧客からの要求仕様書を読まずに受注して大変なことに! | プラントエンジニアは語る
                                                                  • USDM-14. 要求仕様書の作成手順|Kouichi Akiyama

                                                                    2024年のアドカレです。 前回は「USDMのテンプレート」について書きました。 テンプレート自体はシンプルで、改変もしやすいですから、すぐに使いこなせると思います。 問題なのは、このnoteで書いてきた「要求」、「理由」、「仕様」が清水さんが理想とした要求仕様書のレベルで書けるかどうかです。 今回は、「要求仕様書の作成手順」がテーマですが、その結論は「USDMの表を上から順に埋めていき、ひととおり出来たら見直す」です。 当たり前すぎて申し訳ない気もするのですが、「見直す」ことを負けと思っているのか、見直さない人が多いので書いています。 たとえUSDMのフォーマットで書いたとしても良い要求仕様書を一度で書くことは困難です。少なくとも私には無理です。 前回のUSDMテンプレートの行のグルーピングを使って、同じ階層の仕様のレベルがあっているかを確認したり、要求や仕様の抜け漏れを何度も何度も確認

                                                                      USDM-14. 要求仕様書の作成手順|Kouichi Akiyama
                                                                    • 第7回 開発者を悩ませない要求仕様書USDMのマナーとは

                                                                      仕様とは、要求に含まれる「具体的」な処理や振る舞いを表現したものです。 仕様は、開発者および関係者がSpecify、つまり「特定」できる状態まで正確に記述します。それがUSDMのマナーです。 仕様は、4つの条件を満たしている必要があります。 「要求から」導出されている すべての仕様はいずれかの要求に属します。すなわち、要求が適切に表現されていないと仕様は引き出せません。 設計者の立場から実現可能性が見える 具体的なので、どう作ればよいか見当がつき、「仕様の矛盾」も見えます。 評価担当の立場から検証可能性が見える どうすれば検証できるか見当がつき、関係者間での意味解釈のずれを防止できます。 品質要求も例外ではない 品質要求に対する仕様も、機能要求と考え方は同じで、実現可能性と検証可能性が求められます。 要求仕様をどこまで特定するか?

                                                                        第7回 開発者を悩ませない要求仕様書USDMのマナーとは
                                                                      • PRD ( Product Requirements Document, プロダクト要求仕様書)まとめ - kaeken(嘉永島健司)Techブログ

                                                                        PRD (Product Requirements Document) 概要 PRDの概要と特徴 PRDの分類と上位・下位概念 PRDのメリット PRDのデメリット 既存との比較 競合 導入ポイント 注意点 今後 関連キーワード まとめ PRD(プロダクト要求仕様書)の記述項目と説明 PRDに含まれる主な項目と説明 1. 概要 2. 背景 3. プロダクトプリンシプル 4. 機能要件 5. 非機能要件 6. UX要求 7. システム要求 8. その他 PRDを作成する上でのポイント PRDのメリット PRD作成ツールの活用 PRD具体例 まとめ PRD (Product Requirements Document) 概要 PRDの概要と特徴 Product requirements document - Wikipedia PRD(Product Requirements Document

                                                                          PRD ( Product Requirements Document, プロダクト要求仕様書)まとめ - kaeken(嘉永島健司)Techブログ
                                                                        1