requirements-engineering

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Requirements Engineering

需求工程

Structured approaches for capturing what to build before how to build it.

在确定如何构建之前，先通过结构化方法明确需要构建的内容。

Core Principle

核心原则

Specify WHAT, not HOW. Requirements describe outcomes and behaviors, not implementation details.

明确「要什么」，而非「怎么做」。 需求描述的是结果和行为，而非实现细节。

EARS Format

EARS格式

Easy Approach to Requirements Syntax - structured acceptance criteria.

Pattern	Template	Use Case
Event-driven	WHEN [event] THEN [system] SHALL [response]	User actions, triggers
Conditional	IF [condition] THEN [system] SHALL [response]	Business rules
State-driven	WHILE [state] [system] SHALL [response]	Ongoing behaviors
Ubiquitous	WHERE [feature] [system] SHALL [response]	Always-true rules
Unconditional	[system] SHALL [response]	Basic capabilities

Easy Approach to Requirements Syntax（需求语法简易方法） - 结构化的验收标准。

模式	模板	使用场景
事件驱动型	WHEN [事件] THEN [系统] SHALL [响应]	用户操作、触发条件
条件型	IF [条件] THEN [系统] SHALL [响应]	业务规则
状态驱动型	WHILE [状态] [系统] SHALL [响应]	持续行为
通用型	WHERE [功能] [系统] SHALL [响应]	始终生效的规则
无条件型	[系统] SHALL [响应]	基础功能

Examples

示例

Type	Example
Event	WHEN user clicks "Submit" THEN system SHALL validate all required fields
Conditional	IF user is not authenticated THEN system SHALL redirect to login
State	WHILE file is uploading system SHALL display progress indicator
Ubiquitous	WHERE data is displayed system SHALL use consistent date format

类型	示例
事件驱动	WHEN 用户点击“提交”按钮 THEN 系统 SHALL 验证所有必填字段
条件型	IF 用户未通过身份验证 THEN 系统 SHALL 重定向至登录页面
状态驱动	WHILE 文件正在上传系统 SHALL 显示进度指示器
通用型	WHERE 展示数据时系统 SHALL 使用统一的日期格式

User Story Format

用户故事格式

As a [role]
I want [capability]
So that [benefit]

As a [role]
I want [capability]
So that [benefit]

Good vs Bad

正面示例 vs 反面示例

Bad	Good
As a user I want to login	As a returning customer I want to login with my email so that I can access my order history
As a user I want a button	As a content creator I want a publish button so that I can share my work publicly

Key concept: The "so that" clause reveals the actual need - often the stated "want" isn't what's really needed.

反面示例	正面示例
作为用户，我想要登录	作为回头客，我希望通过邮箱登录，以便查看我的订单历史
作为用户，我想要一个按钮	作为内容创作者，我希望有一个发布按钮，以便公开分享我的作品

核心概念：“So that”部分揭示了真实需求——通常用户表述的“想要”并非真正的需求。

Requirements Document Structure

需求文档结构

Section	Content
Problem Statement	What problem are we solving?
User Stories	Who wants what and why?
Acceptance Criteria	How do we know it's done? (EARS)
Non-Functional	Performance, security, accessibility
Out of Scope	What we're NOT building
Success Metrics	How do we measure success?

章节	内容
问题陈述	我们要解决什么问题？
用户故事	谁想要什么，以及为什么？
验收标准	我们如何判断功能已完成？（采用EARS格式）
非功能性需求	性能、安全性、可访问性
范围外内容	我们不会构建的内容
成功指标	我们如何衡量成功？

Constitution (Governing Principles)

指导准则（管理原则）

For complex projects, establish guiding principles before features:

Element	Purpose
Core Values	What matters most (simplicity > cleverness)
Technical Principles	Architecture standards
Decision Framework	How to make trade-offs
Quality Standards	Testing, review requirements

Key concept: Constitution prevents scope creep and ensures consistency across features.

对于复杂项目，在确定功能之前先建立指导原则：

要素	目的
核心价值观	最优先的事项（例如：简洁 > 精巧）
技术原则	架构标准
决策框架	如何进行权衡取舍
质量标准	测试、评审要求

核心概念：指导准则可防止范围蔓延，并确保各功能之间的一致性。

Clarification Techniques

澄清技巧

Before implementation, resolve ambiguities:

Technique	When to Use
Ask "what if"	Edge cases, error scenarios
Present options	Multiple valid approaches
Challenge assumptions	"Is this actually required?"
Define boundaries	What's in/out of scope

在实现之前，解决模糊点：

技巧	使用场景
提出「如果…会怎样」的问题	边缘情况、错误场景
提供备选方案	存在多种有效实现方式时
挑战假设	质疑“这真的是必需的吗？”
定义边界	明确哪些内容在/不在范围内

Questions to Ask

可提出的问题

What happens when [edge case]?
What does success look like?
What's the minimum viable version?
What can we defer to later?

当出现[边缘情况]时，会发生什么？
成功的标准是什么？
最小可行版本包含哪些内容？
哪些内容可以延后实现？

Non-Functional Requirements

非功能性需求

Category	Questions to Answer
Performance	Response time? Throughput? Concurrent users?
Security	Authentication? Authorization? Data protection?
Accessibility	WCAG level? Screen reader support?
Scalability	Expected growth? Peak load?
Reliability	Uptime requirements? Recovery time?

类别	需要回答的问题
性能	响应时间？吞吐量？并发用户数？
安全性	身份验证？授权？数据保护？
可访问性	WCAG级别？屏幕阅读器支持？
可扩展性	预期增长？峰值负载？
可靠性	可用时间要求？恢复时间？

Anti-Patterns

反模式

Don't	Why
Specify implementation	"Use React" locks in decisions
Assume requirements	Validate with stakeholders
Skip edge cases	They become bugs later
Mix requirements with design	Conflates what with how
Write vague criteria	"System should be fast" is untestable

不要做什么	原因
指定实现细节	例如“使用React”会锁定决策
假设需求的合理性	需与相关方验证
忽略边缘情况	后续会演变为bug
混淆需求与设计	将「要什么」和「怎么做」混为一谈
编写模糊的标准	例如“系统应快速”无法测试

Testable vs Untestable

可测试 vs 不可测试

Untestable	Testable
"Fast response"	"Response under 200ms"
"User-friendly"	"Task completable in <3 clicks"
"Secure"	"Passwords hashed with bcrypt"
"Scalable"	"Handles 10K concurrent users"

Key concept: If you can't write a test for it, it's not a requirement - it's a wish.

不可测试	可测试
“响应快速”	“响应时间低于200毫秒”
“用户友好”	“任务可在3次点击内完成”
“安全”	“密码使用bcrypt加密”
“可扩展”	“可支持10000并发用户”

核心概念：如果无法为某项要求编写测试用例，那它就不是需求——只是一个愿望。