软件工程之需求分析.docx
《软件工程之需求分析.docx》由会员分享，可在线阅读，更多相关《软件工程之需求分析.docx（11页珍藏版）》请在冰豆网上搜索。
软件工程之需求分析
软件工程之需求分析
一、综述
软件工程中包含需求、设计、编码和测试四个时期,其中需求工程是软件工程第一个也是专门重要的一个时期，本文以医院治理系统为例详细介绍了需求工程的构成和进行方法。
第一我们必须了解需求工程和其他项目过程的关系：
图1需求与其他项目过程的关系
软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:
业务需说明了提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范畴文档中予以说明;用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明;功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
需求工程分为了需求开发和需求治理两个时期:
下面就以这两个时期说明:
一,需求开发
需求开发又分为需求猎取、需求分析、编写规格说明书和需求验证。
以以下出和讲解分析常规的步骤，因此应按照项目的大小和特点等实际情形我们应该自己确定合适的步骤。
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（IEEE1998）描述的需求规格说明书模板。
要相信模板是专门有用的，但有时要依照项目特点进行适当的改动。
a.引言
引言提出了对软件需求规格说明的纵览，这有助于读者明白得文档如何编写同时如何阅读和说明。
a.1目的
对产品进行定义，在该文档中详尽说明了那个产品的软件需求，包括修正或发行版本号。
假如那个软件需求规格说明只与整个系统的一部分有关系，那么就只定义文档中说明的部分或子系统。
a.2文档约定
描述编写文档时所采纳的标准或排版约定，包括正文风格、提示区或重要符号。
a.3预期的读者和阅读建议
列举了软件需求规格说明所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。
描述了文档中剩余部分的内容及其组织结构。
提出了最适合于每一类型读者阅读文档的建议。
a.4产品的范畴
提供了对指定的软件及其目的的简短描述，包括利益和目标。
把软件与企业目标或业务策略相联系。
能够参考项目视图和范畴文档而不是将其内容复制到那个地点。
a.5参考文献
列举了编写软件需求规格说明时所参考的资料或其它资源。
这可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。
b.综合描述
这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和的限制、假设和依靠。
b.1产品的前景
描述了软件需求规格说明中所定义的产品的背景和起源。
说明了该产品是否是产品系列中的下一成员，是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个新型的、自含型产品。
b.2产品的功能
概述了产品所具有的要紧功能。
其详细内容将在d中描述，因此在此只需要概略地总结。
专门好地组织产品的功能，使每个读者都易于明白得。
b.3用户类和特点
确定你觉得可能使用该产品的不同用户类并描述它们相关的特点。
有一些需求可能只与特定的用户类相关。
b.4运行环境
描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。
b.5设计和实现上的限制
确定阻碍开发人员自由选择的问题，并说明这些问题什么缘故成为一种限制。
b.6假设和依靠
列举出在对软件需求规格说明中阻碍需求陈述的假设因素〔与因素相对立〕。
这可能包括你打算要用的商业组件或有关开发或运行环境的问题。
你可能认为产品将符合一个专门的用户界面设计约定，然而另一个SRS读者却可能不如此认为。
假如这些假设不正确、不一致或被更换，就会使项目受到阻碍。
此外，确定项目对外部因素存在的依靠。
例如，假如你打算把其它项目开发的组件集成到系统中，那么你就要依靠那个项目按时提供正确的操作组件。
假如这些依靠差不多记录到其它文档（例如项目打算）中了，那么在此就能够参考其它文档。
c.外部接口需求
利用本节来确定能够保证新产品与外部组件正确连接的需求。
关联图表示了高层抽象的外部接。
需要把对接口数据和操纵组件的详细描述写入数据字典中。
假如产品的不同部分有不同的外部接口，那么应把这些外部接口的详细需求并入到这一部分的实例中。
c.1用户界面
陈述所需要的用户界面的软件组件。
描述每个用户界面的逻辑特点。
而关于用户界面的细节，例如特定对话框的布局，应该写入一个独立的用户界面规格说明中，而不能写入软件需求规格说明中。
c.2硬件接口
描述系统中软件和硬件每一接口的特点。
这种描述可能包括支持的硬件类型、软硬件之间交流的数据和操纵信息的性质以及所使用的通信协议。
c.3软件接口
描述该产品与其它外部组件〔由名字和版本识别〕的连接，包括数据库、操作系统、工具、库和集成的商业组件。
明确并描述在软件组件之间交换数据或消息的目的。
描述所需要的服务以及内部组件通信的性质。
确定将在组件之间共享的数据。
c.4通信接口
描述与产品所使用的通信功能相关的需求，包括电子邮件、Web扫瞄器、网络通信标准或协议及电子表格等等。
定义了相关的消息格式。
规定通信安全或加密问题、数据传输速率和同步通信机制。
d.系统特性
d.1说明和优先级
提出了对该系统特性的简短说明并指出该特性的优先级是高、中，依旧低。
或者你还能够包括对特定优先级部分的评判，例如利益、缺失、费用和风险，其相对优先等级能够从1〔低〕到9〔高〕。
d.2鼓舞/响应序列
列出输入鼓舞〔用户动作、来自外部设备的信号或其它触发器〕和定义这一特性行为的系统响应序列。
这些序列将与使用实例相关的对话元素相对应。
d.3功能需求
详列出与该特性相关的详细功能需求。
这些是必须提交给用户的软件功能，使用户能够使用所提供的特性执行服务或者使用所指定的使用实例执行任务。
描述产品如何响应可预知的出错条件或者非法输入或动作。
就像本章开头所描述的那样，你必须唯独地标识每个需求。
e.其它非功能需求
这部分列举出了所有非功能需求，如产品的易用程度如何，执行速度如何，可靠性如何，当发生专门情形时，系统如何处理，而不是外部接口需求和限制。
e.1性能需求
阐述了不同的应用领域对产品性能的需求，并说明它们的原理以关心开发人员作出合理的设计选择。
确定相互合作的用户数或者所支持的操作、响应时刻以及与实时系统的时刻关系。
你还能够在那个地点定义容量需求，例如储备器和磁盘空间的需求或者储备在数据库中表的最大行数。
尽可能详细地确定性能需求。
可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它们都集中在一起陈述。
e.2安全设施需求
详尽陈述与产品使用过程中可能发生的缺失、破坏或危害相关的需求。
定义必须采取的安全爱护或动作，还有那些预防的潜在的危险动作。
明确产品必须遵从的安全标准、策略或规那么。
e.3安全性需求
详尽陈述与系统安全性、完整性或与私人问题相关的需求，这些问题将会阻碍到产品的使用和产品所创建或使用的数据的爱护。
定义用户身份确认或授权需求。
明确产品必须满足的安全性或保密性策略。
e.4软件质量属性
详尽陈述与客户或开发人员至关重要的其它产品质量特性。
这些特性必须是确定、定量的并在可能时是可验证的。
至少应指明不同属性的相对侧重点，例如易用程度优于易学程度，或者可移植性优于有效性。
e.5业务规那么
列举出有关产品的所有操作规那么，例如什么人在特定环境下能够进行何种操作。
这些本身不是功能需求，但它们能够暗示某些功能需求执行这些规那么。
e.6用户文档
列举出将与软件一同发行的用户文档部分，例如，用户手册、在线关心和教程。
明确所有的用户文档的交付格式或标准。
f.其它需求
定义在软件需求规格说明的其它部分未显现的需求，例如国际化需求或法律上的需求。
你还能够增加有关操作、治理和爱护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。
附录A：
词汇表
定义所有必要的术语，以便读者能够正确地说明软件需求规格说明，包括词头和缩写。
你可能期望为整个公司创建一张跨过多项项目的词汇表，同时只包括特定于单一项目的软件需求规格说明中的术语。
附录B：
分析模型
那个可选部分包括或涉及到相关的分析模型的位置，例如数据流程图、类图、状态转换图或实体-关系图。
附录C：
待确定问题的列表
编辑一张在软件需求规格说明中待确定问题的列表，其中每一表项差不多上编上号的，以便于跟踪调查。
2〕指明需求来源：
指明需求的来源为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要都能追溯每项需求的来源，这可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。
3〕为每项需求注上标号：
为了满足软件需求规格说明的可跟踪性和可修改性的质量标准，必须唯独确定每个软件需求。
为每项需求注上标号制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号。
这种惯例应当专门健全，承诺增加、删除和修改。
作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。
需求标识方法有序列号;层次化编码;使用"待确定"〔tobedetermined,TBD〕符号等。
4〕记录业务规范：
是指关于产品的操作原那么，比如谁能在什么情形下采取什么动作。
将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档。
某些业务规范将引出相应的功能需求；因此这些需求也应能追溯相应业务规范。
5〕创建需求跟踪能力矩阵：
建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。
如此的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。
在开发过程中建立那个矩阵，而不要等到最后才去补建。
那个地点我们还要介绍需求规格说明书中设计时期，用到的图形模型--数据字典、数据流图、数据流图、状态转换图、对话图和类图。
数据字典：
一个定义应用程序中使用的所有数据元素和结构的含义、类型、数据大小、格式、度量单位、精度以及承诺取值范畴的共享仓库。
数据字典的爱护独立于软件需求规格说明，同时在产品的开发和爱护的任何时期，各个风险承担者都能够访问数据字典。
它定义了原数据元素、组成结构体的复杂数据元素、重复的数据项、一个数据项的枚举值以及可选的数据项。
数据流图：
是结构化系统分析的差不多工具。
一个数据流图确定了系统的转化过程、系统所操纵的数据或物质的收集〔储备〕，还有过程、储备、外部世界之间的数据流或物质流。
数据流模型把层次分解方法运用到系统分析上，这种方法专门适用于事务处理系统和其它功能密集型应用程序。
数据流图：
描画了系统的数据关系。
分析实体联系图有助于对业务或系统数据组成的明白得和交互，并暗示产品将有必要包含一个数据库。
相反，当你在系统设计时期建立实体联系图时，通常要定义系统数据库的物理结构。
状态转换图：
实时系统和过程操纵应用程序能够在任何给定的时刻内以有限的状态存在。
当满足所定义的标准时，状态就会发生改变，例如在特定条件下，接收到一个特定的输入鼓舞。
如此的系统是有限状态机的例子。
大多数软件系统需要一些状态建模或分析，就像大多数系统涉及到转换过程、数据实体和业务对象。
对话图：
在许多应用程序中，用户界面能够看作是一个有限状态机。
在任何情形下仅有一个对话元素〔例如一个菜单，工作区，行提示符或对话框〕对用户输入是可用的。
在激活的输入区中，用户依照他所采取的活动，能够导航到有限个其它对话元素。
因此，许多用户界面能够用状态转换图中的一种称为对话图来建模。
对话图描画了系统中的对话元素和它们之间的导航连接，但它没有揭示具体的屏幕设计。
类图：
面向对象的软件开发优于结构化分析和设计，同时它运用于许多项目的设计中，从而产生了面向对象分析、设计和编程的域。
类图是用图形方式表达面向对象分析所确定的类以及它们之间的关系。
4.需求验证
1〕审查需求文档：
对需求文档进行正式审查是保证软件质量的专门有效的方法。
组织一个由不同代表〔如分析人员，客户，设计人员，测试人员〕组成的小组，对需求规格说明书及相关模型进行认确实检查。
另外在需求开发期间所做的非正式评审也是有所裨益的。
2〕依据需求编写测试用例：
依照用户需求所要求的产品特性写出黑盒功能测试用例。
客户通过使用测试用例以确认是否达到了期望的要求。
还要从测试用例追溯回功能需求以确保没有需求被疏忽，同时确保所有测试结果与测试用例相一致。
同时，要使用测试用例来验证需求模型的正确性，如对话框图和原型等。
3〕
升级会员 