软件需求最佳实践.docx

软件需求最佳实践 -04-03 作者：人月神话 来源：人月神话的BLOG  需求实践所面临的问题· 需求完整性需要诸多顾客的参与和确认，并且顾客间需求自身也存在冲突的也许，因此需求更加强调角色和场景和划分，一种所有顾客需要都可以满足的需求往往不是一种好需求 · 需求过程缺少顾客的参与，我们往往是技术驱动，习惯性的跳到模块的划分导致需求自身验证困难，也导致了需求间耦合很紧，很难在后期组织有效的迭代开发因此要考虑按流程和业务梳理需求 · 需求无法实现也也许不是架构问题，而是需求自身不切实际 · 顾客想要和真正需要是有区别的，没有真正的辨认需求优先级也许导致需求过量开发和需求镀金 · 需求优先级辨认往往并不能完全依托顾客，顾客往往只会把自己关注功能讲优先级辨认的很高，因此需求优先级辨认应当是通过业务规则，流程和模式来拟定优先级辨认措施(离主营业务的远近，发生的频率两个方面来度量) · 沟通失真，要结识到文档仅仅是中介而不是所有，要通过即时的验证来减少沟通失真 · 需求捕获和调研常用问题-顾客告诉你的是她转化后的解决方案，而不是最原始的需求 · 变更频繁，但是要响应变化，例如通过对变更分类来辨认哪些变更是可以通过复用和可配备解决的。

· 非功能性需求为有效的辨认，仅仅是定性，而没有通过定性->场景->定量的路线 需求分析的核心线索在原有的需求分析措施中，我们往往过多的关注How，而没有关注What，或者关注了What而没有关注What背后的需求场景和背后的问题Why这都导致我们没有进行较好的需求挖掘需求分为业务需求，顾客需求和软件需求三个层面而我们在平时的需求分析中往往很容易直接跳到了软件需求阶段，而忽视了业务需求和业务建模· 业务需求=目的+范畴 · 目的的体现必须涉及目的+优势+度量+合理+可行，或者说SMART原则同步在目的体现上可以考虑场景法，即问题是什么-》影响谁-》后果是什么-》解决方案长处是什么？ · 范畴体现的两个重要方面是人和物，人涉及干系人和最后顾客；物涉及业务事件和管理控制点 需求定义输出业务需求；需求捕获输出顾客需求；需求分析输出软件需求需求分析的本质动作就是分解，抽象和消除歧义而对于需求分析的本质线索则是人，事(流程)，物(数据)和接口因此需求分析不能完全等同于建模型分析是本质，建模仅仅是手段需求捕获需求捕获是一种不断的摸索过程在需求捕获中，沟通占40%，业务占30%，技术占30%而对于沟通往往讲究的并不是单纯的技巧，而更多的是一种思维模式和顺序的问题。

在这里教师引入了思维模式的话题，也通过一种案例解说了沟通中顺序的重要性，如先将解决方案再讲具体场景和问题(类似于我上个ppt里面强调的构造化思维的一种重要原则即开门见山的逐级展开)在沟通中讲了三个可以借鉴的措施· 未知问题->已知问题 · 相对重要->相称次要(发明一种比较的环境给顾客) · 关注点的转换->(沟通也要洞察心理学) · 隐喻(将了一种用中文的赢字来体现项目管理核心) 探求本源(问题背后的问题，引入了《你的灯亮着吗》，讲到了没有荒唐需求，只有荒唐的解决方案)需求访谈是捕获中的一种重要内容，这里做一种概括总结：· 一方面要弄清晰你访问的顾客自身的角色和特点，前期要收集足够的资料，然后制定针对性问题 · 应当是先访谈有了初步的聚焦后，再进行调查 · 访谈的顾客分类涉及(顾客特点，功能/流程，数据，非功能性和接口) · 调查问卷设计诸多讲究，如避免简朴的排序题，调查问卷中的C现象和D现象等，不展开 需求规格阐明书业界关注需求有诸多原则，如GB等，但是有关功能性需求方面都不能再细化展开，因此原则仅仅是一种展开各个行业或组织还需要根据自身软件项目特点对模板进行补充和完善需求分析过程应当是一种业务流程驱动的至上而下的过程。

开始不应当一下转入到一种具体的功能细节，而是应当先规划目录和打提纲，然后以流程为主线逐级分解和展开在需求描述上可以是文字，也可以是图形化的，也可以是一种形式化规格体现需求规格阐明书模板的内容也可以逆向思维，如设计需求我们提供什么样的需求对她们才是最有参照意义的我们的需求调研不应当是通过模板格式来决定内容，再决定沟通而是应当根据需要的沟通来决定内容，根据内容来决定我们需要什么样的需求模板和格式 需求验证是一种质量活动，在这里要注意验证和确认的区别，一般验证活动重要方式就是Reivew，而Reivew根据正式限度又涉及了审查，多人复审，单人复审等多种方式需求验证的五大要素涉及： 思想：找到尽量多的错误 措施：从非正式的开始，并逐渐形成文化 语言：从评价者转化为建议者，强调协作者进来减少用你哪里错了，而多用我建议如何 人员：平等并且合适，减少不有关人员的参与 内容：不是所有而是最合适 需求管理的三大内容是基线，变更和状态跟踪其实基线和变更都属于配备管理的需求跟踪需求跟踪又涉及了对需求-》设计-》测试整个需求链的跟踪，同步也涉及了对需求实现状态的跟踪在这个过程中基线是迭代开发的基本，但是迭代开发往往又是最难去规划和打基线的。

在这里的因素是我们是以整个文档作为基线的对象，而不是以文档中的条目化需求作为基线的对象此外对于变更管理其核心作用是通过变更管理减少变更对目的的影响迭代开发和分阶段开发· 迭代开发是以时间(迭代周期)来划分，而分阶段开发是以任务完毕来划分 · 迭代周期一般比较短而分阶段开发的每个阶段会比较长 · 迭代不响应变更，需要变更会转入下次迭代；分阶段开发响应变更导致混乱和筹划失效 在RUP的三要素中最后一种就是增量迭代，但是要注意到迭代是手段，增量是目的并且每一种迭代其自身就是一种微型的瀑布迭代使目的更加容易分解和明确估算是在项目管理中做项目筹划的基本，不能由于估算不精确而不去做估算和筹划，坚持估算和检查估算历史数据的收集就不断的纠正估算的经验数据，而使估算精确性得到提高同步，估算的本质是计算单元和复杂因子，一方面要选择好相应的估算措施，如在需求初期往往并不适合用功能点法进行估算；另一方面就是要辨认计算单元，然后再拟定具体的复杂度· 估算是手段，估算需要在执行过程中多次调节 · 估算应当是基于权重的，例如我们用的根据规模到工作量的措施，例如要考虑人员效率的影响 · 在估算后可以根据核心用例来拟定第一种迭代周期的长度。

需求变更是无法避免的，但是我们要尽量减少和控制变更带来的影响需求变更是需求管理的一种核心内容，有了需求变更自然会波及到需求基线和配备管理的内容例如我们可以讲对于已经基线的配备项要修改都必须要走变更流程等对于需求变更重要有如下重点：· 是控制变更而不是避免变更 · 控制变更的目的是减少变更的影响，客户要意识到变更是有成本的 · 需求团队的奉献在于尽早标记变更 · 需要建立统一的平台来捕获，管理和控制变更 目的的寻找措施可以用GPOA措施：GOAL-Problem-Option-Answer在拟定项目目的和范畴的时候，我们往往容易提出类似要建立一种先进的信息系统一类的不清晰的目的而如何破解不清晰的目的？可以从两个方面来考虑:内部溯源(项目的原始发起人，沟通)；外部寻因(受到外部刺激)RUP中的问题分析五步法:· 在问题的定义上达到共识，问题定义清晰往往问题就解决了一半 · 要多为问题背后的问题，探求问题的本质和本源如鱼骨图+帕累托图) · 拟定Stakeholders和顾客，高层，中层和操作层各自的价值和关注点是什么？ · 定义解决方案系统的范畴-》黑盒思维-》主题域划分-》主题域内的流程和祈求 · 拟定解决方案的约束 对于访谈这块的案例和实战都较好，临时不展开了，感觉还是有诸多本来在访谈中没有注意的内容，特别是开门点和访谈方略两个方面。

具体综述下高层访谈重要关注点:开门点：易于回答并且激发其爱好· 访谈方略：Review验证最后成果，问题不要太大，持续，挖掘不够有时候只听到一种问题 · 问题类型和挖掘：上下文，问题暴露后的分解，发展机会，约束 · 其他方略：还应当找哪些人做进一步的交流 用例是一种纪录新系统或软件更换时的需求的技术每个用例涉及一种系统在作业时与顾客或与其他系统之间互换信息的场景一般用例避免使用术语，而尽量使用顾客、顾客或她们的专家的语言一般用例由软件开发者和顾客一起写成用例之道：· 不是系统完毕的动作行为，而应当是有价值的业务活动的分解 · 用例是需求分析的新视角-》业务视角用例也可以是需求管理的基本单元 · 用例价值的测试涉及两方面，一是业务活动的原子性，一是Boss测试 · 用例的粒度也许会取决于公司内业务的分工 · 对于用例的CRUD原则，更加重点的原则是与否是一系列随机操作，与否由一种Actor完毕 · 用例需要避免功能分解，而应当是顾客业务场景驱动 在用例中常用的关系是扩展(Extend)，涉及(Include)和泛化对于扩展和涉及区别如下：· 扩展：在某种条件是会被执行，也也许不执行因此它有也许是一种可以划到下个迭代的。

· 涉及：涉及的是子事件流，必然会调用到，并且是调用完后还会会到基用例 对于获取用例的措施重要有两种，一种是自顶向下的流程派生法，跨职能流程图和泳道就是参与者，其中的业务活动就是用例；此外一种就是自底向上的合并法，例如可以从条目化的顾客需求进行合并在第一种措施中派生用例的时候需要注意：· 清除掉非EndUser的泳道 · 对泳道进行角色化的抽象 · 判断活动与系统与否有关系 对于用例分析重点是事件和业务流程，而对于数据分析则重点是在业务数据上面用例分析替代不了数据分析数据分析常用的就是业务实体分析，通过数据分析可以建立系统的领域模型数据分析的目的就是理解业务领域中的业务术语和实体，涉及语义关系，数量关系和重要内容数据分析的要点就是要辨认出具体的业务实体，以及这些业务实体间的关系在FDD中的领域建模是基于数据和行为的综合分析，涉及Together之父PeterCoad发明的菜色建模法她将数据类分为了行为，参与角色，人事物，通用描述四个方面的内容在用例模板中有几种核心点，涉及前置条件应当是系统必须可以检测和验证的在用例描述中应当回绝太多的实现细节；用例自身无法展示诸多界面交互，因此需求建模还应当涉及界面和交互建模的内容。

而对于报表等需求往往并不太适合用例的体现方式，可以根据公司状况来拟定具体的报表类需求的描述措施在用例模板中尚有干系人利益的内容，在这里特别阐明的是分析干系人利益可以协助我们挖掘潜在的需求虽然关系人不是Action事件的之间操作者，但是干系人的利益往往会影响到用例自身的需求。