要做一个项目，就得明白给谁做做什么，也就是这个项目的需求。需求是不同类的用户所不同的，所以我们需要针对不同类的用户获取需求，这就需要不同类的用户参与。
获取问题，分析需求，编写规格说明书，验证。这个过程，需要用户类，评测人等风险承担者们的积极参与，只有当风险承担者和项目开发人员对需求达成统一时，才能更节省更有效的进行下一步开发。
当然在验证之后的开发过程中需求也不是一成不变不做更改的，每当出现需求变更，就要评估需求的优先级，对需求的可行性分析制定最终版，对更改的需求所影响的做改变和记录，最好对数据有所记录追踪。
习惯造就未来是深深存在脑海的一句话，对于用户需求的正确获取和验证，以及过程中的实现，如果我们养成了制定计划，周期性改进和评估，同时在需求实现过程中积累材料将为以后的工作省下不少事。习惯制定计划逐个突破，记录，验证，未雨绸缪，积累经验能在与当下的项目里更实际有效的实现，不至于雾水一头。
另外我认为，获取需求到实现需求到验证需求反复的过程中，我们程序员应该有一颗平淡的心，不要有过高的期待，因为需求变更是常有的，是多次反复连续的，要做好一定的心理基础，而且不仅是需求变更，在项目完成的过程中也会有别的风险出现，既然知道是个难题，我们就该有一种临危不乱未雨绸缪的心态去解决问题，一口吃成一个大胖子是不可能的事。
软件需求 获得分析确定 看起来几个字很简单，但是通过该阅读才知道实则是一个繁琐马拉松似的过程，不仅是需求的改变，文档的多次修改甚至重写，还有会以的召开，同时还得注意说话的方式和态度。在合作中更好的获取需求。
通过今天的阅读，我知道了项目视图和范围是描述项目的边界，应当有什么不应当有什么；项目视图是描述业务需求的，不仅是要有需求的宽度，还得有深度，也就是不仅是有什么需求还得对这个需求进行细节的描述。通过关联图，我们可以确定项目的问题域。
项目不仅是有商业需求的考虑还应当有用户使用者的考虑，不然会导致用户少的结果。所以针对不同的使用者，我们应当有不同的用户类别的用户代表，形成核心用户组。
在获取需求时，我们可以通过实例图来使得用户更好的理解，可以使用统一建模语言。当出现需求变更或补充的时候，应当对优先级可行性延迟还是放弃作出判断，对预算和进度等重新估计，并且对计划和文档重新整理，以适应变化。当需求出现冲突、意见不统一谁来做决策，就应当分析需求的比重哪个大，哪个重要，并且应该听谁的谁是最终决策者，代表应当时刻记住虽然产品代表者对软件和本行业的一定了解，但自己不是唯一的用户。
软件需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。
进行需求分析时，应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象，并尽量将分析进度提交给用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。
分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。
开发软件系统最为困难的部分就是要准确说明开发什么。最为困难的概念性工作便是要编写出详细的技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。如果做错，这将是会最终给系统带来极大损害的一部分，并且以后再对它进行修改也极为困难。目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间的接口是系统开发人员最头痛的问题。对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？
然而，即便并非出于商业目的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生。