《软件工程中包含需求》由会员分享，可在线阅读，更多相关《软件工程中包含需求（3页珍藏版）》请在金锄头文库上搜索。
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）确定质量属性：确定质量属性和其它非功能需求在功能需 求之外再考虑一下非功能的质量特点，这会使你的产品达到并超过客户的期望。 对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属性， 这是一种非功能需求。听取那些描述合理特性的意见：快捷、简易、直觉性、 用户友好、健壮性、可靠性、安全性和高效性。你将要和用户一起商讨精确定 义他们模糊的和主观言辞的真正含义。 10）检查问题报告：通过检查当前 系统的问题报告来进一步完善需求客户的问题报告及补充需求为新产品或新版 本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人能 为收集需求过程提供极有价值的信息。 11）需求重用：跨项目重用需求如 果客户要求的功能与已有的产品很相似，则可查看需求是否有足够的灵活性以 允许重用一些已有的软件组件。
