requirements

确定需求是软工设计中最重要的部分。

• feature to satisfy customer.

• indicates what should this sys do.

• 可能是高层抽象的需求 high-level abstract 或者底层具体的 low-level specific.

Stakeholder 利益相关者：受系统影响的组织或个人（当然有的软件可能是针对市场需求开发，而不存在具体的用户）。这些人站在不同角度上有不同见解。

客户不一定清晰描述其需求，也不一定清楚产品特性和功能，且其需求可能不断变化。

在确定需求环节投入的额外时间长远角度来看会节省更多的时间和金钱。

需求分为：functional 和 non functional.

functional requirements

定义系统的需求，要干什么。比如教务系统对于老师和学生端提供的不同的服务。

这一部分要完整 completeness 清晰一致 consistency 的描述大需求，避免不必要的误解。

non-functional requirements

这一部分比功能性更重要，相当于不满足这一部分系统错误，不满足功能需求系统有一些小bug。

Define system properties and constraints，比如时空复杂度，设备 capability。

Process requirements：比如质量标准，编程语言等。

Organisational requirements: 如系统要符合IT政策规定。

external requirements: 比如“用户密码不能泄露”。

非功能性需求需要定量描述指标。不然比如“希望程序跑的快一点”这就很模糊。要有measure的方法区测量quantitative定量指标。

Requirement conflicts

要trade-off权衡需求，让所有人都同意一个最优需求。

Requirement document

Software Requirements Specification (SRS) 软件需求规范，确认测试的参考规范，指明了应该实现的需求，但是不指明如何实现。

Requirements Capture

Background Reading

Interviewing

Observation（观察用户使用系统的情况）

Document or Record Sampling（专业的observation）

Questionnaires

敏捷开发中的需求

usr stories

用户需求被称作用户故事，一两句话写在卡片上。

customer 给他们排序需求，development team分解实现任务。

As a user, I want to backup my entire hard drive so that I won’t lose any work.

写在 stories cards 上，按顺序贴在墙上大家讨论，注意重点不是记录而是大家的讨论。

Project glossary

一些项目相关的专业术语，建议总结出来方便大家理解讨论。

Epics

大的 usr story。通常开始讨论前被拆分为小的块。

Acceptance Criteria

验收标准，通常写在故事卡背面，有助于理解需求和 invite negotiation with the team about the business value that we are trying to create.

Non-functional Requirements as User Stories

比如用户表示：我希望电脑打cf fps高于100.

usr stories注意事项

1. 谁都能写，最好让更多的成员写。
2. 整个 agile development 过程中都可以写。一开始开故事讨论会确定基本，后续随时可以添加。

Product backlog

需求按优先级排列的需求表。综合考虑多方因素。

MoSCoW：一种 dsdm 动态系统开发方法。

• must have：最重要的。
• should have：如果时间资源超限可以被取代。
• could have：用户期望的需求，完成后用户满意度会高。但是不必要。
• want to have: 当前阶段不重要的。

Estimating

估计项目用时。

story point：故事点，用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。

当采用故事点估算时，我们为每个待办项分配一个点数。待办项估算结果的原生数据并不重要，我们只关注最后得到的相对估算结果。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。而它也应该是另一个估算值为3的用户故事的三分之二。

团队不要采用100、200、300，或者1百万、2百万、3百万，而要使用1、2、3。估算结果是比值，而不是绝对值。

敏捷开发中到底什么是故事点（Story Point）？ - 知乎 (zhihu.com)

评判 good usr story

INVEST原则。

– Independent – Negotiable – Valuable – Estimatable – Small – Testable

Prototyping

physical：比如画gui。

logical：元素，元素之间的关联……

Low-fidelity 低保真：最简单，比如手绘图，纸板做的，快速验证产品概念的可行性。

Medium-fidelity 中保真：数字模型。

high-fidelity：如3d打印，最接近产品但是制作麻烦。