软件工程之需求分析报告.docx

1、软件工程之需求分析报告软件工程之需求分析一、综述软件工程中包含需求、设计、编码和测试四个阶段 , 其中需求工程是软件工程第一个也是很 重要的一个阶段，本文以医院管理系统为例详细介绍了需求工程的构成和进行方法。首先我们必须了解需求工程和其他项目过程的关系：图 1 需求与其他项目过程的关系软件需求包括三个不同的层次 -业务需求、用户需求和功能需求 - 也包括非功能需求 :业务需说明了提供给客户和产品开发商的新系统的最初利益 , 反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与围文档中予以说明 ; 用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以

2、说明 ; 功能需求定义了开发人员必须实现 的软件功能，使得用户能完成他们的任务，从而满足了业务需求。需求工程分为了需求开发和需求管理两个阶段 : 下面就以这两个阶段说明 :一 , 需求开发需求开发又分为需求获取、 需求分析、 编写规格说明书和需求验证。 以下列出和讲解分析常 规的步骤，当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤。1 需求获取：1）确定需求开发过程：确定需求开发过程确定如何组织需求的收集、分析、 细化并核实的 步骤，并将它编写成文档。对重要的步骤要给予一定指导， 这将有助于分析人员的工作，而且也 使收集需求活动的安排和进度计划更容易进行。2）编写项目视图和围文

3、档： 项目视图和围文档应该包括高层的产品业务目标， 所有的使用 实例和功能需求都必须遵从能达到的业务需求。 项目视图说明使所有项目参与者对项目的目标能 达成共识。而围则是作为评估需求或潜在特性的参考。表 1 项目视图和围文档的模板a.1 背景 在这一部分，总结新产品的理论基础，并提供关于产品开发的历史背景或形势的 一般性描述。a.2 业务机遇 描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系 统将运用的环境。 包括对现存产品的一个简要的相对评价和解决方案， 并指出所建议的产品为什 么具有吸引力和它们所能带来的竞争优势。a.3 业务目标 用一个定量和可测量的合理方法总结产品所带

4、来的重要商业利润 , 把重点放 在给业务的价值上。a.4 客户或市场需求 描述一些典型客户的需求，包括不满足现有市场上的产品或信息系统 的需求。提出客户目前所遇到的问题在新产品中将可能 （或不可能）出现的阐述， 提供客户怎样 使用产品的例子。 确定了产品所能运行的软、 硬件平台。 a.5 提供给客户的价值 确定产品 给客户带来的价值，并指明产品怎样满足客户的需要。a.6 业务风险 总结开发（或不开发）该产品有关的主要业务风险，例如市场竞争、时间问 题、用户的接受能力、实现的问题或对业务可能带来的消极影响。 预测风险的严重性， 指明你所 能采取的减轻风险的措施。b.1 项目视图述 编写一个总结长

5、远目标和有关开发新产品目的的简要项目视图述。项目视 图述将考虑权衡有不同需求客户的看法。 它可能有点理想化， 但必须以现有的或所期待的客户市 场、企业框架、组织的战略方向和资源局限性为基础。b.2 主要特性 包括新产品将提供的主要特性和用户性能的列表。强调的是区别于以往产品 和竞争产品的特性。可以从用户需求和功能需求中得到这些特性。b.3 假设和依赖环境 在构思项目和编写项目视图和围文档时，要记录所作出的任何假设。 通常一方所持的假设应与另一方不同。c.1 首次发行的围 总结首次发行的产品所具有的性能。描述了产品的质量特性，这些特性 使产品可以为不同的客户群提供预期的成果。 c.2 随后发行的

6、围 如果你想象一个周期性的 产品演变过程，就要指明哪一个主要特性的开发将被延期，并期待随后版本发行的日期。c.3 局限性和专用性 明确定义包括和不包括的特性和功能的界线是处理围设定和客户期望 的一个途径。列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。d.1 客户概貌 客户概述明确了这一产品的不同类型客户的一些本质的特点，以及目标市场 部门和在这些部门中的不同客户的特征。d.2 项目的优先级 一旦明确建立项目的优先级，风险承担者和项目的参与者就能把精力集 中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面：性能、质量、 计划、成本和人员。 e. 产品成功的因

7、素 明确产品的成功是如何定义和测量的，并指明对 产品的成功有巨大影响的几个因素。不仅要包括组织直接控制的围的事务，还要包括外部因素。 如果可能，可建立测量的标准用于评价是否达到业务目标 .3）用户群分类：产品的用户在很多方面存在着差异，例如：用户使用产品的频度、他们的 应用领域和计算机系统知识、 他们所使用的产品特性、 他们所进行的业务过程、 他们在地理上的 布局以及他们的访问优先级。 根据这些差异， 你可以把这些不同的用户分成小组。 用户类不一定 都指人， 你可以把其它应用程序或系统接口所用的硬件组件也看成是附加用户类的成员。 以这种方式来看待应用程序接口， 可以帮助你确定产品中那些与外部应

8、用程序或组件有关的需求。 将用 户群分类并归纳各自特点为避免出现疏忽某一用户群需求的情况， 要将可能使都有所差异。 详细 描述出它们的个性特点及任务状况，将有助于产品设计。4）选择产品代表：择每类用户的产品代表为每类用户至少选择一位能真正代表他们需求的 人作为那一类用户的代表并能作出决策。 这对于部信息系统的开发是最易实现的， 因为此时， 用 户就是身边的职员。 而对于商业开发， 就得在主要的客户或测试者中建立起良好的合作关系， 并 确定合适的产品代表。 他们必须一直参与项目的开发而且有权作出决策。 每一个产品代表者代表 了一个特定的用户类，并在那个用户类和开发者之间充当主要的接口。5）建立核

9、心队伍：建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表 召集起来， 从他们那里收集目前产品的功能需求和非功能需求。 这样的核心队伍对于商业开发尤 为有用， 因为你拥有一个庞大且多样的客户基础。 与产品代表的区别在于， 核心队伍成员通常没 有决定权。6）确定使用实例：让用户代表确定使用实例从用户代表处收集他们使用软件完成所需任务 的描述 - 使用实例，讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用 标准模版，在使用实例基础上可得到功能需求。一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序。 因此， 一个使用实例是相关的用法说明的集合， 并且一

10、个说明是使用实例的例子。 在描述时列出执行者和系统 之间相互交互或对话的顺序。当这种对话结束时，执行者也达到了预期的目的。对于一些复杂的使用实例， 画出图形分析模型是有益的， 这些模型包括数据流程图、 实体关 系图、状态转化图、对象类和联系图。使用实例的描述并不向开发者提供他们所要开发的功能的细节。 为了减少这种不确定性， 你 需要把每一个使用实例叙述成详细的功能需求。 每一个使用实例可引伸出多个功能需求， 这将使 执行者可以执行相关的任务； 并且多个使用实例可能需要相同的功能需求。 使用实例方法给需求 获取带来的好处来自于该方法是以任务为中心和以用户为中心的观点。 比起使用以功能为中心的 方

11、法，使用实例方法可以使用户更清楚地认识到新系统允许他们做什么。每一个使用实例都描述了一个方法， 用户可以利用这个方法与系统进行交互， 从而达到特定 的目标。 使用实例可有效地捕捉大多数所期望的系统行为， 但是你可能有一些需求， 这些需求与 用户任务或其他执行者之间的交互没有特定的关系。这时你就需要一个独立的需求规格说明。7）召开应用程序开发联系会议：召开应用程序开发联系会议应用程序开发联系会议是围广 的、简便的专题讨论会， 也是分析人员与客户代表之间一种很好的合作办法， 并能由此拟出需求 文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实 践。8）分析用户工作流

12、程：分析用户工作流程观察用户执行业务任务的过程。画一简单的示意 图（最好用数据流图）来描绘出用户什么时候获得什么数据，并怎样使用这些数据。编制业务过 程流程文档将有助于明确产品的使用实例和功能需求。 你甚至可能发现客户并不真地需要一个全 新的软件系统就能达到他们的业务目标。9）确定质量属性：确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质 量特点， 这会使你的产品达到并超过客户的期望。 对系统如何能很好地执行某些行为或让用户采 取某一措施的述就是质量属性，这是一种非功能需求。听取那些描述合理特性的意见： 快捷、 简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性。你将要和用户

13、一起商讨精确定义他 们模糊的和主观言辞的真正含义。10 ）检查问题报告： 通过检查当前系统的问题报告来进一步完善需求客户的问题报告及补充 需求为新产品或新版本提供了大量丰富的改进及增加特性的想法， 负责提供用户支持及帮助的人 能为收集需求过程提供极有价值的信息。11 ）需求重用： 跨项目重用需求如果客户要求的功能与已有的产品很相似， 则可查看需否有足够的灵活性以允许重用一些已有的软件组件。2 需求分析1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模 型。同时它也明确了通过接口的信息流和物质流。2）创建开发原型：创建用户接口原型当开发人员或用户不能确定需求时，开发

14、一个用户接 口原型， 这样使得许多概念和可能发生的事更为直观明了。 用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。3）分析可行性：分析需求可行性在允许的成本、性能要求下，分析每项需施的可行性，明 确与每项需现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。4）确定需求优先级：确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项 需现的优先级别。 以优先级为基础确定产品版本将包括哪些特性或哪类需求。 当允许需求变更时， 在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。5）为需求建立模型：为需求建立

15、模型需求的图形分析模型是软件需求规格说明极好的补充 说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。 这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。6）编写数据字典：创建数据字典数据字典是对系统用到的所有数据项和结构的定义，以确 保开发人员使用统一的数据定义。 在需求阶段， 数据字典至少应定义客户数据项以确保客户与开 发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。7）应用质量功能调配：使用质量功能调配质量功能调配是一种高级系统技术，它将产品特 性、属性与对客户的重要性联系起来。 该技术提供了一种分析方法以明

16、确那些是客户最为关注的 特性。它将需求分为三类：期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意； 普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。3 编写规格说明书 项目视图和围文档包含了业务需求， 而使用实例文档则包含了用户需求。 你必须编写从使用 实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属性和外部接口需求。 软件需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件 , 它不仅是系统测试和用户文档的基础， 也是所有子系列项目规划、 设计和编码的基础。 它应该尽可能完 整地描述系统预期的外部行为和用户可视化行为。

17、除了设计和实现上的限制， 软件需求规格说明 不应该包括设计、构造、测试或工程管理的细节。1）采用软件需求规格说明模版 : 采用需求规格说明书模板在你的组织中要为编写软件需求 文档定义一种标准模板。 该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的 结构。注意， 其目的并非是创建一种全新的模板， 而是采用一种已有的且可满足项目需要并适合 项目特点的模板。许多组织一开始都采用 IEEE 标准 830-1998（IEEE 1998） 描述的需求规格说明书模板。要相信模板是很有用的，但有时要根据项目特点进行适当的改动。a.引言引言提出了对软件需求规格说明的纵览， 这有助于读者理解文档如何

18、编写并且如何阅读和 解释。a . 1 目的 对产品进行定义，在该文档中详尽说明了这个产品的软件需求，包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系， 那么就只定义文档中说明的部分或子 系统。a.2 文档约定 描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。a.3 预期的读者和阅读建议 列举了软件需求规格说明所针对的不同读者， 例如开发人员、 项目经理、 营销人员、 用户、 测试人员或文档的编写人员。 描述了文档中剩余部分的容及其组织结构。 提出了最适合于每一类 型读者阅读文档的建议。a.4 产品的围 提供了对指定的软件及其目的的简短描述， 包括利

19、益和目标。 把软件与企业目标或业务策 略相联系。可以参考项目视图和围文档而不是将其容复制到这里。a.5 参考文献 列举了编写软件需求规格说明时所参考的资料或其它资源。这可能包括用户界面风格指 导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。b.综合描述这一部分概述了正在定义的产品以及它所运行的环境、 使用产品的用户和已知的限制、 假 设和依赖。b.1 产品的前景描述了软件需求规格说明中所定义的产品的背景和起源。 说明了该产品是否是产品系列中 的下一成员， 是否是成熟产品所改进的下一代产品、 是否是现有应用程序的替代品， 或者是否是 一个新型的、自含型产品。b.2

20、产品的功能 概述了产品所具有的主要功能。其详细容将在 d 中描述，所以在此只需要概略地总结。很好地组织产品的功能，使每个读者都易于理解。b.3 用户类和特征 确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。 有一些需求可能只与特 定的用户类相关。b.4 运行环境 描述了软件的运行环境， 包括硬件平台、 操作系统和版本， 还有其它的软件组件或与其共 存的应用程序。b.5 设计和实现上的限制 确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。b.6 假设和依赖 列举出在对软件需求规格说明中影响需求述的假设因素 （与已知因素相对立） 。这可能包括 你打算要用的商业组件或有关

21、开发或运行环境的问题。 你可能认为产品将符合一个特殊的用户界 面设计约定，但是另一个 S R S 读者却可能不这样认为。如果这些假设不正确、不一致或被更 改，就会使项目受到影响。此外， 确定项目对外部因素存在的依赖。 例如， 如果你打算把其它项目开发的组件集成到系 统中，那么你就要依赖那个项目按时提供正确的操作组件。 如果这些依赖已经记录到其它文档 （ 例 如项目计划 ） 中了，那么在此就可以参考其它文档。c.外部接口需求利用本节来确定可以保证新产品与外部组件正确连接的需求。 关联图表示了高层抽象的外部 接。需要把对接口数据和控制组件的详细描述写入数据字典中。 如果产品的不同部分有不同的外 部

22、接口，那么应把这些外部接口的详细需求并入到这一部分的实例中。 c.1 用户界面述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。而对于用户界面的细节， 例如特定对话框的布局， 应该写入一个独立的用户界面规格说明中， 而不能写入软件需求规格说 明中。c.2 硬件接口描述系统中软件和硬件每一接口的特征。 这种描述可能包括支持的硬件类型、 软硬件之间 交流的数据和控制信息的性质以及所使用的通信协议。c.3 软件接口描述该产品与其它外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工具、 库和集成的商业组件。 明确并描述在软件组件之间交换数据或消息的目的。 描述所需要的服务以 及部组件

23、通信的性质。确定将在组件之间共享的数据。c.4 通信接口描述与产品所使用的通信功能相关的需求，包括电子、 We b 浏览器、网络通信标准或协议 及电子表格等等。 定义了相关的消息格式。 规定通信安全或加密问题、 数据传输速率和同步通信 机制。d.系统特性d.1 说明和优先级提出了对该系统特性的简短说明并指出该特性的优先级是高、 中， 还是低。 或者你还可以包 括对特定优先级部分的评价，例如利益、损失、费用和风险，其相对优先等级可以从 1（低）到9 （高）。d.2 激励 / 响应序列列出输入激励 （用户动作、 来自外部设备的信号或其它触发器） 和定义这一特性行为的系统 响应序列。这些序列将与使用

24、实例相关的对话元素相对应。d.3 功能需求详列出与该特性相关的详细功能需求。 这些是必须提交给用户的软件功能， 使用户可以使用 所提供的特性执行服务或者使用所指定的使用实例执行任务。 描述产品如何响应可预知的出错条 件或者非法输入或动作。就像本章开头所描述的那样，你必须唯一地标识每个需求。e.其它非功能需求这部分列举出了所有非功能需求， 如产品的易用程度如何， 执行速度如何， 可靠性如何， 当 发生异常情况时，系统如何处理，而不是外部接口需求和限制。e.1 性能需求阐述了不同的应用领域对产品性能的需求， 并解释它们的原理以帮助开发人员作出合理的设 计选择。 确定相互合作的用户数或者所支持的操作

25、、 响应时间以及与实时系统的时间关系。 你还 可以在这里定义容量需求， 例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。 尽 可能详细地确定性能需求。 可能需要针对每个功能需求或特性分别述其性能需求， 而不是把它们 都集中在一起述。e.2 安全设施需求详尽述与产品使用过程中可能发生的损失、 破坏或危害相关的需求。 定义必须采取的安全保护或动作，还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或规则。e.3 安全性需求详尽述与系统安全性、 完整性或与私人问题相关的需求， 这些问题将会影响到产品的使用和 产品所创建或使用的数据的保护。 定义用户身份确认或授权需求。 明确产品

26、必须满足的安全性或 性策略。e.4 软件质量属性详尽述与客户或开发人员至关重要的其它产品质量特性。 这些特性必须是确定、 定量的并在 可能时是可验证的。 至少应指明不同属性的相对侧重点， 例如易用程度优于易学程度， 或者可移 植性优于有效性。e.5 业务规则列举出有关产品的所有操作规则， 例如什么人在特定环境下可以进行何种操作。 这些本身不 是功能需求，但它们可以暗示某些功能需求执行这些规则。e.6 用户文档列举出将与软件一同发行的用户文档部分，例如， 用户手册、 在线帮助和教程。明确所有已 知的用户文档的交付格式或标准。f.其它需求定义在软件需求规格说明的其它部分未出现的需求， 例如国际化需

27、求或法律上的需求。 你还 可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登 录和监控操作等方面的需求。 附录 A ：词汇表定义所有必要的术语， 以便读者可以正确地解释软件需求规格说明， 包括词头和缩写。 你可 能希望为整个公司创建一跨越多项项目的词汇表， 并且只包括特定于单一项目的软件需求规格说 明中的术语。附录 B ：分析模型这个可选部分包括或涉及到相关的分析模型的位置， 例如数据流程图、 类图、 状态转换图或 实体 - 关系图。附录 C ：待确定问题的列表编辑一在软件需求规格说明中待确定问题的列表， 其中每一表项都是编上号的， 以便于跟踪 调查。2）指明

28、需求来源：指明需求的来源为了让所有项目风险承担者明白需求规格说明书中为何 提供这些功能需求， 要都能追溯每项需求的来源， 这可能是一种使用实例或其它客户要求， 也可 能是某项更高层系统需求、业务规、政府法规、标准或别的外部来源。3）为每项需求注上标号：为了满足软件需求规格说明的可跟踪性和可修改性的质量标准， 必须唯一确定每个软件需求。 为每项需求注上标号制定一种惯例来为需求规格说明书中的每项需 求提供一个独立的可识别的标号或记号。这种惯例应当很健全， 允许增加、删除和修改。作了标 号的需求使得需求能被跟踪， 记录需求变更并为需求状态和变更活动建立度量。 需求标识方法有 序列号 ;层次化编码 ;

29、使用待确定 （to be determined, TBD ）符号等。4）记录业务规：是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。将这些 编写成需求规格说明书中的一个独立部分， 或一独立的业务规文档。 某些业务规将引出相应的功能需求；当然这些需求也应能追溯相应业务规5）创建需求跟踪能力矩阵：建立一个矩阵把每项需求与实现、测试它的设计和代码部分联 系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。 在开发过程中建立这个矩阵，而不要等到最后才去补建。这里我们还要介绍需求规格说明书中设计阶段， 用到的图形模型 - 数据字典、 数据流图、 数 据流图、状态

30、转换图、对话图和类图。数据字典： 一个定义应用程序中使用的所有数据元素和结构的含义、 类型、 数据大小、 格式、 度量单位、 精度以及允许取值围的共享仓库。 数据字典的维护独立于软件需求规格说明， 并且在 产品的开发和维护的任何阶段， 各个风险承担者都可以访问数据字典。 它定义了原数据元素、 组 成结构体的复杂数据元素、重复的数据项、一个数据项的枚举值以及可选的数据项。数据流图： 是结构化系统分析的基本工具。 一个数据流图确定了系统的转化过程、 系统所操 纵的数据或物质的收集（存储），还有过程、存储、外部世界之间的数据流或物质流。数据流模 型把层次分解方法运用到系统分析上， 这种方法很适用于事

31、务处理系统和其它功能密集型应用程 序。数据流图： 描绘了系统的数据关系。 分析实体联系图有助于对业务或系统数据组成的理解和 交互，并暗示产品将有必要包含一个数据库。 相反，当你在系统设计阶段建立实体联系图时， 通 常要定义系统数据库的物理结构。状态转换图： 实时系统和过程控制应用程序可以在任何给定的时间以有限的状态存在。 当满 足所定义的标准时，状态就会发生改变，例如在特定条件下，接收到一个特定的输入激励。 这样 的系统是有限状态机的例子。 大多数软件系统需要一些状态建模或分析， 就像大多数系统涉及到 转换过程、数据实体和业务对象。对话图： 在许多应用程序中， 用户界面可以看作是一个有限状态机。 在任何情况下仅有一个 对话元素（例如一个菜单，工作区，行提示符或对话框）对用户输入是可用的。在激活的输入区 中，用户根据他所采取的活动，可以导航到有限个其它对话元素。 因此， 许多用户界面可以用状态转换图中的一种称为对话图来建模。对话图描绘了系统中的对话元素和它们之间的导航连接， 但它没有揭示具体的屏幕设计。类图： 面向对象的软件开发优于结构化分析和设计， 并且它运用于许多项目的设计中， 从而 产生了面向对象