Software Requirements

正文

Types of Requirements

Requirements can be categorised in many ways, but at a high level a useful way to split them is into business requirements, user requirements, and solution requirements.

需求层次可以表示为：

$\text{业务需求} \rightarrow \text{用户需求} \rightarrow \text{解决方案需求}$

Business Requirements

业务需求站在组织、公司或研究机构的角度，描述项目希望实现的战略目标，例如：

• 提高利润率
• 扩大市场份额
• 开拓新的研究方向
• 建立新的合作关系

它回答的是：

这个项目为什么值得做？它要为组织带来什么价值？

如何判断是不是业务需求

一个合格的业务需求通常满足三个特点：

1. 站在组织视角，而不是单个用户视角。
2. 描述目标或价值，而不是具体功能。
3. 与项目战略相关，能够解释项目存在的理由。

例如：

• “降低临床报告的审计风险”是业务需求。
• “报告中增加标准差”不是业务需求，而是功能或解决方案需求。
• “报告必须在 30 秒内生成”通常属于用户需求或非功能需求。 examples
• BR1: improving the statistical quality of clinical trial reporting to meet the needs of external audits
• BR2: increasing the throughput of trial analyses to meet higher demand during peak periods

User (or Stakeholder) Requirements

用户需求描述特定利益相关者希望系统具备什么能力，是业务目标与具体软件实现之间的桥梁。

如何判断是不是用户需求

一个用户需求通常具备以下特点：

• 明确对应某类利益相关者；
• 描述用户期望获得的能力或结果；
• 能追溯到某个业务需求；
• 不深入指定技术实现。 examples
• UR1.1 (from BR1): add support for statistical measures in generated trial reports as required by revised auditing standards (standard deviation, …)
• UR1.2 (from BR1): add support for producing textual representations of statistics in trial reports as required by revised auditing standards
• UR2.1 (from BR2): ability to have an individual trial report processed and generated in under 30 seconds (if we assume it usually takes longer than that)

Solution Requirements

它回答的是：

为了满足用户需求，软件具体必须具备什么能力和约束？

examples

• Functional requirements focus on functions and features of a solution. For our software, building on our user requirements, e.g.:
  • SR1.1.1 (from UR1.1): add standard deviation to data model and include a graph visualisation view
  • SR1.2.1 (from UR1.2): add a new view to generate a textual representation of statistics, which is invoked by an optional command line argument
• Non-functional requirements focus on how the behaviour of a solution is expressed or constrained, e.g. performance, security, usability, or portability. These are also known as quality of service requirements. For our project, e.g.:
  • SR2.1.1 (from UR2.1): generate graphical statistics report on clinical workstation configuration in under 30 seconds