第4章-初始不是需求阶段

《第4章-初始不是需求阶段》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、第4章初始不是需求阶段InceptionisnottheRequirementsPhase第二部分初始阶段初始不是需求初始阶段的目的是决定是否继续进行项目的开发，而不是定义需求。只要关键的需求被调查初始阶段关注的问题项目的愿景(vision)是什么？有哪些业务案例(businesscase)?项目是否可行？购买还是开发？粗略估计成本？在初始阶段结束时：要决定项目是否继续进行下去？一句话概括初始阶段预见项目的范围、愿景和业务案例。一句话概括初始阶段要解决的问题涉众(stakeholders)是否就项目愿景基本达成一致，项目是否值得继续认真研究。初

2、始阶段持续的时间可能只包含第一次需求讨论会（2天）制定第一次迭代计划（1天）初始阶段会创建的制品不是每个项目都需要完整的文档愿景和业务案例描述高阶目标与约束、业务案例，并提供执行摘要.通常会对项目的预算有个大概的估算，并且会列出期望的收益。用例模型(UseCaseModel)描述功能性需求列出大部分所期望的用例的名称和参与者的姓名，在只有10%的用例会被详细分析不要混淆用例图和用例。用例是用文本描述的。补充性规格说明SupplementarySpecification描述其它需求，主要是非功能性的需求多考虑关键的非功能性需求.词汇表(Gloss

3、ary)描述业务领域的关键术语和数据字典风险列表和风险管理计划包括可能遇到的风险的清单包括业务、技术、资源和进度方面的风险，标出可能性和严重性.所有主要的风险应该有应对和缓解的方法。原型/概念验证用来澄清愿景，验证技术思路初始阶段的原型是抛弃型的原型，而不是进化型的。通常使用一些原型工具来建立。迭代计划描述第一个细化迭代的任务.第一个迭代通常实现产品的核心功能。在第一时间消除最大的风险。最糟糕的风险往往是：最终产品无法满足最重要的需求。阶段计划/软件开发计划对细化阶段的持续时间和工作量进行粗略的估计，包括工具、人力、培训等。又称为“资源计划”开

4、发案例DevelopmentCase就特定项目，对UP步骤和制品进行定制的描述。何时知道自己并不了解初始阶段(遇到麻烦的信号)进度认为初始阶段应该持续几个星期需求定义在初始阶段试图定义大部分的需求.精确估计期望初始阶段的预算和计划是可行的定义架构应该在细化阶段以迭代的方式来定义架构瀑布法思想认为正确的工作顺序应该是定义需求设计架构实现产品没有业务案例或愿景制品用例认为应该详细编写所有的用例.认为不用编写详细用例应该详细编写10or20%用例