20、需求文档

1、启发与建模确认启发分析核实批准定义：从涉众出获取素材要领：交流内容聚焦于涉众利益需求工程师综合不同涉众的利益编出需求涉众无资格、无责任提供需求患者无资格、无责任决定自己是什么病；医生才有。“我想要一个QQ那样的”交流形式采用视图模型和视图分离：“几百万的项目怎么才十几页纸？”视图宽松，模型严格：“你这个图我看不懂，画我看得懂的图！”交流和开发分离要素目标参与者问题简单问题放在一头一尾，难的问题摆中间保证回答难问题前有预热，会谈结束时有积极的基调关注点有重大商业价值有重大的风险有很多项目未知点和不确定性有重大技术挑战对其他组件和接口有依赖需要依赖第三方资源资源有限或有资源离开项目的风险研究客户资

2、料研究竞争对手访谈观察行业书籍文章、竞争态势工作手册、规章制度工作表格、作业日志、EMAIL过去的涉众利益积累找对竞争对手：产品分类：和要做的系统同类的产品有哪些？用途分类：对用途而言，目标用户有哪些其他选择？竞争对手是如何解决客户问题的？为什么会有这些功能？客户对竞争对手的评价，好在哪里？不好在哪里？涉众代表必须名副其实：涉众代表！=部门主管选择经验丰富的涉众系统就是为了学习他的经验主要工作是哪些？哪些工作占用时间最多？哪些是绝对不能出错的关键工作？这项工作需要哪些材料？出来哪些结果？具体怎么做的？平时做的时候最烦什么？如果是新手来做这项工作，哪些地方容易出乱子？这项工作如果做不好，会有哪些

3、部门或岗位不高兴？哪些岗位或部门没做好，会影响这项工作的完成？引导涉众举例，具体不要抽象用“最”来激发涉众不要忽略人脑的逻辑问为什么，深入探索在工作环境访谈，深入第一线重点关心：完成一项工作所需时间操作次数出现的错误和混乱工作环境的特殊性1.类图数据层2.序列图业务层3.状态机图表示层责任责任和用例的关系和用例的关系命名命名边界类输入输出简单过滤每个有接口的外系统映射一个边界类外系统名称+接口控制类控制用例流为实体类分配责任每个用例映射一个控制类用例名称+控制实体类系统的核心封装领域逻辑和数据用例和实体类的关系是多对多的领域概念命名 用户只接触边界类UI，边界类对应界面边界类调用控制类UC的用

4、例，控制类调用实体类的功能，控制类对应用例实体类是功能（function）和属性的集合（property）分解只属于部分对象的属性到子类泛化和关联是静态，依赖是动态，尽量通过序列图展示。先对泛化和关联建模，剩下的看作是依赖结构映射类表属性列对象行作用：找到类以后，完成类的责任分配 可以合并到基本路径图单独一张图，在基本路径图引用Include、Extend用例也适用专家原则资源决定消息内容老板原则由老板发送消息给我可视原则只发消息给朋友专家原则专家要专一单一责任原则大责任分解老板原则当出现以下情况时，发给A的消息先通过B处理和中转B聚合A（Aggregation）B组合A（Compositio

5、n）只能发消息给：自己方法参数中的对象属性引用的对象（关联）你创建的对象帮助定义恰当的责任帮助缩窄接口转换内部动作：entry:进入时必须执行exit:离开时必须执行event:发生event时内部执行执行顺序当前S1：e发生：执行b，到S1g发生：执行c，d，a，到S1f 发生：执行c，到S2最简洁的界面：刚好能履行分析所赋予的责任查询条件输入框，”提交“按钮”列表框“”零件详细信息“的表单界面类接收大量消息，不断改变状态界面正确功能需求可靠性需求界面稳定可用性需求界面高效同行审查(peer review)在需求评审会议前进行有助于确保需求不含有低级明显的错误；在需求审查会议后进行确保最终需

6、求文件能得到解决方案团队和开发团队的理解和接受检查（inspection）是同行审查的严格版本；由参与了需求的创建和编写过程的同行来进行， 他们是需求文件的接收者检查有检查清单， 而同行审查没有。目的：确保解决方案满足用户需求要点：不断确认需求巡检解决和需求相关的冲突德尔菲技术多票制加权排序(不赘)时机：需求文件记录后；需求研讨时；检查刚采集到的需求；向干系人展示解决方案时定义：与干系人一起对需求进行审查， 得到他们对需求有效性的确认；重要性：这个环节是干系人提出问题， 澄清需求和提出担忧的最后机会执行要点：在召会之前要给干系人有充分的准备时间，让干系人了解清楚解决方案，并在团队内充分讨论，以免到大会讨论时感情用事先个别访谈以后才能知道如何组织/主持会议，否则在会议上争吵后，日后更难沟通。目的：通过会议上升到集体意见，再对会议外的大众宣布，方能服众德尔菲技术Step 1.挑选专家Step 2.匿名分析Step 3.重复