软件文档写作02-需求分析.ppt

需求分析需求是系统的基础，陈述系统做什么，解决dowhat,而不是howtodo。功能需求：是指系统必须完成的那些事，即系统要完成用户提出的各种功能要求；
非功能需求：是指软件必须具备的品质或属性，如可靠性、性能、系统响应时间、容错、系统可扩展性等；
设计约束：一般是指客户提出的一些补充约束说明，如系统必须基于SOA设计模式、必须采用Oracle数据库、必须采用商用服务器、必须做应用服务器的负载均衡、必须采用Unix服务器等技术要求。需求分析就是分析客户的需求是什么（分析原系统功能、存在的问题以及客户对未来系统的期望），全面地理解客户的各项要求，并准确地表达所接受的客户需求。
简言之，需求分析是获取需求、表达需求和验证需求的过程，最终形成一个客户和开发人员都遵守的规约：软件需求规格说明书，在需求规格说明书中详细记录项目的目标、约束条件、功能需求、非功能需求、接口需求、开发运行环境要求等内容。原系统问卷调查
事先设计好需要提问的问题，然后形成问卷并将问卷发放给所有和系统相关的客户人员，客户人员根据自己的工作职责，以答卷的形式表达对未来系统的要求。
客户访谈
通过与客户方的项目相关人员面对面交流，直接了解到客户对系统的要求。访谈的形式可以多样化，可以是正规会议、小组讨论或电话沟通。软件需求主要包括功能需求、非功能需求和约束条件三个方面，可以采用自然语言的方式来描述，例（一个包含注册功能的网站）：
功能需求部分
注册功能：客户访问网站首页，点击注册链接，之后打开注册 页面，客户输入注册相关信息（用户名、密码、联系 方 式、……）,然后系统保存信息。
XX功能：……
非功能需求部分
性能要求：网页点击响应时间在5秒内。
可靠性：要求系统7*24小时连续运行。
……
约束条件
进度要求：从签订合同起三个月内开始试运行。
运行环境：Web服务器：Tomcat6.0；数据库：MySql5.0。
……需求表达本身没有好坏之分，只要能正确表达即可，但需求表达不是为了表达而表达，重要的在于需求文档要易于交流，与客户交流、与项目团队交流，尤其是与客户交流这一环节，自然语言表达方式不是太直观，在表达功能需求时更侧重于从系统的角度出发，不是从用户的角度出发。
20世纪60年代后期，IvarJacobson提出了“用例”的概念。20世纪80年代，他将用例引入了面向对象编程领域，填补了需求分析过程的一个空白。“用例”的另一用叫法是“用况”，都是译过来的词汇，其原文为UseCase，强调的是用户使用系统的情况，一种使用场景，所以用例法更利于用户理解，接下来我们将介绍如何基于用例法表达系统的功能需求。用例描述了系统完成动作的序列，这一序列动作对执行者产生一个有价值的可见结果。

动作序列：动作序列描述了为产生结果而进行的一系列动作，当执行者提供信息启动该用例，就激活了这些动作；
系统完成：系统为执行者服务；
有价值的可见结果：这是最重要的部分，执行者使用系统一定是为了达成什么目标，用例必须对执行者有价值；
执行者：可以是一个启动用例的个体或设备。用例建模是UML（UnifiedModelingLanguage，统一建模语言）建模的一部分，在我眼里，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求。
用例建模可分为用例图绘制和用例描述两部分，用例图由执行者（Actor）、用例（UseCase）、系统边界、箭头组成，用例描述用来详细描述用例图中每个用例，用文本文档来完成。初学者在这个地方容易走入误区，以为用例建模就是画几个图，其实不然，用例图可以帮助我们表达功能需求的全貌，但用例的根本仍然是文本描述。主执行者用例描述都有的五个必要元素：
名称：每个用例都应该有一个名字，表明执行者对系统的某种要求。通常采用动宾结构短语，简单但有描述性。
简要描述：用一两句话描述用例的用途
执行者：每个用例必须有执行者，否则该用例存在就是多余的。知道每个用例的执行者是谁可以帮助理解系统，尤其是较复杂的系统。
主成功场景：用例的核心事件流，描述执行者和系统之间的交互过程，只考虑正常使用的情况。
扩展：描述执行者和系统交互过程中一些异常情况下的处理。扩展对一个用例可以有多个。
可选元素：
前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件。
后置条件：用例一旦执行后系统所处的状态
项目相关人利益：除执行者外其他关联人的利益。1、集中讨论，并列出主执行者
在系统整个生命周期，找出每个人或非人的主执行者

2、集中讨论，并尽可能列出系统所有的用户目标
产生初始的执行者-目标列表

3、捕获系统目标用例
筛选出系统目标用例，产生用例简述4、捕获项目相关人员和利益、前提条件和保证

5、编写主成功场景
用3-9个步骤

6、集中讨论，并列出所有可能