今天阅读了《构建之法》有关需求分析和典型用户及场景分析相关的章节，有很多思考。我们做软件，必须了解用户的需求。做需求分析得有步骤有条理的进行。
首先是引导需求。我们需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。很多时候用户并不知道自己确切的需求，或者不愿意表达完整的需求，软件团队需要设身处地，替用户着想，引导出需求。有些需求在实现之前，并没有用户明确表达具体的需求。我们还需要分析技术的发展趋势以及产业的变化、社会发展的大趋势，推测用户会产生哪些新的需求。需求还可以来自技术团队本身，团队在考虑软件的代码、架构、所依赖平台的长期演化的时候，会提出技术性的需求，包括代码的迁移、架构的演化、平台的变化，或者引入新的技术。有些需求的目的是要“更好地了解用户的行为和需求”。
其次是分析和定义需求。这是指对从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求量化（需求实现的最后期限，实现需求大致所需的时间和资源成本，各个不同需求的优先级，需求带来的收益，等等）。
接着是验证需求。软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。
最后需要我们在软件产品的生命周期中管理需求。在软件的生命周期中，需求在发生变化，技术在发展，团队成员的能力也在提高。原来认为重要的事情可能不再重要，有些功能原来技术上很难实现，现在出现了捷径，一些相关的法规会发生变化，外部的合作伙伴突然发生变化，这些都要求我们不断对需求进行重新审核并做出相应的调整。
关于需求的分类，有这样几种分类方法。首先是对产品功能性的需求：要求产品必须实现某些功能。其次是对产品开发过程的需求：要求软件的开发流程必须满足某些约束条件，然后是非功能性需求：这也叫“服务质量需求”。最后是综合需求，有些需求并不是单单一个软件模块就能满足，例如，“购物网站必须在24小时内把货物发送到用户手中”，这个需求牵涉到软件系统、货物派送系统、送货部门、监控系统等不同部门的功能和执行能力。
我的思考：我们说做需求分析的时间应该三倍于写代码的时间，可见需求分析是多么的重要。我们需要在需求阶段把很多问题定义清楚，不然写出了代码也是无效，做出的功能也是不尽人意的，从而违反了我们做软件的初衷。