在这个2015年的年末，终于读完了软件需求十步走这本书。通过读这本书我的收获很大。这三个月的读书，让我养成了良好的读书习惯。虽然有的时候感觉十分的烦躁，但是它给我带来了很大的进步。

在需求工程开发片中，需求开发的思路和过程 需求开发工作是“以技术为核心、以业务为辅助”作为指导思想，以要说清楚软件系统“做什么”的软件需求规格说明为目标。这里的需求获取和传统需求工程中需求获取最大的不同，一是无须与客户进行面对面的交流来获取需求，二是只需将需求规划的工作成果作为需求获取的第一来源。需求分析 需求分析工作分为分析和综合两部分工作。分析工作在于找出需求信息间内在的联系和可能的矛盾，而综合工作就是去掉这些矛盾来建立软件系统的功能、数据的逻辑模型。需求编写 软件需求的规划说明是由业务需求、用户需求和系统需求构成。而这些需求都在过程文档中，如果将这些文档看做一粒粒珍珠的话，那我们需要一根线将其穿成一个珍珠项链，穿起珍珠的这根线就是软件需求规格说明。需求验证 需求验证严格来说是检验软件需求规格说明，这是需求开发的最后一项活动，是对前期或阶段工作成果的一次完整的检查。

      需求管理的思路 ：需求工程的需求业务活动由需求规划中的6个业务活动和需求开发的4个业务活动共计10项业务活动组成，构成了需求工程的业务主线。需求工程的需求管理活动的目标就是确保需求业务活动能够按进度要求、质量要求、成本要求生产出高质量的软件需求。需求版本控制 软件需求基线是由各阶段需求业务活动的工作成果文档和文档内各部分内容的版本号的集成。软件需求基线工作的落实借助这些工作成果文档和文档内部分内容版本号来实现的

      管理变更请求 ：对于软件开发工作来说每一次需求变更不是在做加法，而是在做乘法，虽然乘数是1，但被乘数会因为需求变更的层次高低而放大。所以需求变更是一个非常严肃的工作。 建立需求能力矩阵对于实际发生需求变更时可以通过该矩阵遍历出与变更需求相关的各个工作元素，而不至于陷入需求变更的困局中。需求能力矩阵除了可以轻松应对需求变更，而且还可以基于它建立一个需求工程全局管理视图。同时我们要呼吁建立需求分析体系 “千夫所指人人相轻”这种不重视软件需求的观念体现在一个个软件项目只是表象，其症结在于长期以来“轻业务、重技术”的理念已根深蒂固

      需求分析部门的业务工作 需求分析部门的业务工作主要由需求业务和需求开发业务两部分组成。