标签：
这本书主要从软件需求实践中出现的主要问题和困难入手，指出了改造的主要方法，然后逐一说明了需求定义、需求捕获、需求分析与建模、编写规约、需求验证等需求开发活动的任务、要点和具体手段。还对包括需求基线、变更管理、需求跟踪在内的需求管理活动的操作要点进行了阐述。
软件项目实施过程中，会遇到很多的问题，有的甚至许多项目根本无法达到预期的目标，这些问题的根源就是软件需求实践。“在中国做软件太难了！客户连自己的需求都说不清楚！”，这种抱怨的话经常被做软件需求的人说到。需求失败也是因为不完整的需求、缺乏用户参与、不切实际的用户期望、需求变更频繁等原因。在很多软件项目中，用户总是不能有效的参与到项目中来，而主动参与意识与获得的利益是成正比的，为了让用户参与进来，要充分研究不同用户代表的关注点、利益点。对项目的沟通上一般会出现沟通失真的问题，解决这个问题的有效方法是及时复述。而往往客户的需求会被放大，这时候需求分析人员则有必要对需求进行有效的控制。需求的本质在于业务分析并不是技术分析，构造适当的业务场景也是需求所必须的。需求问题一直是一个很大的困扰，需要透过表象、分析本质、总结经验。
在信息系统、嵌入式系统、软件产品等不同角度都有着相应的需求工作，这些能够为需求分析师提供一个切实有效的视图。要更科学的对不同的软件需求进行分析，就需要根据不同的项目选择不同的线索。流程是联机事物处理系统需求视图的关键线索。在信息系统中，目前需求开发的思想提倡从用户的场景出发，从业务流程出发的横向视角。在嵌入式系统中，具体的使用场景是需求的主线索，对于面向用户的嵌入式系统，行为分析是要点；面向特定设备的嵌入式系统，外部接口和事件分析是要点；而软件产品分类则跟联机事务处理系统、管理信息系统等不同，与软件产品对应的是软件项目。
软件需求根据经验来讲可以定义为“业务知识+问题列表+其他因素”。需求的三个层次：业务需求、用户需求和软件需求。业务需求是反映企业/组织对软件系统的高层次目标要求，即软件系统的建设目标，体现在问题和机会两方面，是需求定义的产物；用户需求是指用户使用软件需要完成什么任务，怎么完成的需求，即用户需求是需求捕获的产物；软件需求又称系统需求，是需求分析与建模的产物。一个优秀的需求标准包括：完整性、不失真、有优先级、有技术早期介入等方面。需求工程包括需求开发和需求管理两大范畴，需求开发重点在于开发出高质量的需求规格说明，需求管理重点在于确保开发的软件满足需求。
需求定义就是要确定项目的宏观需求，即定义项目的业务需求，也就是明确的目标和范围。问题分析，就是理解真实世界中的问题和用户需求并提出满足这些多方面的解决方案的过程，要正确定义问题，然后寻找问题的解决方案，但是在确定某个解决方案时，一定要思考是否会引发新问题。在问题被定义之后，接下来就要分析问题背后的问题，也就是寻找问题的本源，然后就可以明确与项目相关的人。在需求定义这个阶段，对系统的范围进行界定十分重要，一般都使用上下文关系图来确定系统的范围，即数据流图中的顶层图，即将整个待开发系统理解成一个黑匣子，标识出外部的参与者和系统与其的交互关系。范围是涉及事、物，边界是人与系统的职责边界。之后可以通过业务事件列表和报表列表将主题域内容显示出来。业务事件分为外部事件（来自系统外部的事件，系统参与者发起）和内部事件（系统内部触发）。
目前看的这本书的这些内容有很多地方都涉及了老师上课讲的知识，更深层次的理解了那些课上比较重点的知识，通过一个个案例学会了思考问题的方式和解决问题的办法。软件需求过程很重要，关联着一个项目的成功与失败。要明确软件需求，尤其是业务需求、用户需求和系统需求，这一部分非常重要；同时明确好上下文图，确定系统的边界及每一个业务事件。
标签：
原文地址：http://www.cnblogs.com/mxj333/p/4945890.html
