需求开发与需求管理概述

lsekfe

　项目管理的日常活动包括了：需求管理、故障管理、版本管理、任务管理。
　　需求管理贯穿了项目的大部分生命周期，故障管理则从第一个迭代版本出现直到产品维护阶段（包括内部故障与外部故障）结束。
　　所以：需求驱动开发，需求是开发的上游。
　　广义的需求管理就是指需求工程，需求工程常分为需求开发（RD：requirementdevelopment）和需求管理（RM：requirementmanagement）。
　　简述之：
1，需求开发=需求获取与分析+编写需求文档+评审并确认需求文档。
　　解释：
　　在需求文档得到下游（开发、测试）确认后，被传递给下游进入代码开发与需求测试活动。二者不属于需求开发范围。
　　由于目前的开发大多常用迭代版本(即：增量开发)，一个项目中包括了多个版本，在项目起始时制定第一个版本的需求基线，在后续每个版本开发前都会补充新的需求（也会删除、修改需求）。所以需求开发计划也包括了多个周期。
　　2，需求管理＝版本规划+需求变更控制+需求状态跟踪+需求追踪。
　　解释：
　　版本规划常称为制定需求基线，它应该制定本项目周期内，每个版本所包括的需求列表（有时版本内功能也包括了某些故障的解决，或把故障以需求的形式进行跟踪）。
　　需求变更控制针对上面提到的需求开发的多个周期进行控制，需求开发活动每个周期开始时都依靠需求变更控制活动来确认需求范围。
　　需求状态跟踪与需求追踪在我看来是颗粒度粗与细的关系，体现了进度控制的作用。
　　需求管理计划与需求开发计划是不同的项目管理计划、受不同的项目进度计划控制，但不同的活动又紧密联系在一起，交叉。
　　在传统的、理想的开发模型中，需求开发活动（这个阶段中也受需求管理活动控制）完成后，需求不再变更，则之后只剩下需求管理活动直至本项目最终版本发布。但实际上，在版本发布之前、甚至版本维护阶段，仍有新的需求产生，则需求开发活动仍然不断持续中，这就是：需求开发多周期的意义。
　　需求开发
　　包括以下各活动
　　1.需求获取与需求分析：
　　在定义了项目目标后，需求收集人员运用各种方法\工具，从不同的渠道，获取真实的需求。
　　需求收集工具：市场调查、原型、需求专题讨论会、头脑风暴、同类/类似产品解剖、历史经验（如以前版本中遗留下来的未实现功能）等。
　　渠道包括：如市场、客户/用户、竞争对手、研发等
　　真实的需求：原始需求可能只有一句话，但整理成的用户需求可能包括（但不限于）：市场必要性、功能（技术可行性分析、需求场景及主要过程、可验证性）、需求优先级及影响面分析、性能、质量、外部接口、应符合的业界标准、实现的限制（指某些不能满足的场景需要明确列出）、国际化等，并整理成用户需求文档或需求属性列表。
　　需求分析工具：建模、图形化分析、创建原型、编写数据字典、UseCase、序列图、流程图。。。
　　分析的结果(用户需求文档)，应该得到客户或需求提交人的确认。
　　有些教材将需求获取与需求分析分成两个活动，但在我看来，这两个活动是融合在一起的，获取的过程中需要明确一些细节，当然需求细节的颗粒度仍然较粗，这里也是考察需求收集人员业务能力的时候，有能力的需求收集人员应该尽可能获取或分析出真实的需求，颗粒度适合研发需要为好。
　　或者可以这样认为：需求最初获取的是原始需求，需求分析时进行细化、转换、显式化上层需求，得到用户需求（但分析过程中也会向客户确认细节）。
　　注1：客户常见的困难在于：“我知道你已理解我所说的，但我不知道我所说的是否就是我真正想要的”，“只要一看到它，我就知道我要的正是它，但是我无法准确描述”
　　注2：如果把活动与项目阶段作严格对应的话，整个需求开发阶段还应该包括：
　　1)，一些需求管理或需求状态跟踪的内容
　　用一个表格维护：需求提交人、需求来源（客户公司名称、项目等）、需求名称、需求描述、提出时间、要求对外发布时间点或承诺时间点、要求决策时间点（即答复客户是否能满足要求的时间点）、需求分析人、需求状态（已拒绝、分析中、已批准。。。）、需求优先级、对外部项目的影响、用户需求文档归档路径等。
　　2)，需求决策：项目组内对于用户需求的评审及确认是否接受的控制过程。接受后即为已批准状态。
　　3)，文档管理
　　原始需求文档、用户需求文档的归档及列表记录，
　　重点需求或经过反复讨论过的需求，应该将需求讨论记录、会议记要归档或附到用户需求文档中。
　　2.编写产品需求：
　　对用户需求文档进行细化，将需求过程对应到具体的产品，有时也称为SRS（SystemRequirementSpecifications）或XX需求说明书。
　　7+4特征：
　　单条需求：完整性/正确性/可行性/必要性/划分优先级/无二义性/可验证性；
　　需求说明书：完整性/一致性/可修改性/可追踪性
　　用户需求文档应视为与外部客户之间的“契约”，而产品需求文档则是软件公司内部的“契约”，后者是产品方案、产品详细设计（HLD，HighLevelDesign)、[url=]系统测试[/url]的基础与依据。
　　它是需求评审、需求管理的对象（我认为：用户需求也在需求管理的范围之内）
　　3，评审并确认产品需求文档
　　评审产品需求文档，它确定了项目交付时用于评判是否符合客户要求的验收准则（内部交付依据产品需求，对客户交付依据用户需求）
　　有时也称为需求验证、需求审核，它不是指验证代码，而是指审核需求文档。
　　发现缺陷越多的评审，是越成功的评审。
　　评审员越全面越好：客户、用户需求作者、产品需求作者、开发代表、测试代表、用服代表、市场代表、售后代表、质量代表。。。
　　激励评审员的积极性，也是项目管理的一个难点之一。
　　4，测试用例、操作手册的开发
　　在产品需求完成同时，应完成以下两个活动：
　　以需求为依据编写测试用例、编写用户操作手册（侧重于功能方面）；
　　这两个活动依据产品需求进行，且可以在产品方案设计前完成。
　　注：为什么不在代码入库，或开发代码时再编写测试用例：由于系统测试用例是基于需求做的，测试经常发现不了需求缺陷。所以要求在审核需求阶段就考虑测试标准，并在需求审核完成后，紧随其后就编写测试用例。
　　编写用户手册也是同样的道理。
　　需求管理
　　需求管理作为整个项目计划的一部分，在项目立项后，项目经理应首先明确：需求管理的活动、方法和资源。
　　需求管理目的：使顾客和项目队伍对系统建立一致并保持一致，保持一致意味着计划、活动、工作产品都要和需求保持一致，不能偏离。
　　所以：需求管理不仅是项目目标的体现，也是项目进度控制的主要手段之一。(其它的手段如：开发计划、测试计划、项目里程碑。)
　　任何活动都可分为三个阶段：
　　1，计划
　　2，执行与进度控制
　　3，验收与收尾
　　需求管理的每个子活动与上述三个阶段可以对应起来理解。
　　比如需求跟踪是属于进度控制的范围，但也包括了已验收状态的记录。
　　收尾时所有需求均进入了已发布状态，项目一般会进行文档的配置管理的补充与审核工作，比如功能清单、版本发布说明、产品规范。。。应该提交。
　　基于需求驱动开发的理念，以需求管理、需求变更控制为主线，将需求、设计、开发、测试和项目管理完全工具化管理。
　　1，制订需求管理计划
　　立项后完成。
　　包含：
　　有关人员的角色职责：
　　产品\项目CCB(ConfigurationControlBoard配置控制委员会)(产品与项目并不等价，产品内可能包括多个项目，反之也可能)，CCB成员包括：主席、秘书、项目经理、开发经理、xx开发组负责人、测试代表、QA代表。。。
　　各人在各子活动中的作用：牵头、组织、负责、参与、旁听、被通知、拍板或决策权。
　　工具与方法：
　　原始需求收集的工具、需求跟踪工具、需求追踪工具、需求变更工具（各工具可使用如Excel表格、邮件、Word文档、软件工程软件、自己开发的OA系统。。。）、度量指标（如需求总数、已完成需求个数、测试中需求个数、已发布需求个数。。。）、项目需求例会机制、版本规划工具（如excel、microsoft的Project...)、版本规划例会、项目CCB会议机制。
　　各工具、指标、会议机制的具体内容（如excel中应该包括哪些字段）、负责人、参与人。
　　需求追踪：需要追踪的工作产品类别及其追踪粒度：
　　需求追踪的工作产品包括：市场需求文档、产品需求文档、系统测试用例、组件级需求、组件级方案、设计文档、代码模块\函数，前三者应该是最基本的跟踪粒度。有些非常敏捷的项目可能把产品需求文档也省掉了。
　　需求状态跟踪：跟踪的需求状态及其跟踪方法：
　　用户需求、产品需求、产品组件需求的各种状态（可能是不同的），如已提出、已批准或采纳、已删除、已拒绝、开发中、分析中、测试中、已实现、已验证、已发布、变更中、已变更、已延期。。。，项目需要为状态进行定义。
　　部分项目可能跟踪的需求粒度更大或更小。由于有若干层次的需求，因此，需要明确需要跟踪的是哪个层次的需求(原始需求、用户需求、产品需求。。。）
　　接受用户需求、产品需求的准则，如项目可以定制自己的需求评审检查单。
　　定义审核频度：将项目组从技术角度对追踪关系的审核要求明确化。
　　注：需求管理活动可以酌情剪裁掉许多内容，视项目情况而定。
　　在数十、上百研发人员参与的大项目，需求繁多、变更频繁、质量要求高时，需要更多的管理成本投入到各种需求管理活动中。
　　也有些公司，虽然项目大且需求复杂，但参与项目的各方已经建立了一套约定俗成的规则，员工的职业成熟度较高，对于自己岗位的职责比较明确，较少发生扯皮事件，上下游之间配合较好，可以剪裁掉一部分需求管理活动，比如需求评审、变更评审、需求追踪\跟踪的简化、不再维护产品需求文档等。
　　注：需求管理工具中还应该包括沟通机制、文档访问控制，和设计方案、测试计划、配置工具的结合，跨项目追踪能力。
　　有些商业工具可以完成需求管理的全套或有关工作：提交用户需求、指派SE分析、提交分析结果、文档归档与基线化、决策记录与执行决策（拒绝或采纳、挂起、转交、拆分）、需求规划入版本、需求基线化、需求变更、需求状态跟踪（需求状态的变更）、需求单派生出文档单\代码单（与设计方案、代码开发计划的有效衔接）、导出需求追踪矩阵、提交版本、批准版本、生成roadmap、版本发布、计算需求度量指标、需求决策与变更通知有关人等、人员角色分组自定义。加上强大的统计、分析、图形功能。
　　基于文档（比如Word、Excel)存储需求的方法有若干限制。例如：
　　很难保持文档与现实的一致(即文档的变更没有进行正确跟踪，手工跟踪只能通过详细的修订记录表格来记录变更详细情况与变更历史，很容易懈怠)；
　　通知受变更影响的设计人员是手工过程（一般是通过邮件通知联系人分组，对方可能会忽视邮件）；
　　不太容易做到为每一个需求保存增补的信息(每次变更的修订必须手工记录、维护，很难保证全面，商业跟踪工具可以与SVN版本建立关联)；
　　很难在功能需求与相应的使用实例、设计、代码、测试和项目任务之间建立联系链（与第一条文档与现实的理由一样）；
　　很难跟踪每个需求的状态(Excel做这个较好，但Word的表格功能则较差，行列长度个数受页面大小控制而不能让字段太多，没有筛选功能)；
　　部分项目选择Excel、结合word进行需求管理的原因可能是：商业工具的性能较差（全公司数千个项目都在[url=]数据库[/url]内维护），公司定义的流程不符合项目需要、公司IT部门对项目需求的反应太慢。