软件工程之需求分析
软件工程之需求分析
编者按：现在人们越来越认识到软件工程在软件开发中的重要作用。目前国内软件在开发中还没有对软件开发的过程进行明确规定，文档不完整，也不规范，软件项目的成功往往归功于软件开发组的一些杰出个人或小组的努力。这种依赖于个别人员上的成功并不能为全组织的软件生产率和质量的提高奠定有效的基础，只有通过建立全过程的改善，采用严格的软件工程方法和管理，并且坚持不懈地付诸实践，才能取得全组织的软件过程能力的不断提高，使软件开发更规范合理。
我们马上就要进入WTO，因此软件开发也要与国际接轨，只有这样才能提高我们在项目管理水平，最终开发出高质量的软件。
综述
软件工程中包含需求、设计、编码和测试四个阶段,其中需求工程是软件工程第一个也是很重要的一个阶段，本文以医院管理系统为例详细介绍了需求工程的构成和进行方法。
一、需求开发
需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。以下列出和讲解分析常规的步骤，当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤
1．需求获取
确定需求开发过程确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。
2．需求分析
绘制关联图、创建开发原型、分析可行性、确定需求优先级、为需求建立模型、编写数据字典、应用质量功能调配。
3．编写规格说明书
项目视图和范围文档包含了业务需求，而使用实例文档则包含了用户需求
4．需求验证
审查需求文档、依据需求编写测试用例、编写用户手册、确定合格的标准
二、需求管理
需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线。
==============================================================
一、综述
软件工程中包含需求、设计、编码和测试四个阶段,其中需求工程是软件工程第一个也是很重要的一个阶段，本文以医院管理系统为例详细介绍了需求工程的构成和进行方法。
首先我们必须了解需求工程和其他项目过程的关系：
|
|
软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:业务需说明了提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明;用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明;功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
|
|
需求工程分为了需求开发和需求管理两个阶段:下面就以这两个阶段说明:
二,需求开发
需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。以下列出和讲解分析常规的步骤，当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤。
1．需求获取：
1）确定需求开发过程：确定需求开发过程确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。对重要的步骤要给予一定指导，这将有助于分析人员的工作，而且也使收集需求活动的安排和进度计划更容易进行。
2）编写项目视图和范围文档：项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。
表1 项目视图和范围文档的模板
a . 1 背景在这一部分，总结新产品的理论基础，并提供关于产品开发的历史背景或形势的一般性描述。
a.2 业务机遇描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系统将运用的环境。包括对现存产品的一个简要的相对评价和解决方案，并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。
a.3 业务目标用一个定量和可测量的合理方法总结产品所带来的重要商业利润,把重点放在给业务的价值上。
a.4 客户或市场需求描述一些典型客户的需求，包括不满足现有市场上的产品或信息系统的需求。提出客户目前所遇到的问题在新产品中将可能（或不可能）出现的阐述，提供客户怎样使用产品的例子。确定了产品所能运行的软、硬件平台。
a.5 提供给客户的价值确定产品给客户带来的价值，并指明产品怎样满足客户的需要。
a.6 业务风险总结开发（或不开发）该产品有关的主要业务风险，例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性，指明你所能采取的减轻风险的措施。
b.1 项目视图陈述编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。项目视图陈述将考虑权衡有不同需求客户的看法。它可能有点理想化，但必须以现有的或所期待的客户市场、企业框架、组织的战略方向和资源局限性为基础。
b.2 主要特性包括新产品将提供的主要特性和用户性能的列表。强调的是区别于以往产品和竞争产品的特性。可以从用户需求和功能需求中得到这些特性。
b.3 假设和依赖环境在构思项目和编写项目视图和范围文档时，要记录所作出的任何假设。通常一方所持的假设应与另一方不同。
c.1 首次发行的范围总结首次发行的产品所具有的性能。描述了产品的质量特性，这些特性使产品可以为不同的客户群提供预期的成果。
c.2 随后发行的范围如果你想象一个周期性的产品演变过程，就要指明哪一个主要特性的开发将被延期，并期待随后版本发行的日期。
c.3 局限性和专用性明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径。列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。
d.1 客户概貌客户概述明确了这一产品的不同类型客户的一些本质的特点，以及目标市场部门和在这些部门中的不同客户的特征。
d.2 项目的优先级一旦明确建立项目的优先级，风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面：性能、质量、计划、成本和人员。
e. 产品成功的因素明确产品的成功是如何定义和测量的，并指明对产品的成功有巨大影响的几个因素。不仅要包括组织直接控制的范围内的事务，还要包括外部因素。如果可能，可建立测量的标准用于评价是否达到业务目标.
3）用户群分类：产品的用户在很多方面存在着差异，例如：用户使用产品的频度、他们的应用领域和计算机系统知识、他们所使用的产品特性、他们所进行的业务过程、他们在地理上的布局以及他们的访问优先级。根据这些差异，你可以把这些不同的用户分成小组。用户类不一定都指人，你可以把其它应用程序或系统接口所用的硬件组件也看成是附加用户类的成员。以这种方式来看待应用程序接口，可以帮助你确定产品中那些与外部应用程序或组件有关的需求。将用户群分类并归纳各自特点为避免出现疏忽某一用户群需求的情况，要将可能使都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。
4）选择产品代表：择每类用户的产品代表为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。这对于内部信息系统的开发是最易实现的，因为此时，用户就是身边的职员。而对于商业开发，就得在主要的客户或测试者中建立起良好的合作关系，并确定合适的产品代表。他们必须一直参与项目的开发而且有权作出决策。每一个产品代表者代表了一个特定的用户类，并在那个用户类和开发者之间充当主要的接口。
5）建立核心队伍：建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求。这样的核心队伍对于商业开发尤为有用，因为你拥有一个庞大且多样的客户基础。与产品代表的区别在于，核心队伍成员通常没有决定权。
6）确定使用实例：让用户代表确定使用实例从用户代表处收集他们使用软件完成所需任务的描述-使用实例，讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标准模版，在使用实例基础上可得到功能需求。
一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序。因此，一个使用实例是相关的用法说明的集合，并且一个说明是使用实例的例子。在描述时列出执行者和系统之间相互交互或对话的顺序。当这种对话结束时，执行者也达到了预期的目的。
对于一些复杂的使用实例，画出图形分析模型是有益的，这些模型包括数据流程图、实体关系图、状态转化图、对象类和联系图。
使用实例的描述并不向开发者提供他们所要开发的功能的细节。为了减少这种不确定性，你需要把每一个使用实例叙述成详细的功能需求。每一个使用实例可引伸出多个功能需求，这将使执行者可以执行相关的任务；并且多个使用实例可能需要相同的功能需求。使用实例方法给需求获取带来的好处来自于该方法是以任务为中心和以用户为中心的观点。比起使用以功能为中心的方法，使用实例方法可以使用户更清楚地认识到新系统允许他们做什么。
每一个使用实例都描述了一个方法，用户可以利用这个方法与系统进行交互，从而达到特定的目标。使用实例可有效地捕捉大多数所期望的系统行为，但是你可能有一些需求，这些需求与用户任务或其他执行者之间的交互没有特定的关系。这时你就需要一个独立的需求规格说明。
7）召开应用程序开发联系会议：召开应用程序开发联系会议应用程序开发联系会议是范围广的、简便的专题讨论会，也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践。
8）分析用户工作流程：分析用户工作流程观察用户执行业务任务的过程。画一张简单的示意图（最好用数据流图）来描绘出用户什么时候获得什么数据，并怎样使用这些数据。编制业务过程流程文档将有助于明确产品的使用实例和功能需求。你甚至可能发现客户并不真地需要一个全新的软件系统就能达到他们的业务目标。
9）确定质量属性：确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质量特点，这会使你的产品达到并超过客户的期望。对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属性，这是一种非功能需求。听取那些描述合理特性的意见：快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性。你将要和用户一起商讨精确定义他们模糊的和主观言辞的真正含义。
10）检查问题报告：通过检查当前系统的问题报告来进一步完善需求客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。
11）需求重用：跨项目重用需求如果客户要求的功能与已有的产品很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。
2．需求分析
1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。
2）创建开发原型：创建用户接口原型当开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。
3）分析可行性：分析需求可行性在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
4）确定需求优先级：确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。
5）为需求建立模型：为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
6）编写数据字典：创建数据字典数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。
7）应用质量功能调配：使用质量功能调配质量功能调配是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。它将需求分为三类：期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。
3．编写规格说明书
项目视图和范围文档包含了业务需求，而使用实例文档则包含了用户需求。你必须编写从使用实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属性和外部接口需求。软件需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。
1）采用软件需求规格说明模版: 采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注意，其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。许多组织一开始都采用IEEE标准830-1998(IEEE 1998)描述的需求规格说明书模板。要相信模板是很有用的，但有时要根据项目特点进行适当的改动。
4. 需求验证
1）审查需求文档：对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查。另外在需求开发期间所做的非正式评审也是有所裨益的。
2）依据需求编写测试用例：根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求。还要从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。同时，要使用测试用例来验证需求模型的正确性，如对话框图和原型等。
3）编写用户手册：在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能。而辅助需求如质量属性、性能需求及对用户不可见的功能则在需求规格说明书中予以说明。
4）确定合格的标准：确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。将合格的测试建立在使用情景描述或使用实例的基础之上。
二、需求管理
需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。需求约定是需求开发和需求管理之间的桥梁，需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动。
1．确定需求变更控制过程，确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。
2．建立变更控制委员会，组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。
3．进行需求变更影响分析，应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。影响分析可以提供对建议的变更的准确理解，帮助做出信息量充分的变更批准决策。通过对变更内容的检验，确定对现有的系统做出是修改或抛弃的决定，或者创建新系统以及评估每个任务的工作量。进行影响分析的能力依赖于跟踪能力数据的质量和完整性。
4．跟踪所有受需求变更影响的工作产品当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。
5．建立需求基准版本和需求控制版本文档确定一个需求基准，这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。
6．维护需求变更的历史记录记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。版本控制工具能自动完成这些任务。版本控制是管理需求的一个必要方面。需求文档的每一个版本必须被统一确定。组内每个成员必须能够得到需求的当前版本，必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应仅允许指定的人来更新需求。这些策略适用于所有关键项目文档。
7．跟踪每项需求的状态建立一个数据库，其中每一条记录保存一项功能需求。保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。
8．衡量需求稳定性记录基准需求的数量和每周或每月的变更（添加、修改、删除）数量。过多的需求变更"是一个报警信号"，意味着问题并未真正弄清楚，项目范围并未很好地确定下来或是政策变化较大。
9．使用需求管理工具商业化的需求管理工具能帮助你在数据库中存储不同类型的需求，为每项需求确定属性，可跟踪其状态，并在需求与其它软件开发工作产品间建立跟踪能力联系链。
