软件需求最佳实践
需求实践所面临的问题
- 需求完整性需要诸多用户的参与和确认，而且用户间需求本身也存在冲突的可能，因此需求更加强调角色和场景和划分，一个所有用户需要都能够满足的需求往往不是一个好需求。
- 需求过程缺乏用户的参与，我们往往是技术驱动，习惯性的跳到模块的划分导致需求本身验证困难，也导致了需求间耦合很紧，很难在后期组织有效的迭代开发。因此要考虑按流程和业务梳理需求。
- 需求无法实现也可能不是架构问题，而是需求本身不切实际。
- 用户想要和真正需要是有区别的，没有真正的识别需求优先级可能导致需求过量开发和需求镀金。
- 需求优先级识别往往并不能完全依靠用户，用户往往只会把自己关注功能讲优先级识别的很高，因此需求优先级识别应该是通过业务规则，流程和模式来确定。优先级识别方法(离主营业务的远近，发生的频率两个方面来度量)
- 沟通失真，要认识到文档仅仅是中介而不是全部，要通过即时的验证来减少沟通失真。
- 需求捕获和调研常见问题-用户告诉你的是他转化后的解决方案，而不是最原始的需求。
- 变更频繁，但是要响应变化，比如通过对变更分类来识别哪些变更是可以通过复用和可配置解决的。
- 非功能性需求为有效的识别，仅仅是定性，而没有通过定性->场景->定量的路线。
需求分析的核心线索
在原有的需求分析方法中，我们往往过多的关注How，而没有关注What，或者关注了What而没有关注What背后的需求场景和背后的问题Why。这都导致我们没有进行很好的需求挖掘。需求分为业务需求，用户需求和软件需求三个层面。而我们在平时的需求分析中往往很容易直接跳到了软件需求阶段，而忽视了业务需求和业务建模。
- 业务需求 = 目标 + 范围
- 目标的表达必须包括目标+优势+度量+合理+可行，或者说SMART原则。同时在目标表达上可以考虑场景法，即问题是什么-》影响谁-》后果是什么-》解决方案优点是什么？
- 范围表达的两个重要方面是人和物，人包括干系人和最终用户；物包括业务事件和管理控制点。
需求定义输出业务需求；需求捕获输出用户需求；需求分析输出软件需求。需求分析的本质动作就是分解，抽象和消除歧义。而对于需求分析的本质线索则是人，事(流程)，物(数据)和接口。因此需求分析不能完全等同于建模型。分析是本质，建模仅仅是手段。
需求捕获
需求捕获是一个不断的探索过程。在需求捕获中，沟通占40%，业务占30%，技术占30%。而对于沟通往往讲究的并不是单纯的技巧，而更多的是一种思维模式和顺序的问题。在这里老师引入了思维模式的话题，也通过一个案例讲解了沟通中顺序的重要性，如先将解决方案再讲具体场景和问题(类似于我上个ppt里面强调的结构化思维的一个重要原则即开门见山的逐层展开)。在沟通中讲了三个可以借鉴的方法。
- 未知问题->已知问题
- 相对重要->相当次要(创造一种比较的环境给用户)
- 关注点的转换->(沟通也要洞察心理学)
- 隐喻(将了一个用汉字的赢字来表达项目管理核心)
探求本源(问题背后的问题，引入了《你的灯亮着吗》，讲到了没有荒唐需求，只有荒唐的解决方案)
需求访谈是捕获中的一个重要内容，这里做一个概括总结：
- 首先要搞清楚你访问的用户本身的角色和特点，前期要收集足够的资料，然后制定针对性问题。
- 应该是先访谈有了初步的聚焦后，再进行调查。
- 访谈的用户分类包括(用户特点，功能/流程，数据，非功能性和接口)
- 调查问卷设计诸多讲究，如避免简单的排序题，调查问卷中的C现象和D现象等，不展开。
需求规格说明书
业界关注需求有很多标准，如GB2006等，但是关于功能性需求方面都不能再细化展开，因此标准仅仅是一个展开。各个行业或组织还需要根据自身软件项目特点对模板进行补充和完善。
需求分析过程应该是一个业务流程驱动的至上而下的过程。开始不应该一下转入到一个具体的功能细节，而是应该先规划目录和打提纲，然后以流程为主线逐层分解和展开。在需求描述上可以是文字，也可以是图形化的，也可以是一种形式化规格表达。
需求规格说明书模板的内容也可以逆向思维，如设计需求我们提供什么样的需求对他们才是最有参考意义的。我们的需求调研不应该是通过模板格式来决定内容，再决定沟通。而是应该根据需要的沟通来决定内容，根据内容来决定我们需要什么样的需求模板和格式。
需求验证是一种质量活动，在这里要注意验证和确认的区别，一般验证活动主要方式就是Reivew，而Reivew根据正式程度又包括了审查，多人复审，单人复审等多种方式。需求验证的五大要素包括：
思想：找到尽可能多的错误
方法：从非正式的开始，并逐渐形成文化
语言：从评价者转化为建议者，强调协作者进来减少用你哪里错了，而多用我建议如何
人员：平等而且合适，减少不相关人员的参与
内容：不是全部而是最合适
需求管理的三大内容是基线，变更和状态跟踪。其实基线和变更都属于配置管理的需求跟踪。需求跟踪又包括了对需求-》设计-》测试整个需求链的跟踪，同时也包括了对需求实现状态的跟踪。在这个过程中基线是迭代开发的基础，但是迭代开发往往又是最难去规划和打基线的。在这里的原因是我们是以整个文档作为基线的对象，而不是以文档中的条目化需求作为基线的对象。另外对于变更管理其核心作用是通过变更管理减少变更对目标的影响。
迭代开发和分阶段开发
- 迭代开发是以时间(迭代周期)来划分，而分阶段开发是以任务完成来划分。
- 迭代周期一般比较短而分阶段开发的每个阶段会比较长。
- 迭代不响应变更，需要变更会转入下次迭代；分阶段开发响应变更导致混乱和计划失效。
在RUP的三要素中最后一个就是增量迭代，但是要注意到迭代是手段，增量是目标。而且每一个迭代其本身就是一个微型的瀑布。迭代使目标更加容易分解和明确。
估算是在项目管理中做项目计划的基础，不能因为估算不准确而不去做估算和计划，坚持估算和检查估算历史数据的收集就不断的纠正估算的经验数据，而使估算准确性得到提高。同时，估算的本质是计算单元和复杂因子，首先要选择好相应的估算方法，如在需求早期往往并不适合用功能点法进行估算；其次就是要识别计算单元，然后再确定具体的复杂度。
- 估算是手段，估算需要在执行过程中多次调整。
- 估算应该是基于权重的，比如我们用的根据规模到工作量的方法，比如要考虑人员效率的影响。
- 在估算后可以根据关键用例来确定第一个迭代周期的长度。
需求变更是无法避免的，但是我们要尽量减少和控制变更带来的影响。需求变更是需求管理的一个核心内容，有了需求变更自然会涉及到需求基线和配置管理的内容。例如我们可以讲对于已经基线的配置项要修改都必须要走变更流程等。对于需求变更主要有以下重点：
- 是控制变更而不是避免变更。
- 控制变更的目的是减少变更的影响，客户要意识到变更是有成本的。
- 需求团队的贡献在于尽早标识变更。
- 需要建立统一的平台来捕获，管理和控制变更。
目标的寻找方法可以用GPOA方法：GOAL-Problem-Option-Answer。在确定项目目标和范围的时候，我们往往容易提出类似要建立一个先进的信息系统一类的不清晰的目标。而如何破解不清晰的目标？可以从两个方面来考虑:内部溯源(项目的原始发起人，沟通)；外部寻因(受到外部刺激)
RUP中的问题分析五步法:
- 在问题的定义上达成共识，问题定义清楚往往问题就解决了一半。
- 要多为问题背后的问题，探求问题的本质和根源。(如鱼骨图+帕累托图)。
- 确定Stakeholders和用户，高层，中层和操作层各自的价值和关注点是什么？
- 定义解决方案系统的范围-》黑盒思维-》主题域划分-》主题域内的流程和请求
- 确定解决方案的约束
对于访谈这块的案例和实战都很好，暂时不展开了，感觉还是有很多原来在访谈中没有注意的内容，特别是开门点和访谈策略两个方面。具体综述下高层访谈主要关注点:
开门点：易于回答而且激发其兴趣
- 访谈策略：Review验证最后结果，问题不要太大，连续，挖掘不够有时候只听到一个问题
- 问题类型和挖掘：上下文，问题暴露后的分解，发展机会，约束
- 其它策略：还应该找哪些人做进一步的交流
用例是一种纪录新系统或软件更换时的需求的技术。每个用例包含一个系统在作业时与用户或与其它系统之间交换信息的场景。一般用例避免使用术语，而尽量使用顾客、用户或他们的专家的语言。一般用例由软件开发者和顾客一起写成。用例之道：
- 不是系统完成的动作行为，而应该是有价值的业务活动的分解。
- 用例是需求分析的新视角-》业务视角。用例也可以是需求管理的基本单元。
- 用例价值的测试包括两方面，一是业务活动的原子性，一是Boss测试。
- 用例的粒度可能会取决于企业内业务的分工。
- 对于用例的CRUD原则，更加重点的标准是是否是一系列随机操作，是否由一个Actor完成。
- 用例需要避免功能分解，而应该是用户业务场景驱动。
在用例中常用的关系是扩展(Extend)，包含(Include)和泛化。对于扩展和包含区别如下：
- 扩展：在某种条件是会被执行，也可能不执行。所以它有可能是一种可以划到下个迭代的。
- 包含：包含的是子事件流，必然会调用到，而且是调用完后还会会到基用例。
对于获取用例的方法主要有两种，一种是自顶向下的流程派生法，跨职能流程图和泳道就是参与者，其中的业务活动就是用例；另外一种就是自底向上的合并法，比如可以从条目化的用户需求进行合并。在第一种方法中派生用例的时候需要注意：
- 去除掉非EndUser的泳道。
- 对泳道进行角色化的抽象。
- 判断活动与系统是否有关系。
对于用例分析重点是事件和业务流程，而对于数据分析则重点是在业务数据上面。用例分析代替不了数据分析。数据分析常用的就是业务实体分析，通过数据分析可以建立系统的领域模型。数据分析的目标就是理解业务领域中的业务术语和实体，包括语义关系，数量关系和主要内容。数据分析的要点就是要识别出具体的业务实体，以及这些业务实体间的关系。在FDD中的领域建模是基于数据和行为的综合分析，包括Together之父PeterCoad发明的菜色建模法。他将数据类分为了行为，参与角色，人事物，通用描述四个方面的内容。
在用例模板中有几个关键点，包括前置条件应该是系统必须能够检测和验证的。在用例描述中应该拒绝太多的实现细节；用例本身无法展示很多界面交互，因此需求建模还应该包括界面和交互建模的内容。而对于报表等需求往往并不太适合用例的表达方式，可以根据企业情况来确定具体的报表类需求的描述方法。
在用例模板中还有干系人利益的内容，在这里特别说明的是分析干系人利益可以帮助我们挖掘潜在的需求。虽然关系人不是Action事件的之间操作者，但是干系人的利益往往会影响到用例本身的需求。
