Cozyモデル駆動開発/ユースケース/include

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法について考えています。

ユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行い、CML(Cozy Modeling Language)で記述する方法について考えました。

前回はユースケース間の関係のモデルについて整理しました。

今回からユースケース間の関係のどのようにCMLで記述するか、という観点で具体的な記述方式を検討していきます。

今回はincludeを取り上げます。

include

• マージモード : Include
• マージ点 : 任意Step
• 機能 : 共通動作の再利用
• UML include

includeの意味

include は、あるユースケースが実行される際に、必ず別のユースケースの振る舞いを含めて実行することを表す関係です。

UML における include は、

• 元ユースケースの処理の途中に
• 常に同一の共通処理が組み込まれる

という意味を持ちます。

典型的な例としては、次のようなものがあります。

• 「商品を購入する」が「在庫確認」を含む
• 「会員購入」が「ログイン処理」を含む
• 「注文処理」が「本人確認」を含む

include される側のユースケースは、単独で完結する利用を想定しない点が重要です。共通処理を再利用するための、意味的に独立した単位として定義されます。

Cozyモデルにおける include の位置づけ

Cozyモデルでは、ユースケースを単なる図形要素ではなく、

• 構造化された要求
• ステップ列として表現される振る舞い
• 再利用可能な意味単位

として扱います。

この観点から include は、

• 共通処理をコピーするのではなく
• 振る舞いを独立したユースケースとして切り出し
• 必要な箇所に合成する

ための仕組みと位置づけられます。

Cozyモデルにおける include は、

• ユースケースのステップ列を、別のユースケースのステップ列に合成する関係

として捉えることができます。

記述方式

シナリオ中のincludeの記述方式は以下の通りです。

- include <UseCaseName>

includeディレクティブを指定してincludeステップであることを示します。includeの次にあるのがincludeするユースケース名です。

記述例

- [select] 社員: 希望する日時と会議室を選択する。
- include CheckAvailability
- 社員: 会議の目的を入力する。

この記述は、

• CheckAvailability ユースケースの MainFlow に定義された
• ステップ列を
• この位置に展開・合成する

ことを意味します。

基本方針

CML において include は、ユースケース間の外部的な関連としてではなく、

• ユースケース定義の内部に
• 明示的な合成指示として

記述する方針を取ります。

このとき、以下の点を重視します。

• include は方向を持つ
• include されるユースケースは再利用単位である
• マージ点（どのステップに含めるか）を明確にできる

UML include との対応

UML	Cozy / CML
include 関係	ステップ合成
共通処理	再利用ユースケース
図による表現	テキストによる構造表現
実行時に必須	常に合成される振る舞い

UML で矢印として表現されていた include 関係を、CML ではユースケース内部の構造として記述する点が特徴です。

UMLの場合、概念的に指定されたユースケースを取り込むというところまでの指定になりますが、その具体的な実現をCozy/CMLではユースケース・シナリオで行うことができる分けです。

まとめ

今回は、ユースケース間の関係の一つである include について、

• UML における意味
• Cozyモデルとしての解釈
• CML による記述方針と表現方法

を整理しました。

include は、共通動作の再利用を目的とし、ユースケースのステップ列を合成する関係として扱うことで、図に依存しない、意味的に明確な要求モデルを記述できます。

次回も引き続いてユースケース間の関係について具体的な記述方式について考えます。

Cozyモデル駆動開発/ユースケース・モデル間の関係

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法について考えています。

ユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行い、CML(Cozy Modeling Language)で記述する方法について考えました。

前回はユースケース記述の基本フォーマットについて考えました。

今回からユースケース間の関係のモデルについて考えていきます。

ユースケース間の関係の候補

CMLに取り入れるユースケース間の関係の候補を表にまとめました。表中のREはRequirement Engineeringを示します。

関係	マージモード	マージ点	機能	由来
include	Inline	任意Step	共通動作の再利用	UML include
extend	ConditionalInline	After指定	条件付き拡張	UML extend
generalize	Inherit/Override	Override	シナリオ継承	UML generalization
precedes	Sequence	After end	シナリオ連結	Workflow / BPMN
triggers	EventDriven	After condition	イベント駆動	Event-driven modeling
requires	Prepend	Before start	事前条件統合	RE preconditions
ensures	Append	After end	事後条件統合	RE postconditions
collaborates	Parallel	同期点	並行・協調動作	Workflow patterns
conflicts	Branch	条件分岐	排他シナリオ	Goal/Feature modeling
supersedes	Replace	Full	上書き置換	Scenario evolution
references	ReferenceOnly	N/A	ドキュメント参照	Traceability

伝統的な手続き型の処理に加えて、イベント駆動による処理についてもモデル化できることを目標にしています。

ユースケース関係の由来

候補としてまとめたユースケース間の関係の、意味上のマージ方式・シナリオ統合のふるまい・歴史的な由来に基づき関係を分類します。

UML系統

• include
• extend
• generalize

UMLユースケースの主要関係に由来します。SimpleModelingではより厳密な意味統合として再解釈する予定です。

Workflow / BPMN 系統

• precedes（順次）
• collaborates（並行・同期）

ワークフローパターンおよびBPMNゲートウェイの意味モデルに対応します。

Event-driven 系統

• triggers

外部イベントや条件成立によってシナリオが起動する関係を示します。

Requirements Engineering 系統

• requires（事前条件）
• ensures（事後条件）

要求工学の前後条件モデルを、流れとして統合できるよう拡張します。ユースケース記述の項目とユースケース図の2つの観点で検討を進める予定です。

Goal / Feature モデリング系統

• conflicts（排他・競合）

KAOS(要求工学の代表的なゴール指向モデリング手法)などのゴール競合、Feature ModelのXOR制約への対応について検討します。

シナリオ進化系統

• supersedes（置換）

シナリオの置換は要求工学やUPでも出てくる概念ですが、ユースケース・モデルにおけるユースケース関係として定義されていません。CMLでのサポートの有無を含めて検討予定です。

トレーサビリティ系統

• references

モデルの管理上、使用する可能性のある関係です。CMLでのサポートの有無を含めて検討予定です。

まとめ

今回はユースケース間の関係について整理しました。

次回から、それぞれの関係についてユースケース記述やシナリオでの記述方式について検討します。

Cozyモデル駆動開発/ユースケース・モデルのシナリオをCMLで記述

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法について考えています。

ユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行い、CML(Cozy Modeling Language)で記述する方法について考えました。

今回からシナリオ記述のCML文法について考えていきます。

今回はtユースケース記述の基本フォーマットです。

ユースケース記述の基本フォーマット

ユースケース記述では、シナリオを時系列のステップとして記述するシナリオ記述が必要となります。

この目的のシナリオ記述のCMLは以下のものになります。「会議室を予約する」の節には基本情報、拡張方法などが定義されますが省略しています。

# UseCase
## 会議室を予約する
### MainFlow
- [open] 社員: システムを開き、「会議室予約」メニューを選択する。
- システム: 予約可能な会議室一覧を表示する。
- [select] 社員: 希望する日時と会議室を選択する。
- [check] システム: 選択された会議室の空き状況を確認する。
- 社員: 会議の目的と参加者を入力し、予約を確定する。
- [confirm] システム: 予約を登録し、確認メッセージを表示する。
- end
### AlternateFlow
A1. [check] 会議室が満室の場合  
  - システム: 「選択された時間帯は満室です」と表示する。  
  - 社員: 別の会議室または時間帯を選択する。  
  - システム: 新しい候補を再表示する。  
  - goto select
A2. [select] 日時が未指定の場合  
  - システム: 「日時を入力してください」とメッセージを表示する。  
  - 社員: 日時を入力し、再度会議室を選択する。  
  - goto select
A3. [confirm] 予約完了後に内容を変更したい場合  
  - 社員: 「予約一覧」から対象の予約を開く。  
  - call ModifyReservation
### ExceptionFlow
E1. [confirm] データベースエラーが発生した場合  
  - システム: エラーログを記録する。  
  - システム: 「予約を登録できませんでした」とエラーメッセージを表示する。  
  - abort
E2. [open] セッションがタイムアウトしていた場合  
  - システム: ログイン画面にリダイレクトする。  
  - 社員: 再度ログインしてから操作を続行する。  
  - goto open

文法の説明

ステップの文法

要素	説明	例
-	ステップを表すリストマーカー。1行に1ステップを記述する。	- [open] 社員: システムを開く。
[id]	ステップの識別子（省略可）。他のフローから参照可能。	[select], [check]
actor:	ステップの実行者（省略可）。主に「社員」「システム」など。	社員:, システム:
action	自然言語による行動・応答の記述。	会議室一覧を表示する。
directive	フロー制御のための命令文。整形時に自然文化される。	goto select, abort, end

• ステップはユースケースの基本的な単位である。各行の - から始まる文は、ユースケースの中で行われる一つの行動または反応 を表す。それは「誰が何を行うか」を記述するための最小構成要素である。

• [id] はステップの恒久的識別子である。ステップに付与された [id] は、他のフロー（AlternateFlow や ExceptionFlow）から参照するための安定した論理的ラベルとして扱われる。ステップ番号ではなく識別子を用いることで、将来的な編集（挿入・削除）に強くなる。

• actor: は行為主体を示す。これはシナリオの主語に相当し、通常は「ユーザ」または「システム」である。省略された場合は、文脈（前のステップやUseCase全体のactor）から推定される。

• action は自然言語での行動・応答の記述である。行動（Actorの操作）と応答（Systemの出力）を同一形式で表現できる。文体は「〜する」「〜を表示する」といった手続的な叙述形式で統一するのが望ましい。

• directive は制御的命令として扱う。goto, call, end, abort などはシナリオの制御フローを明示する命令であり、整形段階で自然文（例：「処理は id に戻る。」）に展開される。これにより、読みやすさと機械可読性の両立が実現される。

1. 構造上の意味各ステップは UseCaseScenario の中で順序を持つ要素であり、Cozyモデル上では UseCaseStep エンティティとして表現される。この構造により、シーケンス図生成やテストケース展開などへの転用が可能となる。

代替フローの文法

要素	説明	例
### AlternateFlow	セクション見出し。代替フローの開始を示す。	### AlternateFlow
A1.	代替フローの識別子（A＋番号）。	A1.
[ref]	分岐元となるMainFlowステップの識別子。	[check], [select]
条件文	代替フローが発生する条件を自然文で記述する。	会議室が満室の場合
ステップ列	代替フロー内での処理をステップ構文で記述する。	- システム: ...
directive	復帰や呼出しを示す制御命令。整形時に自然文化される。	goto select, call ModifyReservation

• 分岐元ステップ（ref）AlternateFlowは、指定されたMainFlowステップを起点として分岐する。例：A1. [check] は MainFlow の [check] ステップから派生。

• 条件（Condition）分岐が発生する具体的な状況を自然言語で記述する。書式上は [ref] 条件 の形をとる。

• 代替処理（ScenarioStep群）代替フロー内での詳細な行動をステップ構文で記述する。各ステップは - [id] actor: action 形式。

• 復帰点（Directive）フローの末尾で、通常 goto ディレクティブを使い MainFlow に戻る。整形時には「処理は id に戻る。」と自然文化される。

例外フローの文法

要素	説明	例
### ExceptionFlow	セクション見出し。例外フローの開始を示す。	### ExceptionFlow
E1.	例外フローの識別子（E＋番号）。	E1., E2.
[ref]	対応するMainFlowステップの識別子。	[confirm], [open]
条件文	発生する例外やエラーの内容を自然文で記述。	データベースエラーが発生した場合
ステップ列	異常処理の流れをステップ構文で記述。	- システム: エラーログを記録する。
directive	終了・復帰を指示する制御命令。整形時に自然文化される。	abort, goto open, end

• 発生元ステップ（ref）ExceptionFlowは、指定されたMainFlowステップに対応する異常時処理を定義する。例：E1. [confirm] は、MainFlowの [confirm] ステップでエラーが起きた場合の処理を表す。

• 条件（Condition）例外が発生する具体的な原因や状況を自然文で記述する。例：「データベースエラーが発生した場合」「認証が失敗した場合」など。

• 異常処理ステップ（ScenarioStep群）エラー検出後に実施される一連の処理（通知・再試行・停止など）を - [id] actor: action 形式で記述する。

• 終了／復帰（Directive）処理終了や再試行を示す命令を用いて、制御の戻り先または中断を明示する。整形時には「処理を中断する。」「処理は id に戻る。」などに展開される。

整形規則

シナリオ内で使用したdirectiveの整形規則です。

原文	整形出力
goto select	処理は select に戻る。
call ModifyReservation	処理は ModifyReservation を呼び出す。
end	処理を終了する。
abort	処理を中断する。
repeat open	open から繰り返す。

まとめ

今回はシナリオ記述の基本的なCML文法について考えました。

次回はユースケース間の関係のモデルについて考え流予定です。

Cozyモデル駆動開発/ユースケース・モデルの拡張情報をCMLで記述

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法について考えています。

前前回にユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行いました。

前回はユースケース記述の基本情報をCML(Cozy Modeling Language)で記述する方法について考えました。

今回は拡張情報をCMLに追加します。

ユースケース拡張情報

前々回に定義したユースケースの拡張情報の構造です。

name	type	mult	description
secondary actor	name	?	セカンダリ・アクター
supporting actor	name	*	スポーティング・アクター
precondition	text	*	事前条件
postcondition	text	*	事後条件
priority	token	?	優先度
status	token	?	状態

ユースケース

CMLで記述したユースケース記述基本情報に拡張情報をを追加したものを以下に示します。

項目の内容に応じてプロパティ方式とセクション方式を混在させています。

ユースケース
==========
# UseCase
## 顧客の商品の予約を申請する
| Name             | 顧客の商品の予約を申請する                    |
| Id               | UC0056                                   |
| Primary Actor    | 販売担当者                                 |
| Secondary Actor  | 顧客                                      |
| Supporting Actor | よろず販売システム（在庫管理・予約管理機能）     |
| Goal             | 顧客が希望する商品の在庫を確保し、予約状態とする |
| Triger           | 顧客の予約依頼                              |
| Priority         | 高                                        |
| Status           | 設計済み・実装予定                          |
### Summary
販売担当者は、顧客からの希望商品について予約を申請し、在庫の確保を行う。予約が確定すると、顧客は商品を後日受け取ることができる。
### Precondition
- 顧客が購入意向を持ち、商品を特定している
- 商品が予約対象として登録されている
- 販売担当者がログイン済みである
### Postcondition
- 対象商品が「予約済み」状態として在庫管理に登録される
- 顧客情報と予約内容が記録される
- 確認メッセージが販売担当者および顧客に通知される

説明

基本項目中の以下の項目をセクション形式にしました。

summary

ユースケースの簡潔な説明

以下の拡張情報の項目を表に追加しました。

Secondary Actor

Primary Actorの目的を達成するための協力をするアクター。Primary Actorの相手役。

Supporting Actor

ユースケースで支援的な役割を果たすアクター

Priority

優先度

Status

ユースケースの管理状態

また、以下の拡張項目をセクションとして追加しました。

precondition

事前条件

postcondition

事後条件

まとめ

今回はユースケース記述の拡張情報をCMLで記述する方式について考えてみました。

次回はシナリオ記述についてCMLでの定義について考えていく予定です。

Cozyモデル駆動開発/ユースケース・モデルをCMLで記述

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法について考えています。

前回はユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行いました。

今回はCML(Cozy Modeling Language)での記述方法について考えます。

ユースケース基本情報

前回定義したユースケースの基本情報の構造です。

name	type	mult	description
id	identifier	1	ユースケースID
name	name	1	ユースケース名
title	i18ntitle	?	タイトル
goal	i18ntext	1	プライマリ・アクターの目的
summary	i18ntext	?
primary actor	name	1	プライマリ・アクター
trigger	text	?	トリガー

このユースケース基本情報をCMLで記述したものを以下に示します。

ユースケース
==========
# UseCase
## 顧客の商品の予約を申請する
| Name          | 顧客の商品の予約を申請する |
| Id            | UC0056                |
| Primary Actor | 販売担当者              |
| Goal          |                       |
| Triger        | 顧客の予約依頼           |
| Summary       |                       |

タイトル

タイトルの「ユースケース」はモデル的には特別な意味はありません。必要に応じて管理上適切なタイトルをつけることができます。

UseCase

セクション「UseCase」はユースケースの集まりを定義するセクションであることを示しています。

セクション内の各サブセクションは、それぞれユースケースの定義となっています。

上記の場合はサブセクション「顧客の商品の予約を申請する」がユースケース名となり、サブセクション内でユースケース「顧客の商品の予約を申請する」の定義を行います。

ユースケース情報

ユースケース基本情報を表で記述しました。

ユースケース基本情報は単純なプロパティの集まりなので、表形式で記述することが可能です。

プロパティをセクションで記述

CMLのメタ文法では、表の代わりにセクションの階層構造を使ってプロパティを記述することができます。

セクションを使ってプロパティを記述した場合の例を以下に示します。

ユースケース
==========
# UseCase
## 顧客の商品の予約を申請する
### Name
顧客の商品の予約を申請する
### Id
UC0056
### Primary Actor
販売担当者
### Goal
### Triger
対面販売
### Summary

サブサブセクションの名前の「Name」や「Id」がプロパティ名を示し、そのコンテンツがプロパティに対する値を記述します。

前述の表形式と記述する内容そのものは等価であることが確認できます。

ただ、表のフィールドで記述しきれない複雑な情報でもセクション形式では記述することができるので、そのような場合はセクション形式を選択するとよいでしょう。

表形式とセクション形式は混在することができるので、単純な値のプロパティを表形式で、複雑な構造を持つプロパティをセクション形式で記述することも可能です。

まとめ

今回はユースケース記述の基本情報をCMLで記述する方式について考えてみました。

次回から順次、拡張情報、シナリオ記述、ユースケース間の関係などについてCMLでの定義について考えていく予定です。

Cozyモデル駆動開発/ユースケース・モデル

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法について考えています。

前回は要求項目のモデルを考えました。

今回からユースケース・モデルについて考えていきます。

ユースケース・モデル

ユースケースは、システムの利用者が目的を達成するために体験する物語を記述したモデルです。

Cozyモデル駆動開発(CMDD)ではユースケース・モデルを要求モデルの中核モデルとしています。

ユースケース・モデルの記述にはUMLのユースケース図も使用しますが、モデルの本体は自然言語で書かれたユースケース記述です。ユースケース記述の集まりによって記述されるユースケース・モデルの概要を図示したものがユースケース図です。

このためCMDDではCozy Modeling Language(CML)によって記述したユースケース記述の集まりから必要に応じてユースケース図をCozyで生成するアプローチを取ります。

ユースケース記述

ユースケース記述の内容を基本情報と拡張情報に分けて考えます。

基本情報

ユースケース記述の基本情報は以下の項目で構成されます。

name	type	mult	description
id	identifier	1	ユースケースID
name	name	1	ユースケース名
title	i18ntitle	?	タイトル
goal	i18ntext	1	プライマリ・アクターの目的
summary	i18ntext	?
primary actor	name	1	プライマリ・アクター
trigger	text	?	トリガー

id

ユースケースを一意に識別するためのIDです。

name

ユースケースの論理名です。利用者の目的をベースにソフトウェアで識別しやすい名前をつけます。

title

ユースケースを人間向けに説明するラベルです。画面や文書上に表示されます。利用者の目的をベースにしたタイトルをつけます。多国語で定義することができます。

goal

このユースケースが達成すべき、プライマリ・アクターの目的です。多国語で定義することができます。

summary

このユースケース全体の簡潔な説明です。システムやアクターの主要な振る舞いを要約します。多国語で定義することができます。

primary actor

このユースケースを開始し、利益を得る主なアクターです。

trigger

このユースケースを開始する外的な出来事や操作です。

拡張情報

ユースケースの拡張情報はユースケースを高度に使用したい場合に用いる情報です。

name	type	mult	description
secondary actor	name	?	セカンダリ・アクター
supporting actor	name	*	スポーティング・アクター
precondition	text	*	事前条件
postcondition	text	*	事後条件
priority	token	?	優先度
status	token	?	状態

secondary actor

セカンダリ・アクターはこのユースケースに関与しますが、主要な操作主体ではないアクターです。

supporting actor

サポーティング・アクターはユースケースにおいて支援的な役割を果たすシステムやアクターです。

precondition

ユースケースが正しく開始されるために、事前に満たされているべき条件です。

postcondition

ユースケースが成功裡に完了した後に成立すべきシステムやアクターの状態です。

priority

このユースケースの重要度や実装上の優先順位です。

status

ユースケース記述の完成度やレビュー状況などのステータスです。

まとめ

今回はユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行いました。

次回はCML(Cozy Modeling Language)での記述方法について考えます。

Cozyモデル駆動開発/要求項目モデル

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法について考えています。

前回はコンテキスト・モデルを作成しました。

今回から要求モデルの作成を開始します。

要求項目モデル

Cozyモデルはユースケース駆動が軸となるので、ユースケース・モデルが重要なモデルとなりますが、ユースケース・モデル以外のモデルも目的毎に併用する形になります。

要求仕様をまとめるにあたって、ユースケースのような詳細なモデルに入る前の準備モデルといった位置付けのモデルが必要になります。

この目的で用意しているのが要求項目モデルです。

要求項目は以下の属性を持つシステムで実現したい要求で、この要求項目の集まりが要求項目モデルとなります。

• 管理番号 (No)
• 名前 (Name)
• 内容 (Content)
• 優先度 (Priority)
• 作成日時 (CreatedAt)
• 更新日時 (UpdatedAt)

属性は日本語と対応する英語を定義していますが、モデル記述時にはどちらを使ってもかまいません。

優先度

要求項目の優先度は以下のMoSCoW基準で記述します。

優先度	展開形	意味	備考
M	Must have	必須	要求
S	Should have	重要	要求
C	Could have	可能であれば実現	要件
W	Want to have	将来検討	要望

フォーマット

モデル記述のフォーマットは以下のものになります。

# 要求項目
## 商品の販売
| Item       |          値 |
|------------+------------|
| No         |        001 |
| Priority   |          M |
| CreateDate | 2025-06-30 |
| UpdateDate | 2025-06-30 |
### 内容
Web画面経由で商品の販売を行う。
## 商品の発送
| Item       |          値 |
|------------+------------|
| No         |        002 |
| Priority   |          S |
| CreateDate | 2025-06-30 |
| UpdateDate | 2025-06-30 |
### 内容
販売した商品の発送を発送システムに依頼する。

要求項目

以下のように要求項目セクションを宣言するとその内容が要求項目モデルになります。

# 要求項目

要求項目の名前

以下のようにサブセクションのタイトルが要求項目の名前になり、サブセクション内の情報が要求項目のモデルとなります。

## 商品の販売

プロパティ

各種属性は以下のようなプロパティの表で一括して記述することができます。

| Item       |          値 |
|------------+------------|
| No         |        001 |
| Priority   |          M |
| CreateDate | 2025-06-30 |
| UpdateDate | 2025-06-30 |

内容サブサブセクション

タイトルが「内容」または「Content」のサブサブセクションにはモデルの内容を記述します。

### 内容
Web画面経由で商品の販売を行う。

管理方法

Cozyモデルの記述方法として上記のテキスト・フォーマットを定めています。このテキストをCozyが読み取って処理します。

また、同等の情報があれば要求管理システム、バグ管理システムやExcelなどの表計算ソフトのフォーマットでの管理も可能です。この場合、Cozyで処理をするためには連携アダプタが必要になります。

まとめ

今回は要求項目モデルを定義しました。

次回も引き続き要求分析を進めます。