本节书摘来自华章出版社《实践者的研究方法》一书中的第3章，第3.3节，作者罗杰 S. 普莱斯曼（Roger S. Pressman），更多章节内容可以访问云栖社区“华章计算机”公众号查看。
3.3 明确任务集
我们再来看图3-1，每一个软件工程动作（如需求获取以及与沟通活动相关的动作）都由若干个任务集（task set）构成，而每一个任务集都由软件工程工作任务、相关工作产品、质量保证点和项目里程碑组成。需要选择最能满足项目需要并适合开发团队特点的任务集。这就意味着软件工程动作可以根据软件项目的特定需要和项目团队的特点做适当的调整。
信息栏 任务集
任务集定义了为达到一个软件工程动作的目标所需要完成的工作。例如，需求获取（通常称为“需求收集”）就是发生在沟通活动中的一个重要的软件工程动作。需求获取的目的是理解利益相关者对将构建的软件的需求。
对于一个小型、相对简单的项目而言，需求获取的任务集可能包括：
1. 制定项目的利益相关者列表。
2. 邀请所有的利益相关者参加一个非正式会议。
3. 征询每个人对于软件特性和功能的需求。
4. 讨论需求，并确定最终的需求列表。
5. 划定需求优先级。
6. 标出不确定域。
对于大型、复杂的软件工程项目而言，可能需要如下不同的任务集：
1. 制定项目的利益相关者列表。
2. 和利益相关者的每个成员分别单独讨论，获取所有的要求。
3. 基于利益相关者的输入，建立初步的功能和特性列表。
4. 安排一系列促进需求获取的会议。
5. 组织会议。
6. 在每次会议上建立非正式的用户场景。
7. 根据利益相关者的反馈，进一步细化用户场景。
8. 建立一个修正的利益相关者需求列表。
9. 使用质量功能部署技术，划分需求优先级。
10. 将需求打包以便于软件可以实施增量交付。
11. 标注系统的约束和限制。
12. 讨论系统验证方法。
上面两种任务集都可以完成需求获取，但是无论从深度还是形式化的程度上来说，二者都有很大区别。软件团队采取适当的任务集以达到每个动作的目的，并且保持软件质量和开发的敏捷性。
