TRACERY Lab.(トレラボ)

TRACERY開発チームが、要件定義を中心として、システム開発で役立つ考え方や手法を紹介します。

要件定義

RDRAで見積りを行う方法その2〜ウォーターフォール開発・工数編

システム開発の見積りは「経験」と「勘」に頼りがちで、担当者によって大きくぶれる課題があります。本記事では「RDRAx見積りシート」のウォーターフォール開発用シートを取り上げ、要件モデルから工数を算出する仕組みを解説します。RDRAで定義した画面・イ…

RDRAで見積りを行う方法その1〜要件モデルから工数・金額を自動算出する

要件定義完了後の概算見積りは、スコープや予算に関する意思決定を左右する重要なプロセスです。本記事では、RDRAで構造化された要件をもとに、根拠のある概算見積りを自動算出するツール「RDRA×見積りシート」の使用方法を解説します。同シートはシンプルフ…

要件定義をAIで加速する「RDRA Agent」その2〜要件を仕様化するRDRASpec

RDRA Agentの仕様化機能「RDRASpec」を紹介します。RDRASpecは、要件定義で整理した情報をもとに、論理データモデル・ビジネスルール・画面仕様の3種類の成果物を自動生成します。仕様化とは「何を実現したいか(要件)」を「どう実現するか(仕様)」へ変換…

要件定義をAIで加速する「RDRA Agent」その1〜LLMがモデルの叩き台を自動生成

シリーズ: モデルベース要件定義手法RDRA 要件定義手法RDRAの概要と全体像 RDRAによる要件定義の進め方〜第1フェーズ:枠組みを作る RDRAによる要件定義の進め方〜第2フェーズ:要件を組み立てる RDRAによる要件定義の進め方〜第3フェーズ(1):システムレ…

RDRAの成果物と設計プロセスとの連携

RDRAによる要件定義の成果物が、設計プロセスにどのように引き継がれるかを全体像として整理します。情報モデルを中心としたクラス設計(ドメインモデル)への対応、状態モデル・条件・バリエーションのクラス属性やメソッドへの反映、ユースケースに関連付…

RDRAによる要件定義の進め方〜第3フェーズ(2):整合性を確認し、精度を高める

RDRAによる要件定義では、システムを構成する要素同士の関係定義が増えるほど、定義漏れや参照ミスが発生しやすくなります。本記事では、こうした不整合を自動検出する「✖不整合」シートと、ユースケースを軸に要素間の関係を俯瞰できる「UC_PIVOT」シートの…

RDRAによる要件定義の進め方〜第3フェーズ(1):システムレイヤーの要素同士を関連付ける

本記事では、RDRAによる要件定義の第3フェーズ前半として、システムレイヤーの要素同士を関連付ける具体的な進め方を解説します。バリエーションと状態の違いを整理し、情報・条件とそれらをどのように結び付けるかを明確にすることで、ビジネスルールとデー…

RDRAによる要件定義の進め方〜第2フェーズ:要件を組み立てる

本記事は、要件定義手法RDRAの「第2フェーズ:要件を組み立てる」を解説します。要件を個別に並べるのではなく、ユースケースを起点に画面・イベント・タイマー、アクター/外部システムを関連付けてシステム境界を明確化。さらに情報・条件・状態を定義し、…

RDRAによる要件定義の進め方〜第1フェーズ:枠組みを作る

本記事では、モデルベース要件定義手法RDRAにおける「フェーズ1:枠組みを作る」の進め方を解説します。RDRAでは要件を個別に整理するのではなく、システム価値、業務、ユースケース、情報・状態といった要素をレイヤー構造で整理し、関係性を保ちながら要件…

要件定義手法RDRAの概要と全体像

本記事では、要件定義手法「RDRA(Relationship Driven Requirement Analysis)」の概要と全体像を解説します。RDRAは、要素同士の関係性を軸に要件を構造化し、業務・システムを一貫したモデルとして可視化することで、抜け漏れや認識齟齬、手戻りを防ぐア…

V字モデルの各レイヤー(要件定義、運用テスト・システムテスト編)

この記事では、V字モデルにおける「要件定義」「運用テスト」「システムテスト」プロセスの関係を体系的に解説します。 V字モデルでは、左側で定めた要件を右側のテスト工程で検証する構造になっており、要件定義は“何を作るか”を定めるプロセス、運用テスト…

要件定義と設計の関係を体系的に理解する【全体像まとめ】

本記事では、システム開発における要件定義と設計の関係を体系的に解説します。要件定義で整理された「何を作るか(What)」をもとに、「どのように実現するか(How)」を設計へと具体化する流れを、ソフトウェアアーキテクチャ設計、クラス設計、データベー…

要件定義のプロセスと成果物を体系的に理解する【全体像まとめ】

要件定義を成功させるには、流れを体系的に理解し、必要な成果物を正しく準備することが欠かせません。本記事では「要件定義とは何か」を整理し、要望から要求・要件へとつなぐ三層構造の考え方、業務フロー図やユースケース、ロバストネス図による具体化の…

移行要件とは何か

システム開発では、事業・業務・システム要件に加え、現行環境から新環境へ円滑に切り替えるための移行要求(移行要件)を定義することが不可欠です。国際的なビジネス分析ガイド BABOK では、この移行要求を「一時的に必要となる要件」として位置づけていま…

要件定義を学ぶ人におすすめの書籍まとめ

要件定義の学習や実務に役立つおすすめ書籍を厳選して紹介するまとめ記事です。入門者向けの「はじめよう!要件定義」から、業務要件定義を深く学べる「はじめよう!プロセス設計」、中級者向けの名著「ソフトウェア要求 第3版」、USDMを提唱する「要求を仕…

非機能要件とは何か

本記事は「非機能要件」をわかりやすく解説します。性能・可用性・セキュリティ・保守性など、機能要件では語れない“どう動くか”の品質を定義し、システムアーキテクチャ/ソフトウェアアーキテクチャへの具体的な落とし込みを紹介します。

要件とは何か

本記事では、システム開発における「要件」とは何かを、日本の現場特有の「要望→要求→要件」という三段階の整理と、事業・業務・システムといった階層構造の視点から解説しています。英語圏では Requirement という一語で包括されるのに対し、日本では合意形…

要件定義とバッチ処理設計

バッチ処理設計と要件定義の関係を解説します。バッチ処理は売上集計や在庫更新、帳票作成などに不可欠な仕組みであり、リアルタイム性よりも業務開始前までに正しく完了していることが求められます。記事では、機能要件としての入力・処理・出力の整理方法…

要件定義とAPI設計

API(Application Programming Interface)は、異なるシステムやアプリケーションをつなぐ重要な仕組みです。本記事では、特にWeb APIを対象に、要件定義とAPI設計の関係を解説します。外部公開APIの特性やRESTful APIの設計手法を取り上げ、機能要件を「入…

要件定義と画面設計

ユーザーに「使いやすい」と感じさせる画面設計には、直感的な操作と自然な導線が欠かせません。本記事では、システム開発における画面設計の基本から、ユーザーの思考順序(対象→操作)に基づいたオブジェクト指向UIの活用法までを詳しく解説。さらに、ナビ…

要求の妥当性を早期に検証する〜プロトタイプ、モック、ワイヤーフレームの活用と留意点

システム開発の成功には、要求の妥当性を早期に検証し、関係者間で認識を揃えることが不可欠です。本記事では、そのために活用されるワイヤーフレーム、モック、プロトタイプの違いと、それぞれの適切な使いどころ、注意点を解説します。ワイヤーフレームは…

要件定義とデータベース設計

システム開発におけるデータベース設計の重要性と、要件定義の成果物をどのように設計に反映するかを解説します。クラス設計とデータベース設計の違い、データ品質の観点、具体的な設計手法について詳しく説明しています。

要件定義とクラス設計

ソフトウェア開発における「関心の分離」と「高凝集」という重要な設計原則について、これらの概念がなぜ重要なのかを説明し、具体的な設計手法として「オブジェクト指向設計」を取り上げ、特にその中核となる「クラス設計」の考え方を紹介しています。 クラ…

要件定義とソフトウェアアーキテクチャ設計

本記事では、システム開発における要件定義とソフトウェアアーキテクチャ設計の重要性について解説します。要件定義で作成された成果物をどのように設計に活用するか、また設計プロセスの流れや観点を理解することで、要件定義の成果物の実用性や完成度を大…

ROUTE06社による要件定義のインタビュー記事が掲載されました

ROUTE06社に、要件定義の重要性と実践のポイントをテーマにインタビューしていただいた記事の紹介です。 特に要件定義の初期段階や、それ以前の企画・要求分析段階における考え方について掘り下げています。

ユースケースとロバストネス図によるシステム要件定義

本記事では、システム要件定義において ユースケースとロバストネス図を活用してシステムの要素を抽出する方法 を説明します。前回の記事では 業務フロー図を用いてユースケースを導出 しましたが、本記事ではそのユースケースを詳細化し、ロバストネス図を…

ユーザとベンダの想いは相反する〜 超上流から攻めるIT化の原理原則17ヶ条/ 原理原則その1

システム開発では、ビジネス側と開発側が協調し、ビジネス価値の創出に向けて動くことが求められます。『超上流から攻めるIT化の原理原則17ヶ条』の第1条『ユーザとベンダの想いは相反する』の原則は、システム開発において、ビジネス側と開発側が持つ責任の…

『超上流から攻めるIT化の原理原則17ヶ条』は、要件定義に取り組む全ての人に読んでほしい実践ガイド

要件定義を効果的に行うには、ビジネス側と開発側が協力し、互いの視点や目的を共有することが不可欠です。ビジネス側と開発側は具体的にどのように協力すればよいか、指針として参考になるのが、『*超上流から攻めるIT化の原理原則17ヶ条*』です。『超上流…

業務フロー図で見える化する業務プロセスからシステム要件への道筋

業務プロセスを構想し、整理する手段として、業務フロー図の作成が有効です。業務フロー図を作成する効果として、5W2Hの視点で業務の必要事項を漏れなく詳細化できること、業務の課題点発見とステークホルダー間の共通理解が促進されること、テスト設計や運…

事業・業務・システムの3階層で要件を捉える

事業要件、業務要件、システム要件の3層に要件を階層化することは、事業戦略から業務運営、システム構築に至るまでの整合性を保つために不可欠です。各層がどのように連携して全体目標と一致しているかが明確になり、組織全体としての方向性が統一されます。…