SERU

在實際的應用過程中，由於結構化分析、面向對象分析方法都無法覆蓋需求工程的全部內容，因此還派生了業務工程、業務建模方法來補充。另外，由於實踐需求工程的人員大多是技術背景，因此經常仍然遵循UI驅動、資料庫驅動等技術驅動需求過程。

而用例、用戶故事等業務視角的需求分析方法應用誤區多，加之無法覆蓋所有的需求工作，因此許多需求人員仍然無法離開技術驅動的思想，形成了半業務、半技術的結果。

SERU需求方法體系正是針對這一問題，有效集成了各種有效需求實踐，為從業人員提供了完整、清晰的全面業務驅動需求方法體系。SERU完全覆蓋需求開發的全過程，打通了業務工程和需求工程之間的鴻溝，具有很好的可操作性。

1. 文檔概述

1.1 編寫的目的

1.2 背景

1.3 定義

1.4 參考資料

2. 任務概述

2.<1> 業務需求

2.<2> Stakeholder利益分析（略）

2.<3> 用戶特點分析

2.<4 >相關事實與假定

3. 需求概述

3.1 系統概述[主題域劃分，用構件圖表述]

3.2 主題域 1

3.2.1 概述[用上下文關係圖表示該主題域的範圍]

3.2.2 業務事件

3.2.2.1 業務事件1[包括流程分析、領域類分析、用例分析]

… …

3.2.2.n 業務事件n

3.2.3 報表

3.2.3.1 Report 1

[用領域類圖片段表示涉及數據，用用例標識具體的報表項]

… …

3.2.3.n Report n

3.3 主題域 n

4. 具體需求

4.1 主題域 1

4.1.1 用例模型

4.1.1.1 UC_B_xx（B類）

（1）概述[編號、名稱、概述、相關Stakeholder]

（2）事件流描述[前、後置條件，基本、擴展、子事件流]

（3）相關需求與功能點

（4）界面原型[交互過程與界面詳解]

（5）規約與約束

4.1.1.2 UC_R_xx（R類）

（1）概述[名稱、用戶部門與職位、業務意圖、相關場景]

（2）報表內容[領域類圖、數據項]

（3）輸入/輸出格式

（4）其他

4.1.1.3 UC_I_xx（I類）

（1）使用者[名稱、業務目的、時機、頻率]

（2）內容與格式[交互過程、數據包說明]

（3）設計與實現約束[諸如協議格式要求、性能要求等]

… …

4.1.2 領域模型

4.1.2.1 xx領域類

（1）概述[類名稱、別名]

（2）數據窗口分析[涉及主題域、業務事件，各域數據]

（3）數據組成與格式

（4）其他

… …

4.n 主題域 n

5. 補充規約

5.1 設計約束

5.1.1 技術選擇的限制條件

5.1.2 運行環境[建議用部署圖表示]

5.1.3 預期的使用環境

5.2 質量屬性[本部分建議直接分解成需要開發的技術功能點]

5.2.1 安全性要求

5.2.1.1 訪問安全性要求

5.2.1.2 數據安全性要求

5.2.1.3 通信安全性要求

5.2.1.4 其他安全性要求

5.2.2 可靠性要求

5.2.2.1 容錯性要求

5.2.2.2 可恢復性要求

5.2.2.3 其他可靠性要求

5.2.3 易用性要求

5.2.3.1 界面友好性要求

5.2.3.2 易操作性要求

5.2.3.3 其他易用性要求

5.2.4 性能要求

5.2.4.1 數據訪問性能要求

5.2.4.2 數據傳輸性能要求

5.2.4.3 其他性能要求

5.2.5 可維護性要求

5.2.5.1公共數據要求

5.2.5.2公共框架開發要求

5.2.5.3公共程序庫開發要求

5.2.5.4其他可維護性要求

5.2.6 可移植性要求

5.2.6.1適應性要求

5.2.6.1易安裝性要求

5.2.6.1其他可移植性要求

5.2.7 其他質量屬性要求

5.3 其他需求

5.3.1 培訓需求

5.3.2 後勤需求

5.3.3 包裝需求