-
软件需求分析
-
中文名
- 软件需求分析 外文名
- Software requirement analysis
-
任 务
- 确定对系统的综合要求 分 析
- 系统的数据要求 导 出
- 系统的逻辑模型
目录
简介
深入描述软件的功能和性能，确定
软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求，借助于当前系统的逻辑模型导出目标系统逻辑模型，解决目标系统“做什么”的问题。
需求分析可分为需求提出、需求描述及需求评审三个阶段。
需求提出
主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。开发人员和用户确定一个问题领域，并定义一个描述该问题的系统。这样的定义称作系统
规格说明，并且它在用户和开发人员之间充当合同。
需求描述
在问题分析阶段分析人员的主要任务是：对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来，以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是用户尚未提出但具有真正价值的潜在需求。
需求评审
在需求评审阶段，分析人员要在用户和
软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保
软件需求的完整、准确、清晰、具体，并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。
进行需求分析时，应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象，并尽量将分析进度提交给用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。
分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、
结构设计和过程设计的数据和功能表示。在
软件完成后，制定的软件规格说明还要为评价
软件质量提供依据。
开发软件系统最为困难的部分就是要准确说明开发什么。最为困难的概念性工作便是要编写出详细的技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。如果做错，这将是会最终给系统带来极大损害的一部分，并且以后再对它进行修改也极为困难。目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间的接口是系统开发人员最头痛的问题。对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？
然而，即便并非出于商业目的的
软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生。
下面这些定义是
需求工程领域中常见术语的定义。
软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。
1．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们
在项目视图与范围文档中予以说明。
2．用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（use
case）文档或方案脚本说明中予以说明。
3．功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的
任务，从而满足了业务需求。
在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件
需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大
型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部
件）。
作为功能需求的补充，
软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和
执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或
实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是
通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为
重要。
下面以一个子处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中
的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户
需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该
拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现
整个文档范围的替换。
从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些
没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发
布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。
软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下：
1 引言
1．1编写目的
说明编写这份软件需求说明书的目的，指出预期的读者。
1．2背景
说明：
a．待开发的软件系统的名称；
b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
C．该软件系统同其他系统或其他机构的基本的相互来往关系。
1．3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1．4参考资料
列出用得着的参考资料，如：
a．本项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2 任务概述
2．1目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
2．2用户的特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是
软件设计工作的重要约束
2．3假定和约束
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
3 需求规定
3．1对功能的规定
用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
3．2对性能的规定
3．2．1精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3．2．2时间特性要求
说明对于该软件的时间特性要求，如对：
a．响应时间；
b．更新处理时间；
c．数据的转换和传送时间；
d．解题时间； 等的要求。
3．2．3灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
a．操作方式上的变化；
b．运行环境的变化；
c．同其他软件的接口的变化；
d．精度和有效时限的变化；
e．计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3．3输入输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的
数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3．4数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
3．5故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3．6其他专门要求
如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
4 运行环境规定
4．1设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a．处理器型号及内存容量；
b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
c．输入及输出设备的型号和数量，联机或脱机；
d．数据通信设备的型号和数量；
e．功能键及其他专用硬件
4．2支持软件
列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
4．3 接口
说明该软件同其他软件之间的接口、
数据通信协议等。
4．4控制
说明控制该软件的运行的方法和
控制信号，并说明这些控制信号的来源。
-
参考资料
扫一扫
1205
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
