才能够体会到如何才能够把系统做好，如何更好的把软件需求和后续实现更好的衔接起来。有一本《软件需求》的书讲的很系统，从事需求工作的都值得仔细阅读。对于采用面向对象的需求开发和分析方法的，一定要熟悉RUP统一过程和用例分析和建模。
对于管理软件都离不开其涉及到的业务领域，因此要做好需求分析工作必须要熟悉管理软件所涉及到的业务领域，对业务领域相关的标准模型进行分析和研究，对业界的一些标准和最佳实践进行熟悉。比如做供应链管理系统和软件应该熟悉业界标准的SCOR模型，做ERP的应该结合现在的业界比较大的厂商的ERP产品进行学习，对于研发管理系统可以结合PACE和IPD等等。只有熟悉了业务领域才可能在需求调研和分析的时候提供很多有建设性的意见，或者说需求分析人员不是被用户牵着走，而是真正的可以引导用户。
4.需求分析的步骤和输出有哪些？
开始首先是需求的收集，需求收集可以通过调查表，访谈，业界标准，会议讨论沟通等多种方式进行。需求收集第一是要能够很好的描述现状，第二是要搞清楚用户的期望。同时一定要弱化用户期望系统怎么做，因为用户并不熟悉系统实现和内部原理，我们的软件需求不仅仅考虑的是功能的实现，还需要考虑需求复用，业务抽象，可扩展和配置等多方面的问题。
收集回来的需求就需要开始进行分析工作，分析包括了动态行为分析和静态数据分析。动态行为分析涉及到用例分析，业务流程和活动输入输出的分析，数据流分析，业务操作规则分析。静态数据分析设计到业务对象建模，数据字典，组织结构，权限等分析。在这一个阶段的重点就是需求的系统化和结构化，最好要体现到规范的文档中。在软件开发过程中我们最强调的需要文档化的输出就是需求文档和总体设计方案文档。
需求分析阶段还有一个重点的产出就是原型和DEMO，为了更好的和用户沟通并挖掘需求，我们需要将我们理解后的想法更加形象的讲述给用户，所以原型就显得额外重要。不管是否是抛弃的原型，都需要客户看到的原型和最终实现的系统基本一致，因此原型开发需要投入一定的时间，并根据客户反馈的信息不断修正。在原型中多投入些时间，就会多减少一份后期需求变更引起的返工时间。软件原型是降低需求变更风险的有效方法。
5.需求的验证和确认包括哪些事情？
我们可以再简单理解下验证和确认的区别，对于判断最终开发出来的系统是否和用户想要的东西是一致的过程叫确认，对于你理解和描述的需求和我当初的想法是否是一致的过程叫验证。需求的验证包括了很多的内容，涉及到软件开发中上下游相关人员的参与。首先你结构和文档化后的需求需要用户来验证是否和他们的想法是一致的，是否把用户的真实意图描述清楚了，以保证需求本身的正确性。对于后续设计开发阶段的人员也需要对需求进行评审以保证需求的可实现性，确认需求描述是否清楚，是否是可以实现的，对于业务对象，流程和规则是否存在不可实现的模糊描述词语。对于测试人员，则主要是确认需求是否是可测试的，是否在需求描述中引入了较多的易用，较好，应该等不确定和不可测试的词语。对于大型的软件项目，如果有专门的产品化标准和UI组的话，还需要对需求的易用性和产品交互等方面进行评估，以评价整个软件系统的产品化。
确认主要是软件系统已经开发完成后交付给用户后验收的时候，用户确认系统是否实现了当初的需求。为了保证确认过程的顺利，就必须重视需求验证的过程，需求验证不仅仅是需求阶段对需求文档的评审，还需要关注设计，开发等各阶段对需求的实现情况的验证。