《软件需求十步走》阅读笔记二

      做任何事情都讲求方法，方法是人类智慧的体现、知识的运用。方法是人们解决问题的手段。人们在寻找解决问题的方法时总是趋向于简单实用、易于掌握。

      面对着空的肥皂盒子，有人花了几十万解决了这个问题，有人只花了90块钱就解决了这个问题。一个是博士，一个是小工。方法之美就在于简单。

      TPC基准测试体系、SPECweb２００５基准测试体系、SPECjAppSeｒｖｅｒ２００４基准体系测试三种基准测试在使用时都要对具体情况进行分析，选择最佳的基准测试。统一建模、人机交互、设计模式等课程都在学习用例图、类图、状态图、活动图、序列图、协作图、组件图等等，面向对象分析中的几个图示方法将作为功能需求分析和用户需求分析建模的方法。用例图以新的图形符号来重构需求规划分析的业务事项，为功能需求分析提供依据信息，类图对用例图信息要素进行归类后体现为类内部属性和类间关系，时序图以类作为要素对用例图进行重构，时序是刚性的，协作图是相对自由的。

      不仅有软件设计模式，也有需求统一模式。需求模式１０要素是：模式名称、基本细节、适用性、讨论、内容、模板、实例、额外需求、开发考虑、测试考虑。编写需求模式要考虑这个模式实例是否有价值，并且复制一个需求模式模板文档的内容，填写基本细节，描述模式是为了什么，构造所有能找到的实例列表，找到需求实力的共同之处以及区别，描述需求信息，编写需求模板，需求模板可以是多个，考虑需求应该关注什么、什么可以考虑什么可以忽视，编写额外需求实例，检查潜在的额外需求、把相似的需求放在一起，与资深开发人员讨论并记录下他们的意见，与测试人员讨论并记录下他们的意见，让分析师检查模式是否清晰和易用、让设计人员检查其实用性、请测试人员检查测试考虑部分的有效性。

      图形化的需求描述比较的直观和易理解，但是与形式化需求规格说明相比缺乏数学的严格性。形式化规格说明减少了规格说明完成后的错误，利用数学方法可以证明说明的正确性以及判断多个规格说明间的等价关系等等。

      需求规划工作是面向“全业务、全信息、全系统”，业务是事项，也是事项的实作行为，也是对所做事项的总称。业务的法理依据是业务研究中的关键，业务研究的目的是要认识业务的要素、结构、层次、规律、范围、目标，给应用建模提供依据，即为改造业务提供依据。业务研究从资料研究开始，资料研究从资料收集开始。业务组织的梳理对于找到系统关联性很有帮助，一个组织一定会有其上级、下级和横向协同的相关组织。找出主体和对象间物理、能量、信息的交互物与交互行为是业务梳理的关键。

      资料研究让我们从过去积累的大量纸质材料中认识了客户业务，利用逻辑方法梳理出了组织与对象在交互过程中的业务主线，围绕这条业务主线建立包含业务域、业务工程、业务活动、业务岗位、业务规则的业务知识体系。现场调查是去给客户展现他们的业务，而不是让客户告诉你业务。

      问题是理想与现实之间的差距，目标是理想和现实之间的一个路标，问题决定范围、目标决定深度。

      面向信息系统的某个类用户以及解决某某问题或某几个问题是应用的显著特征。由业务建模、系统建模和体系建模三个建模共同构成的应用建模，是从业务系统转向信息系统的中间过程，是业务系统和信息系统之间的桥梁，其基本方法是业务与系统的映射。业务是对业务系统的组成成分的一种整体性认识，系统功能是对信息系统组成成分的一种整体性的认识，他们之间一一对应但又不是简单的对应。业务域和子系统是一对一映射，业务事项与功能模块是一对一和多对一，业务事项和功能模块是一对一或多对一，业务视图和基本表是一对多等等。

     需求规划报告不仅是需求开放工作的基础，也是软件开发工作的指导性文件，还是下一次信息化建设的基础。