2-1-需求分析

,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,第,2,章,可行性分析,&,需求分析,复习,瀑布模型,原型开发模型,增量模型,螺旋模型,可行性分析,可行性研究的,输入,信息是系统的一个,框架描述,和,系统将如何在机构中使用,的说明信息，可行性研究的,结果,应该是给出一份报告，对需求工程和系统开发过程,是否值得开发,给出具体的意见和建议。,一个可行性研究过程较短，集中在,回答以下几个问题,：,1,系统是否符合机构的总体目标？,2,系统是否可能在现有的技术条件、预算和时间限制内完成？,3,系统能否和已经存在的其它系统集成？,可行性分析,可行性研究的目的,是,用最小的代价在尽可能短的时间内确定问题是否能够解决,。,经济可行性,技术可行性,运行可行性,法律可行性,开发方案可行性,可行性研究的步骤：,1),复查系统规格和目标,2),对于现行系统进行分析研究,3),导出新系统的高层逻辑模型,4),重新定义问题,5),导出和评价供选择的,方案,6),推荐一个方案并说明理由,7),推荐行动方针,8),书写计划任务书（系统概述、可行性分析、拟定开发计划、结论意见）,9),提交审查,可行性研究报告,1,引言,1.1,编写目的,1.2,背景,1.3,定义,1.4,参考资料,2,可行性研究的前提,2.1,要求,2.2,目标,2.3,条件、假定和限制,2.4,进行可行性研究的方法,2.5,评价尺度,3,对现有系统的分析,3.1,处理流程和数据流程,3.2,工作负荷,3.3,费用开支,3.4,人员,3.5,设备,3.6,局限性,可行性研究报告,4,所建议的系统,4.1,对所建议系统的说明,4.2,处理流程和数据流程,4.3,改进之处,4.4,影响,4.4.1,对设备的影响,4.4.2,对软件的影响,4.4.3,对用户单位机构的影响,4.4.4,对系统运行过程的影响,4.4.5,对开发的影响,4.4.6,对地点和设施的影响,4.4.7,对经费开支的影响,4.5,局限性,4.6,技术条件方面的可行性,5,可选择的其他系统方案,5.1,可选择的系统方案,1,5.2,可选择的系统方案,2,可行性研究报告（续）,6,投资及效益分析,6.1,支出,6.1.1,基本建设投资,6.1.2,其他一次性支出,6.1.3,非一次性支出,6.2,收益,6.2.1,一次性收益,6.2.2,非一次性收益,6.2.3,不可定量的收益,6.3,收益投资比,6.4,投资回收周期,6.5,敏感性分析,7,社会因素方面的可行性,7.1,法律方面的可行性,7.2,使用方面的可行性,8,结论,需求分析,需求分析概念,需求分析过程,需求分析方法,需求分析产品,软件需求的定义,客户定义的,“,需求,”,vs.,开发者所说的,“,需求,”,软件需求包含多个层次，不同层次的需求从不同角度与不同程度反映着细节问题。,IEEE,软件工程术语（,1997,）的需求定义：,（,1,）用户解决问题或达到目标所需的条件或能力。,（,2,）系统或系统部件要满足合同、标准、规范或其它正式强制性文件所需具有的条件或能力。,（,3,）反映上面（,1,）或（,2,）所描述的条件或能力的文档说明。,上述定义包括从用户（外部）、从开发者（内部）角度来阐述需求。,需求的层次,业务需求（,business requirement,）：反映组织机构或客户对系统、产品高层次的目标要求。,用户需求（,user requirement,）：描述用户使用产品必须要完成的任务。,功能需求（,functional requirement,）：定义开发人员必须实现的软件功能。,需求规格说明中还包括,非功能需求,。,软件需求各组成部分之间关系,业务需求,用户需求,功能需求,系统需求,质量属性,其它非功能需求,约束条件,项目视图与范围文件,使用实例文档,软件需求规格说明,需求管理的困难性,不成熟的需求分析,无足够用户参与,用户需求的不断增加,摸棱两可的需求,不必要的特征（镀金）,过于精简的规格说明,忽略了用户分类,不准确的计划,高质量需求过程的获益,开发后期和整个维护阶段的重做的工作大大减少,Barry W.Boehm,发现可以节省成本,68,倍,有研究认为可以节省成本,200,倍,忠实的客户关系,采用系统方法将需求分配到各子系统可以简化集成,有效的变更控制和影响分析能降低变更的负面影响,清晰、无二义的需求文档有利于测试,谁是客户,定制软件：合同甲方（提出方）,通用软件：高层管理者和（或）市场部,嵌入式软件：软件所属计算机系统,客户的权利,1,要求分析人员使用符合客户语言习惯的表达,2,要求分析人员了解客户的业务及目标,3,要求分析人员编写软件需求规格说明,4,要求得到需求工作结果的解释说明,5,要求开发人员尊重你的意见,6,要求开发人员对需求及产品实施提供建议,7,描述产品易使用的特性,8,调整需求，允许重用已有的软件组件,9,要求对变更的代价提供真实可信的评估,10,获得满足客户功能和质量要求的系统,客户的义务,1,给分析人员讲解你的业务,2,抽出时间清楚地说明并完善需求,3,准确而详细地说明需求,4,及时地作出决定,5,尊重开发人员的需求可行性及成本评估,6,划分需求优先级别,7,评审需求文档和原型,8,需求出现变更要马上联系,9,应遵守开发机构处理需求变更的过程,10,尊重开发人员采用的需求工程过程,对签定需求协议的认识,签约是客户同意需求的标志行为,客户不应当忽略签约的严肃性,开发方不应当因此拒绝变更,签约应当建立在一个需求协议的基线上,应当理解为：,“,我同意这份文档表达了目前我们对项目软件需求的了解。进一步的变更可在此基础上通过项目定义的变更过程来进行。我知道变更可能会使我们要重新协商成本、资源和项目时间工期任务等。,”,需求开发过程,需求获取,需求分析,编写需求规格说明,需求验证,知识培训,需求管理,项目管理,需求获取的内容,在同用户的交流过程中收集各种用户的信息,认真理解用户的各项要求,澄清模糊,排除不合理,明确约束,分析人员的两个信条,第一：只有在,彻底了解和掌握,了用户的全部意图之后，才有可能建立起成功的软件系统。,第二：,一切从用户的角度着想,，在条件允许的情况下，应尽可能地保证用户从所构造的软件系统中获得最大的利益。,容易产生的问题,交流障碍,误解,各方缺乏共同的语言,“,完整性,”,问题,需求永远会变化,用户本身的意见不一致,错误的要求,认识上混淆目标和需求,工作流程,用户,调查,具体模型,逻辑,抽象,当前系统,逻辑模型,当前系统,计算,机化,评审,修改,正式模型,完善,细节,目标系统,目标系统,初始模型,经认可的,问题需求,系统模型,用户,建立模型的步骤,分析现有系统和过程，建立,物理模型,抽取特征，建立旧系统的,逻辑模型,根据新的要求，补充和建立新的,逻辑模型,需求分析的任务,需求分析的内容,提炼、分析和仔细审查已收集到的需求,确保所有利益相关者都明白其含义并找出其中的错误、遗漏或其它不足的地方,是从用户最初的非形式化需求到满足用户要求的软件产品的映射过程,是对用户意图不断进行提示和判断的过程,需求分析的步骤,绘制系统关联图,创建用户接口（界面）原型,分析需求可行性,确定需求的优先级别,为需求建立,模型,创建,数据字典,使用质量功能调配（,QFD,）,明确哪些是客户最关心的特征,编制需求规格说明的过程,采用软件需求规格说明（,SRS,）模版,指明需求的来源,为每项需求注上标号,记录业务规范（操作原则）,创建需求跟踪矩阵,需求规格说明的作用,为用户、分析人员和设计人员之间的交流提供方便,支持目标软件系统的确认,控制软件开发进程,软件需求规格说明文档条目,1,引言,1.1,系统参考文献,1.2,整体描述,1.3,软件项目约束,2,信息描述,2.1,信息内容,2.2,信息流,2.2.1,数据流,2.2.2,控制流,3,功能描述,3.1,功能描述,3.2.1,处理说明,3.2.2,限制,3.2.3,性能需求,3.2.4,设计约束,3.2.5,支撑图,3.2,控制描述,3.2.1,控制规格说明书,3.2.2,设计约束,4,行为描述,4.1,系统状态,4.2,事件和动作,5,确认标准,5.1,性能范围,5.2,测试种类,5.3,预期的软件响应,5.4,特殊考虑,6,参考书目,7,附录,软件需求规格说明文档条目,软件需求必须包括的属性,1,）标识,2,）需要,3,）优先级,4,）稳定性,5,）源,6,）清晰性,7,）验证性,IEEE,需求规格说明的编写,8,原则,1,从实际重分离功能，描述,“,做什么,”,不描述,“,怎么做,”,2,要求有一个面向处理的软件系统规格说明语言，以描述软件系统的,动态行为,3,必须对,以该软件为元素的系统,进行说明，以描述清楚之间的,关系,4,必须对软件系统的,运行环境,进行说明，以保持接口描述的一致性,5,必须是,认识的模型,而不是实际的模型,6,必须是,可操作,的,7,必须,容忍不完备性,和,可修改性,8,必须,局部化,和,松散耦合,，使得变化时只修改一个片段,需求表达,需求说明语句,保持语句和段落的,简短,采用,主动语态,的表达方式,编写具有正确的语法和标点的,完整句子,使用的术语应该和词汇表中定义的,一致,需求陈述应该具有一致的式样，例如,“,系统必须,”,，或者,“,用户必须,”,，并紧跟一个行为动作和可观察的结果，例如,“,仓库管理子系统必须现实一张在所请求的仓库中有存货的药品名单。,”,需求表达,为了减少不确定性，避免采用模糊的、主观的术语，例如，,用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的,。,避免使用比较性的词汇，例如：,提高，最大化，最小化和最佳化,。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。,eg.,任务管理器需求表达,“,应用程序页面必须在固定的时间间隔内提供程序状态消息，并且每次时间间隔不得大于,1,秒,”,应用程序页面应该在用户界面的指定区域显示状态消息,在后台任务进程启动之后，消息必须每隔,1,秒更新一次，并且保持连续的可见性。,如果正在正常处理后台任务进程，那么后台任务管理器必须显示后台任务进程已完成的百分比,当程序运行时，后台任务管理器必须显示一个,“,正在运行,”,的消息。,如果后台任务中止执行，那么后台任务管理器必须显示一个出错信息。,知识培训,培训需求分析人员,培训软件需求的用户代表和管理人员,让开发人员了解应用领域的基本概念,编写项目术语汇编,分析员的职责,）作为管理员、用户和顾客的顾问；,）从各种来源收集数据，并综合问题的解答；,）分析新的系统，并评价现有的系统；,）准备文档和管理报告；,）理解硬件和软件的界面；,）为了产生软件需求规格说明，必要时要进行一些研究工作；,）为编写软件需求规格说明主持座谈会；,）不断吸收先进技术。,分析员的素质,）能够合乎逻辑地、象征性地、抽象地、创造性地思考问题；,）能作为小组中的一个成员很好地开展工作；,）熟悉计算机硬件和软件的能力；,）自觉遵守时间，能按规定的进度完成任务；,）在系统的分析和设计中能发挥其他人的作用；,）能保持教师和学生的双重身份；,）能够倾听别人的意见，但又能根据客观事实来作决策，而,不是依赖别人的意见,；,）熟悉商业和政策管理部门的组织、原则。,分析员应该显示的性格特征,1,）善于领会一些抽象的概念，重新整理使之成为各种逻辑成分，并根据各种逻辑成分综合出问题的解决办法。,2,）善于从各种相应冲突或混淆的原始资料中汲取恰当的依据。,3,）能够理解用户,需求者的环境。,4,）具备把系统的硬件部分和（或）软件部分应用于用户,需求者环境的能力。,5,）具备良好的用书面或口头形式进行讨论及交换意见的能力。,6,）具有,“,既能看到树木，又能看到森林,”,的能力。,需求管理,确定需求变更控制过程,建立变更控制委员会（,CCB,）,进行需求变更影响分析,跟踪所有受需求变更影响的工作产品,建立需求基准版