德信无线标准软件过程tssp-08-软件需求管理过程培训

需求管理流程,曾 新 宇(Eric Zeng)UI. Group / SW Depart.,提纲:,需求的概念需求工作流程需求管理需求的收集需求的评估需求的实现需求的跟踪需求变更,1.需求的概念,需求包括业务需求、用户需求和功能需求。业务需求（Business Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（User Requirement ）描述了用户使用产品必须完成的任务，功能需求（Functional Requirement ）定义了开发人员必须实现的软件功能。,1.需求的概念(1),1.需求的概念(2),1.需求的概念(3),需求包括业务需求、用户需求和功能需求。业务需求（Business Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（User Requirement ）描述了用户使用产品必须完成的任务，功能需求（Functional Requirement ）定义了开发人员必须实现的软件功能。 NASA的软件开发过程中的概念，软件需求过程的标准是：清楚(Clear)完整(Complete)一致(Consistent)可测试(Testable)其他的概念，如可跟踪的、可修改的等等。,1.需求的概念(4)_清楚,目前大多数的需求分析采用的仍然是自然语言（如果采用形式化语言的话，意味着客户在开发软件之前必须先进行形式化语言培训，这是不现实的）。自然语言对需求分析最大的弊病就是它的二义性。所以尽量采用主语动作的简单表达方式。需求分析中的描述让人看上去像是小孩子刚学习写作。不要采用疑问句、修饰这些华丽的表达方式。除了语言的二义性之外，主意不要使用行业术语。以免和用户沟通时造成用户理解上的困难。例如银行的信用卡系统，可以描述软件需求为：银行的卡部管理信用卡，每张信用卡只属于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。,1.需求的概念(5)_完整,需求的完整性是非常非常重要的，如果出现需求遗漏就不得不返工。这仅仅是你的问题，更多的问题发生在用户那里，因为他们不知道该做些什么。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。,1.需求的概念(6)_一致,简单的来说，就是用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。在实现过程中，我们还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。,1.需求的概念(7)_可测试,真正的测试开始于需求分析过程。需求分析是测试计划的输入和依据。这就要求需求分析是可测试的。什么是可测试？“我们要用新的系统完成报表自动化处理”，例如该需求就是不可测试的。报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。因此这项需求是无法测试的，就是不具有可测试性。前面的需求标准都是为了保证需求的可测试性。只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。大家真正在应用一些科学的方法的时候也应该记住，任何的方法都是为了保证软件的成功，不能偏离这个目标。,1.需求的概念(8)_写作,写作软件需求时应记在心上的原则： 保持句子和段落简短； 从开发者的立场来看，检查需求陈述是否足够明确；努力找到一个适当的层次来写作；检查是否有一个陈述表达了多个需求，将它们分开；整个需求文档的写作都保持在一个一致的细节层次上； 避免陈述冗余的需求。,1.需求的概念(9),用户需求与系统需求的区别 :在许多开发中常常混淆用户与系统需求。 分析人员过分重视定义系统功能以至于忽略用户的想法；系统需求定义抽象的解决方案，而用户需求定义问题或系统对用户产生的结果。用户应该拥有用户需求并且应该使用他们能够理解的语言来描述；分析人员生成系统需求，它是对用户需求的直接响应。定义问题与解决方案需要不同的组织，如果混在了一起就会混淆用户与开发人员的需求，无法区分相应的责任。非功能需求(隐性需求)也具有同样的特点。用户有非功能需求，如他们所要使用的系统的交付时间。在软件需求阶段，其它非功能需求来源于专业领域如安全、可靠性或开发标准。假想你去购买汽车，他们向你展示带有数据与控制流程的功能框图与性能特点，你会因此而购买吗？当然不会你希望他们能以你所能够理解的方式来向你介绍产品车速多快、舒适性、花销、安全性等。这些才是用户需求 。,1.需求的概念(10),“我的项目很紧，没有时间来做需求”。经验表明最快的做事方式是以恰当的方式去做不要有“如果”，不要有“但是”等意外情况发生。世上有两种类型的经理:第一类经理：相信无需需求就可以把事情做好。第二类经理：知道需求只会占用很少的资源与时间，没有需求就无从度量项目的进展。经历了一些失败的项目后，很多第一类经理都转变为第二类经理。,2.需求工作流程,SW需求实现评估,UI 设计文档与评审,测试文档与评审,开发设计文档与评审,需求库,SW 开发,发布时邮件通知：PMPlatform manager SPMUI groupTest groupSQA,跟踪和索取记录需求评估结果,1,客户需求市场要求员工建议,会议邮件,需求库,会议记录或CR,反馈需求评估结果,记录需求事件,需求评估通知,文档完成的依据,同意实现,及时记录评估结果,2,3,4,5,6,8,跟踪和检查需求的实现,9,记录实现需求,7,AMSPM需求工程师,AMSPM需求工程师,需求工程师,需求工程师,需求工程师,需求工程师,需求工程师,需求工程师,需求工程师,UI 工程师开发工程师测试工程师,SPM,需求工程师,需求工程师,参与角色,1,工作次序,图例：,需求收集阶段,需求评估阶段,需求设计阶段,需求实现与跟踪阶段,2.需求工作流程(1),3.需求管理,需求管理的好处 可以从高层需求跟踪到实现-在数据库中确立联接 评估需求变更建议的影响-分析功能使你能看到变更对其它需求的影响 对当前项目信息提供访问控制 -一个共享数据库确保所有使用者同时基于当前数据进行工作 -一个集中的存储库允许控制基于信息的访问能力 变更控制 -变更建议系统(CPS)实现管理过程的控制,3.需求管理(1),在该级别上，CMMI 对于需求管理过程域的目标是：“需求是可管理的。项目计划和产品开发间的不一致性是可以识别的。”所有产品的目标都是可以满足其责任人和客户的需求，但它也必须遵守其内部功能上和质量上的约束。需求管理过程在这一点上起到了非常重要的作用。为达到需求管理流程目标而必须建立的一系列最佳经验概括如下： 组织必须定义一组需求 组织必须管理需求的变更 组织必须确保需求被满足 组织必须确保项目计划，开发产品和需求是一致的,3.需求管理(2),4.需求的收集,DOORS,AM,需求工程师,SPM,用户,3.提交需求,2.收集需求,2.收集需求,4.需求统一录入,5.需求管理、评估与跟踪,7.需求评估,用户,6.需求核对,3.提交需求,3.提交需求,开发工程师,4.需求的收集(1),需求书写要求 正确完整明确简练可测试可追踪,4.需求的收集(2),需求书写举例： 在IDLE screen (Have events),短按OK键进入SMS（Inbox）；短按Send键进入Missed call;而Alarm, Schedule来事件提示时，将出现事件的Icon在Soft key的左上方位置（位置具体待定）。在IDLE界面出现Missed call时，弹出一个单独的提示界面（将Missed call的图标放大）；当再来一个SMS时，Missed call事件的提示被SMS提示界面覆盖，提示界面的显示方式是按事件提示的时间顺序先后来显示的。当在非IDLE界面时，来Missed call或SMS，不显示提示界面，只有返回到IDLE界面时才提示事件的界面，并且去掉Events list。,4.需求的收集(3),需求书写举例： 在IDLE screen (Have events),短按OK键进入SMS（Inbox）；短按Send键进入Missed call;Alarm, Schedule来事件提示时，将出现事件的Icon在Soft key的左上方位置（位置具体待定）。在IDLE界面出现Missed call时，弹出一个单独的提示界面（将Missed call的图标放大）；当再来一个SMS时，Missed call事件的提示被SMS提示界面覆盖，提示界面的显示方式是按事件提示的时间顺序先后来显示的。当在非IDLE界面时，来Missed call或SMS，不显示提示界面，只有返回到IDLE界面时才提示事件的界面，并且去掉Events list。,在收集过程中，一定要其用户主管者及用户全体人员参加，第一个目的是了解用户的整体需求细节，第二个目的使用户人员从各自的角度也了解到用户方要做一个什么样的系统。 如果用户需求是多人商谈，在开发方的系统分析人员进行评估前，每人也不过是计划自己的需求而已，即使有时沟通，一般也是在讨论而不是进行结论，使业务需求并不是很明确。 用户方多人在进行需求确认前，业务互相有分歧是相当正常的，开发方的系统分析人员必须要在需求评估过程，使其达成一致。一般情况下需明确以下问题:当前整体业务需求的目的要求提供的需求功能列表已经定义的需求规则将来发展的设想明确软、硬件及性能要求（容量、速度、可操作性等）用户需求的系统及用户本身或其它系统的接口要求用户的其它要求,4.需求的收集(4),5.需求的评估,考虑： 完成所需的时间 实现的成本 实现的技术难度 用户使用的友好性 细节化评估,6.需求的实现,需求开发过程将解释如何抽取责任人的需要、导出用户的需求声明，并把这些用户需求进一步分析/总结成为相应的系统需求。CMMI 对需求开发定义了以下几个目标： 组织必须能够将收集来的责任人的需求转换成用户需求 组织必须可从用户需求分析出系统需求 组织必须能够验证需求,7.需求的跟踪,ProductDescription,UserRequirement,SRS,SDS,Link,Link,Link,通过关联的方式将需求用为实现目标，将所有的开发环节链接起来。,需求的跟踪将从需求的提出时刻开始，直到产品开发结束为止。 对目前不能实现的需求还应放入预研需求中，为新产品的开发做准备。 对已被否定的需求仍需保留在需求库中，以表明当时处理的状况，而不能随意删除。,7.需求的跟踪(1),需求收集1.PD/Feature2.Schedule3.User requirement (UR),以需求为主线，联接所有的开发环节。,需求为主线的开发环节,需求评估1.可行性报告2.Schedule,需求实现1.UR2.UI Design3.SRS4.SDS5.Coding,需求验证1.Test,8.需求变更,在开发过程中，有很多问题都是由于在需求分析阶段没有正确地收集、编写、协商、修改产品真实需求而产生的，造成这样的状况有几方面的原因:1.对需求的理解分歧当客户向需求分析人员提出需求的时候往往是通过自然语言来表达的，这样的表达对于真实的需求来说是一种描述（甚至只是某个角度的描述），远远不能保证这样的描述可以得到百分之百的正确理解，也许在同客户交流的第一时刻就埋下了理解分歧的种子。一般跟分析员的知识、背景，还有客户表述的标准程度、双方的交流情况有关；2.系统实施时间过长一个大中型系统的建设可能要延续一段时间，当客户提出要求之后，他当时并不能看到系统的运行情况，当双方认为理解大概没有分歧的时候(或Deadline时)，开发方就开始工作了。当客户拿到差不多可以试用的产品时他可以实际操作，这时候他就会对系统的界面、操作、功能、性能等有一些切身的体会，有可能提出需求变更要求；,8.需求变更(1),3.客户具体情况不一当前客户的情况不一，有可能客户行业的竞争度高，需要随时作出调整和反应，那么他们自然会经常提出需求变更的要求；也有可能客户所在的行业操作不规范，本身存在很多人为因素，这时候开发方更是需要随时准备应变；4.开发本身要求开发方自身版本升级、性能改进或修正设计时出现需求变更，这些都是无法避免的问题。所以说就算分析人员和客户之间不存在理解分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务会变化或环境发生变化，这些都是无法避免的。,8.需求变更(2),应对需求变更：1.加强人员培训加强对需求分析人员的培训，尽可能增强软件系统、行业的背景知识，提高与客户的沟通能力，增强服务意识和责任感，因为将要开发的系统直接建立在需求分析的基础上。规范需求分析人员和客户沟通的方式，以及规范需求说明的格式。尽量采取用例或者用户可以理解的用例图来对需求进行标准、规范的描述，保证双方对需求达成共识。2.确定文档的有效性（Validity ）需求文档是相当重要的，应当注意文档的有效性和有用性问题，甚至对文档的格式进行一下合理性检查。,8.需求变更(3),3.建立代价估算（Cost Estimate ）概念如果出现需求变更，将不可避免将带来成本的增加、开发时间延长等不良后果，这样对双方都会产生影响。这时候需要区分需求变更的原因，对现实情况进行分析，得出双方实现变更需求所需的成本，包括时间，人力，资源等等方面，再与客户商讨是否进行变更和如何在最小代价下实现变更。当客户看到实际的代价估算，他们也会再一次慎重地考虑需求变更问题，也会更