需求工程

设计和开发一个计算机软件时，如果软件解决的问题不对，那么再精巧的软件也满足不了任何人的要求。
理解问题的需求是软件工程师所面对的最困难的任务之一。
困难的原因有二：客户不知道或无法全面的阐述需求；客户需求可能在项目实施过程中改变；
因此，在软件工程过程模型中，需求的获取与分析是最为重要的一环。

软件需求(Software Requirements) ——IEEE, 1997定义：

• 主观需求：用户解决一个问题或达到一个目标所需要的一种状况或能力
• 客观需求：系统或系统构件要满足的合同、标准、规范或其他正式文档所需具备的能力；
• 需求文档：上述需求的文档化表示。

IEEE公布的需求定义分别从用户和软件工程师的角度阐述了什么是需求，需求一方面反映了系统的外部行为，另一方面反映了系统的内部特性，反映的方式是需求文档。
软件需求以一种清晰、简洁、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对系统的约束。
需求通常用于表达“做什么”，而不描述“如何做”。

我们可以将需求分为：

1. 用户需求(User Requirements)：从用户角度描述的系统功能需求与非功能需求，通常只涉及系统的外部行为而不涉及内部特性。
2. 系统需求(System Requirements, SR)：系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，不考虑系统内部的实现细节。
3. 功能需求：指具体需要提供的功能和内容，比如用户登陆功能、收发邮件功能和论坛功能等。描述了系统与其独立于系统实现环境之间的交互。环境包括用户和任何其他与该系统进行交互的外部系统。还包含了数据需求。
4. 领域需求：是由软件系统的应用领域所决定的特有的功能需求，或是对功能的约束。
5. 非功能性需求(Non-Functional Requirements, NFR)：指为满足客户业务需要必须达到初功能性需求之外的一些约束和限制。如：可用性(Usability)、可靠性(Reliability)、性能(Performance)、可支持性等。

好的需求应具备的特征：

• 完整性：每一项需求都必须将所要实现的功能描述清楚；
• 正确性：每一项需求都必须准确地陈述其要开发的功能；
• 可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的；
• 必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来；
• 划分优先级：给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量；
• 无二义性：对所有需求说明的读者都只能有一个明确统一的解释；
• 可验证性：检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现。

由于用户、视角不同，需求也必然不同。并且，由于以下因素的存在提高了需求的获取的复杂性和困难性。

• 问题的复杂性：比如专业领域；
• 理解的不完备性与不一致性；
• 交流障碍；
• 需求易变性。
  并且，在需求获取的过程中通常会存在一些问题，这些问题会导致得到错误的需求。
• 无足够用户参与，拒绝思想“我不明白为什么要花那么多功夫收集需求”、“与其与用户讨论浪费时间，不如写代码有意思”、“我已经明白用户需求了”。
• 用户需求的不断增加：若不断增加新需求，项目就越来越庞大以致超过其计划及预算范围。开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护。
• 模棱两可的需求：诸多读者对需求说明产生了不同的理解，单个读者能用不止一个方式来解释某个需求说明。其后果通常是返工，重做一些你认为已做好的事情。
• 不必要的特性