《软件文档写作02-需求分析课件》由会员分享，可在线阅读，更多相关《软件文档写作02-需求分析课件（30页珍藏版）》请在金锄头文库上搜索。
1、需求分析,需求是系统的基础，陈述系统做什么，解决do what,而不是how to do。,何谓需求？,功能需求：是指系统必须完成的那些事，即系统要完成用户提出的各种功能要求； 非功能需求：是指软件必须具备的品质或属性，如可靠性、性能、系统响应时间、容错、系统可扩展性等； 设计约束：一般是指客户提出的一些补充约束说明，如系统必须基于SOA设计模式、必须采用Oracle数据库、必须采用商用服务器、必须做应用服务器的负载均衡、必须采用Unix服务器等技术要求。,需求包含哪些内容？,需求分析就是分析客户的需求是什么（分析原系统功能、存在的问题以及客户对未来系统的期望），全面地理解客户的各项要求，并准
2、确地表达所接受的客户需求。 简言之，需求分析是获取需求、表达需求和验证需求的过程，最终形成一个客户和开发人员都遵守的规约：软件需求规格说明书，在需求规格说明书中详细记录项目的目标、约束条件、功能需求、非功能需求、接口需求、开发运行环境要求等内容。,什么是需求分析？,原系统,存在问题,客户期望,需求规 格说明,需求 分析,输入,处理,输出,需求分析输入输出,问卷调查 事先设计好需要提问的问题，然后形成问卷并将 问卷发放给所有和系统相关的客户人员，客户人员根据自己的工作职责，以答卷的形式表达对未来系统的要求。 客户访谈 通过与客户方的项目相关人员面对面交流，直接了解到客户对系统的要求。访谈的形式可
3、以多样化，可以是正规会议、小组讨论或电话沟通。,获取需求方式,软件需求主要包括功能需求、非功能需求和约束条件三个方面，可以采用自然语言的方式来描述，例（一个包含注册功能的网站）： 功能需求部分 注册功能：客户访问网站首页，点击注册链接，之后打开注册页面，客户输入注册相关信息（用户名、密码、联系方式、）,然后系统保存信息。 X能： 非功能需求部分 性能要求：网页点击响应时间在5秒内。 可靠性：要求系统7*24小时连续运行。 约束条件 进度要求：从签订合同起三个月内开始试运行。 运行环境：Web服务器：Tomcat 6.0；数据库：MySql 5.0。 ,表达需求方式自然语言,需求表达本身没有好坏
4、之分，只要能正确表达即可，但需求表达不是为了表达而表达，重要的在于需求文档要易于交流，与客户交流、与项目团队交流，尤其是与客户交流这一环节，自然语言表达方式不是太直观，在表达功能需求时更侧重于从系统的角度出发，不是从用户的角度出发。 20世纪60年代后期，Ivar Jacobson提出了“用例”的概念。20世纪80年代，他将用例引入了面向对象编程领域，填补了需求分析过程的一个空白。“用例”的另一用叫法是“用况”，都是译过来的词汇，其原文为Use Case，强调的是用户使用系统的情况，一种使用场景，所以用例法更利于用户理解，接下来我们将介绍如何基于用例法表达系统的功能需求。,表达需求方式用例模型
5、,用例描述了系统完成动作的序列，这一序列动作对执行者产生一个有价值的可见结果。 动作序列：动作序列描述了为产生结果而进行的一系列动作，当执行者提供信息启动该用例，就激活了这些动作； 系统完成：系统为执行者服务； 有价值的可见结果：这是最重要的部分，执行者使用系统一定是为了达成什么目标，用例必须对执行者有价值； 执行者：可以是一个启动用例的个体或设备。,用例是什么？,用例建模是UML（Unified Modeling Language，统一建模语言）建模的一部分，在我眼里，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求。 用例建模可分为用例图绘制和用例描述两部分，用
6、例图由执行者（Actor）、用例（Use Case）、系统边界、箭头组成，用例描述用来详细描述用例图中每个用例，用文本文档来完成。初学者在这个地方容易走入误区，以为用例建模就是画几个图，其实不然，用例图可以帮助我们表达功能需求的全貌，但用例的根本仍然是文本描述。,用例建模,主执行者,系统边界,用例,箭头,执行者：不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色 。 用例 ：用例是执行者想要系统做的事情。 系统边界 ：是用来表示正在建模系统的边界 。 箭头：用来表示执行者和系统通过相互发送信号或消息进行交互的关联关系。,用例图,用例描述都有的五个必要元素： 名称：每个用例都应该有
7、一个名字，表明执行者对系统的某种要求。通常采用动宾结构短语，简单但有描述性 。 简要描述：用一两句话描述用例的用途 执行者：每个用例必须有执行者，否则该用例存在就是多余的。知道每个用例的执行者是谁可以帮助理解系统，尤其是较复杂的系统 。 主成功场景：用例的核心事件流，描述执行者和系统之间的交互过程，只考虑正常使用的情况 。 扩展：描述执行者和系统交互过程中一些异常情况下的处理。扩展对一个用例可以有多个 。,用例描述,可选元素： 前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件。 后置条件：用例一旦执行后系统所处的状态 项目相关人利益：除执行者外其他关联人的利益 。,用例描述,1、集
8、中讨论，并列出主执行者 在系统整个生命周期，找出每个人或非人的主执行者 2、集中讨论，并尽可能列出系统所有的用户目标 产生初始的执行者-目标列表 3、捕获系统目标用例 筛选出系统目标用例，产生用例简述,用例建模过程,4、捕获项目相关人员和利益、前提条件和保证 5、编写主成功场景 用3-9个步骤 6、集中讨论，并列出所有可能的扩展条件 包括系统所能检测到并且必须处理的所有条件 7、编写扩展处理步骤 8、重新调整用例集：进行必要的增减、合并,用例建模过程,列出主执行者,步骤1,谁将使用系统的主要功能？ 谁需要借助系统的支持来完成日常工作？ 谁来维护和管理系统？ 系统控制那些硬件设备？ 系统需要与哪
9、些其他系统交互？ 哪些人或系统对本系统产生的结果感兴趣？,列出主执行者目标,步骤2,行为者需要系统提供哪些功能？ 行为者是否需要维护系统中的某类信息？ 系统中发生的事件需要通知行为者吗？行为者需要通知系统某件事情吗？,执行者,目标,执行者-目标列表（利于整体把握系统功能）,图书管理员,登记新书,统计图书借出情况,学生,查询新书,用例简述,步骤3,执行者,目标,用例简述（利于初步估计工作复杂度）,图书管理员,登记新书,统计图书借出情况,学生,查询新书,简述,图书管理员收到新到图书后，将新书的信息登记到图书系统。,捕获用例的项目相关人员利益、前置条件和后置条件,步骤4,编写主成功场景,步骤5,描述
10、成功场景的活动序列。描述成功场景的活动序列，一般用3-9个步骤，不易过多，如果多于10个步骤，可考虑将用例进行拆分。编写用例文本尽可能简练、目的明确。,句子的结构应该非常简单： 主语谓语动词直接宾语 例如： 系统从账户余额中扣除100元。,准则1：使用简单的语法,每一个步骤中，一个执行者“控制球”，这个执行者就是句子的主语。,准则2：明确地写出“谁控制球”,“系统读取ATM卡和PIN号码，并从帐号余额中扣除一定数量” - 系统内部的角度 应改为： “用户插入ATM卡并输入PIN号码” “系统从帐号余额中扣除一定数量”,准则3：从系统外部描述系统,修改前： 1）系统要求用户输入名字 2）用户输入
11、名字 3）系统要求用户输入地址 4）用户输入地址 5）用户点击“确定” 6）系统. 修改后： 1）用户输入名字和地址 2）系统,准则4：显示执行者的意图而不是动作,修改前： 1）系统检查密码是否正确 2）如果密码正确，系统 修改后： 1）系统确认密码正确。 2）系统,准则5：“确认”而不是“检查与否”,1）顾客提供帐号或者名字和地址 2）系统查出顾客的爱好信息 3）用户选择一个商品，并做上购买的标记 4）系统将这个商品加入到顾客的“购物车”中 顾客重复步骤3-4，直到顾客指明完成了选购 5）顾客购买所有在购物车中的商品,准则6：循环表达“循环执行步骤x到y，直到条件满足”,用例范例,【用例名称
12、】 登记新书 【主执行者】 图书管理员 【前置条件】 已经登录到系统,【主成功场景】 1.图书管理员选择新书登记功能 2.系统显示新书登记界面 3.图书管理员录入书号、书名、出版社、出版时间、作者、数量，并点击保存 4.系统保存新书信息，并刷新界面显示所有新书信息 系统管理员重复执行步骤1-4，直到登记完所有新书 【扩展】,集中讨论所有扩展条件,步骤6,集中讨论主成功场景中的步骤，找出所有可能发生的失败或可选择的过程。,编写扩展步骤,步骤7,【扩展】 2a. 扩展条件 2a1.步骤. 2a2.步骤.,用例范例,【用例名称】 登记新书 【主执行者】 图书管理员 【前置条件】 已经登录到系统,【主成功场景】 1.图书管理员选择新书登记功能 2.系统显示新书登记界面 3.图书管理员录入书号、书名、 出版社、出版时间、作者、数量，并点击保存 4.系统保存新书信息，并刷新界面显示所有新书信息 重复执行步骤1-4，直到登记完所有新书 【扩展】 4a.系统已经包含新书的信息 4a1.系统提示新书信息重复 4a2.跳转到步骤2,
