怎么写需求分析_需求分析怎么写

 

一、需求分析的目的

需求分析是一项软件工程的活动，其目的包括以下几点：

完整地获取用户要求，清楚地理解索要解决的问题；

描述清楚软件的功能和性能；

指明软件与其他系统元素的接口；

建立软件必须满足的约束（如运行环境等）。

二、需求分析的任务

需求分析是研究用户要求，以得到目标系统的需求定义的过程。需求分析的基本任务是软件开发人员和用户一起完全弄清用户对系统的确切要求。具体步骤包括下面几点。

1. 需求获取

调查研究的方法有访谈、分发调查表或开会等。

（1）访谈 ：正式访谈和非正式访谈 。

（2）分发调查表：调查表中列出需要的内容，让用户书面回答问题。

（3）开会 ：可采用开会-讨论-确认的方法进行调查。

2. 需求建模

需求分析建立起来的模型为日后的软件设计提供了可被翻译成数据、体系结构、接口和处理过程设计的模型。

 

2.1软件需求的层次

1)．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

2)．用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本说明中予以说明。

3)．功能需求(functional requirement) 定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

4). 非功能需求(non-functional requirement) 作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。常见的非功能需求如表所示。

 

       下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。

 

2.2常用分析方法

(1) SA（Structure Analysis）：面向数据流的结构化分析方法。

(2) JSD（Jackson System Development）：面向数据结构的Jackson方法。

(3) DSSD（Data Structure System Development）：面向数据结构的结构化数据系统开发方法。

(4) OOA（Object-Oriented Analysis）：面向对象的分析方法。

 

2.3建立系统的逻辑模型（结构化分析方法）

功能模型：DFD数据流图

描述数据在系统中如何被传送或者变换，以及描述如何对数据进行变换的功能（子功能）。

数据模型：ERD实体-关系图

描述数据对象及数据对象之间的关系。

行为模型：STD状态-迁移图

描述系统对外部事件如何响应，如何动作以及系统的各种行为模式和不同状态的转换。

 

结构化分析遵循的三条基本原则：分解、抽象、映射

三个主要目标：

描述用户需要

建立创建软件设计的基础

定义软件完成后可被确认的一组需求

3. 需求规格说明书

       需求规格说明书可以简单理解为由可行性分析、需求建模等内容组成，它为开发人员和用户提供软件开发完成时质量评价的依据。

4. 需求评审

需求分析研究的对象是用户的需求，必须全面理解用户的各项要求，准确表达被接受的用户要求。只有经过确切描述的软件需求才能成为软件设计的基础。

在需求评审阶段，分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保软件需求的完整、准确、清晰、具体，并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。

由系统分析员和用户一起对需求分析结果进行严格的审查，确保软件需求的一致性，完整性和正确性。审查内容有：实体-关系图、详细的数据流图、数据字典、状态转换图和一些简明的算法描述等。

三．编写需求分析报告的要求

a．无歧义性

对最终产品的每一个特性用某一术语描述；若某一术语在某一特殊的行文中使用时具有多种含义，那么应对该术语的每种含义做出解释并指出其适用场合。

b．完整性

需求分析报告应该包括全部有意义的需求，无论是关系到功能的、性能的、设计约束的、还是关系到外部接口方面的需求；对所有可能出现的输入数据的响应予以定义，要对合法和非合法的输入值的响应做出规定；填写全部插图、表、图示标记等；定义全部术语和度量单位。

c．可验证性

需求分析报告描述的每一个需求应是可以验证的。可以通过一个有限处理过程来检查软件产品是否满足需求。

d．一致性

在需求分析报告中的各个需求的描述不能互相矛盾。

e．可修改性

需求分析报告应具有一个有条不紊、易于使用的内容组织；没有冗余，即同一需求不能在需求分析报告中出现多次。

f．可追踪性

每一个需求的源流必须清晰，在进一步产生和改变文件编制时，可以方便地引证每一个需求。

g．运行和维护阶段的可使用性

需求分析报告必须满足运行和维护阶段的需要。在需求分析报告要写明功能的来源和目的。