《软件需求十步走》读书笔记三
近期读了《软件需求十步走》最后的部分，分别是管理篇、组织篇。
管理篇
1.需求管理的思路 ：需求工程的需求业务活动由需求规划中的6个业务活动和需求开发的4个业务活动共计10项业务活动组成，构成了需求工程的业务主线。需求工程的需求管理活动的目标就是确保需求业务活动能够按进度要求、质量要求、成本要求生产出高质量的软件需求。
2.需求版本控制 ：软件需求基线是由各阶段需求业务活动的工作成果文档和文档内各部分内容的版本号的集成。软件需求基线工作的落实借助这些工作成果文档和文档内部分内容版本号来实现的。
3.管理变更请求 ：对于软件开发工作来说每一次需求变更不是在做加法，而是在做乘法，虽然乘数是1，但被乘数会因为需求变更的层次高低而放大。所以需求变更是一个非常严肃的工作。
4.需求跟踪能力 ：建立需求能力矩阵对于实际发生需求变更时可以通过该矩阵遍历出与变更需求相关的各个工作元素，而不至于陷入需求变更的困局中。需求能力矩阵除了可以轻松应对需求变更，而且还可以基于它建立一个需求工程全局管理视图。
组织篇
1.呼吁建立需求分析体系 “千夫所指人人相轻”这种不重视软件需求的观念体现在一个个软件项目只是表象，其症结在于长期以来“轻业务、重技术”的理念已根深蒂固。
2.需求分析部门的组织结构 “什么样的工作职能，将决定建立什么样的组织结构”。
3.需求分析部门的管理工作 需求分析部门的管理思路是“抓两端、促中间、一条业务线、专业化分工”。
4.需求分析部门的业务工作 需求分析部门的业务工作主要由需求业务和需求开发业务两部分组成。
开发因需求而来，需求开发以需求规划的成果为主要依据。软件需求开发首先要做的是获取需求，得到目标、系统关联情况以及用例的分析；其次是需求分析，软件系统的可行性、用户接口、系统功能、数据、优先级等这些都在需求分析之列；然后汇总成需求分析规格说明书；最后在进行需求测评，制定具体的开发方案。
需求获取是确定和理解不同用户类的需求和约束的工作活动，是需求开发工作中最困难、最关键、最容易出错的地方，只有需求架构师和开发人员的紧密结合才能保证工作高质量地完成。需求架构师收集了客户的法律法规、工作总结、业务规划和信息化建设指导等文件，在梳理的基础上对这些材料进行全面细致的分析，通过向客户高层和各级职能部门人员讲述其业务并听取他们的反馈意见，在对梳理结果进行修正。
编辑项目视图和范围的文档应站在技术的角度，需求规划中的问题和目标的描述应站在业务角度。编制项目视图和范围的文档一定要将需求规划的成果作为参照物。项目视图和范围的描述为待开发的系统的范围作了一个界定。
用例分析是基于需求规划的部分成果和系统关联关系分析整理出系统使用主体、用例条目，在采用用例图或用例规约对用例进行描述。用力分析和描述分为三步：整理系统使用者、对系统使用主体期望的用例条目进行提炼、通过用例图和用例描述进行规范化的描述。写实法和演绎法是用例条目提炼是综合运用的手段。
需求获取是对业务事项的综合分析，而需求分析的一个主要工作是对软件系统做归类分析。需求分析是在需求规划、需求获取的基础上展开的。功能需求分析是需求分析的核心工作面向对像的功能需要求分析是一种功能的概念设计和初步的逻辑设计，概念设计得出这个系统的组成部分的名称及作用，逻辑初设是将系统器件看成一个灰盒，能看清内部元件构成，只是不知道元件材质是什么。在这里作者多次提到了白盒和黑盒，不同的阶段将系统比作不同的盒子，很形象的表现出了在不同阶段我们能看到的系统的程度。