第二部分-需求开发
需求定义最佳实践
清晰的项目目标和范围定义，能够引导需求工作顺利进行。
对混沌不清的目标，可以通过内部寻根或外部溯源来破解。
对问题进行了正确的定义，意味着成功解决了一般。而在问题定义时应该善于使用转换和本源两种技巧。
需求定义阶段要善于将未知解问题转换为已知解问题。
在确定某问题的解决方案是，一定要思考是否会引发新的问题。
直接修改错误，不要用其他方案来弥补错误。
鱼骨图为解决问题找到了靶子，帕累托图则表上了环数。
范围是设计的是、物，边界是人与系统的职责边界。
用户永远会希望花同样的钱，获得尽可能多的功能。
需求阶段描述的是用户的能力特点，旨在提高可用性。
你可以不做一件事，但一定不能不知道为什么做这件事。
在分解系统时，应该按业务的脉络来划分成不同的主题域。
各个主题域之间的服务接口是需求变更的防火墙。
确保能做的事和知道的事相匹配是职责驱动设计的要点。目标决定范围。
绘制上下文图关系图，先考虑Customer再考虑Worker是要点。
业务事件应该是主动触发的，并且将会一系列后续行为。
业务事件是直接作用于系统的，也就是将触发系统行为。
需求捕获最佳实践
需求捕获是撒网打鱼，不是休闲钓鱼。
善于聚焦访谈话题是需求捕获人员成功的关键。
尝试理解业务场景是合格需求分析人员的良好习惯。
善于利用技术为用户创新体验是优秀需求人员的特质。
通过比较用户代表的表述来识别言过其实，利用差异展现、瓶颈分析法来缓解影响。
针对越俎代庖心理现象最有效的方法是识别正确的被访谈者。
离开办公室、对访谈进行计划是避免非正事现象的主要手段。
化敌为友是缓解抗拒心态的主要方向。
倾听对象的抱怨是化敌为友的有效手段之一。
突破推卸责任心理的简单手段是让被访谈者介绍工作场景。
需求捕获时不要忽视对变更可能的了解。
在需求捕获时要善于使用“？”之箭，找到真正的需求。
“拨开立场，寻找利益诉求”是需求协商的要点。
不要孤立地看待需求项，应该将所有需求视为一个整体。
“环境”将改变结果，切换不同的视角会得到不同的认识。
善于打比方是提高跨专业沟通效果的好方法。
占用时间长和信息的片面性是用户访谈的两大敌人。
访谈的线索是因“人”（用户类型）而异的。
尽量将访谈问题事先发给被访谈者，让他打一场有准备之战。
在需求补货时别忘了“一图抵千言”这句经典提示。
用户调查能够有效克服用户访谈中存在的片面性。
在需求捕获中，先访谈再调查是更合理的方式。
大样本用户、跨地域用户的存在就是使用用户调查的时机。
分析文档资料时应该思考流程对其的影响。
收集文档时，应该尽可能让用户提供带有真是数据的样本。
需求捕获人员要善于根据流程分析的结果主动收集相关文档。
清洁串联版是消除用户盲区的有效技术。
情景串联板应该以业务场景作为展示的主线索。
交互才是情景串联板的本质，不要只关注与界面的静态效果。
现场观摩技术是消除开发团队认识盲区的有效手段。
现场观摩技术能够使开发团队实现对业务场景“感同身受”。
联合开发是突破书暗访需求盲区的有效手段。
出现“上开大会，下开大会”现象，一半责任在组织者。
沟通决定内容，内容决定格式。
在第二个阶段重点就是粒度的细化，从主题域我需要细化一层到识别了关键业务对象的领域视图，从业务事件进行流程分析我们需要讲业务事件细化一层到具体的业务活动，而业务活动正式我们在识别用例的时候的重要参考。所以在这里我们基本清楚了第二阶段刚开始是通过业务事件进行业务流程分析，业务实体分析，业务场景分析，识别领域类和用例。
需求分析就是先分解，在提炼，然后在这个过程中消除矛盾。不管是采用结构化的方法还是面向对象的方法，分解是人类控制复杂性，认知复杂事物的最佳实践。现代工程理论更建议采用业务导向的分解而非系统导向的分解。在第一阶段的分解我们可以看到以主题域为主线索，具体的分解过程为目标系统-》主题域-》业务事件；到了第二阶段则是以业务流程为主线索进行分解，具体为业务事件-》业务流程和业务活动-》领域类图和用例。
业务流程是对信息系统进行庖丁解牛的核心线索，每个业务事件都是一个业务流程的触发，因此针对每个业务事件都应继续做业务流程分析。对于业务流程是企业核心业务的重要载体，业务流程本身就是结构化的，而且是分级的，通过分析业务流程就能够识别企业核心业务活动，为需求建模做好准备工作。
在这个阶段我们看到两个重要输出，一个是静态的领域类涉及到领域建模，而领域建模的重点就是标识类，明确类之间的逻辑关系和数量关系，添加重要的结构规则。另外一个就是动态的用例，在RUP核心三要素中专门强调了用例驱动，足见用例建模的重要性，但是我们要注意到第二阶段的重点仍然是搭框架结构，因此并没有要求要识别所有的领域类和用例。