功能需求分析

一：软件的功能需求分析要怎么写？ 5分

1. 引言

1.1　编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体.

1.2　项目背景

1.2.1项目委托单位:****公司

1.2.2开发单位:***公司

1.3　定义

1.4　　参考资料

2. 任务概述

2.1　目标:

<1> 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示

<2>提高效率:利用软件进行管理,避免人工管理的失误以及 延迟性,从而实现高效率的管理.

2.2　运行环境:

<1> 硬件方面:Pentium级处理芯片

1兆显存的兼容显卡

256色,800*600的兼容显示器

标准兼容打印机

<2>软件方面: WIN95操作系统

2.3　条件与限制:

编程用计算机一台

完成期限2000/7/1

无资金供给

3. 数据概述

数据流程图如下:

3.1　静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据

3.2 　动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间

3.3　数据库描述:

人事管理数据库:公司内人员的个人详细信息,包括档案信息

销售管理数据库:当日销售记录及以前的销售统计,用于销售分析

财务管理数据库:公司内部账目及收支情况详表

技术管理数据库:公司所需各技术档案的详细记录(包括文档)

3.4 数据字典:

<1>数据流词条描述:

1.数据流名:登录信息

来源:用户的输入

去向:系统内部检验部分

组成:用户名,密码

流通量:每次登录输入一次

2.数据流名:登录结果

来源:系统

去向:用户

组成:返回信息

流通量:每次登录返回一次

3.数据流名:输入修改信息

来源:用户

去向:系统判断部分

组成:根据各数据库内容而不同

流通量:依用户输入而定

4.数据流名:反馈信息

来源:系统判断部分

去向:用户

组成:系统经判断后发回的字符数据

流通量: 依系统当前信息而定

5.数据流名:识别信息

来源:系统内部检验部分

去向:系统判断部分

组成:系统各数据库的标识信息

流通量:用户每次输入流通一次

6.数据流名:处理信息

来源:系统判断部分

去向:各数据库处理部分

组成:读取/修改标识,读取/修改的变量名称

流通量:用户每次输入流通一次

7.数据流名:读取修改

来源:系统判断部分

去向:系统各数据库

组成:读取/修改标识,读取/修改内容

流通量: 用户每次输入流通一次

<2>数据文件词条描述:

1.数据文件名:人事数据

简述:存储人员信息

数据文件组成:人员的各项信息(以CString类型为主)

2.数据文件名:销售数据

简述:存储当日及从前的销售记录

数据文件组成:销售的各项信息

3.数据文件名:财务数据

简述:存储财务管理信息

数据文件组成:财务管理的各项记录

4.数据文件名:技术数据

简述:存储公司内部使用的技术档案信息

数据文件组成:技术档案名称,内容

<3>加工逻辑词条描述:

1.加工名:检验

简要描述:判断用户......余下全文>>

二：如何进行非功能需求分析？

按照常规的需求分析理论，需求可分为功能需求和肺功能需求，其中非功能需求又可分为质量和约束。一般来说，对于功能需求，我们仔细一点，多和用户沟通的话，是比较好分析的。而对于非功能需求，我们有时会觉得心有余而力不足，或者说不知如何是好。在很多情况下，项目组干脆就不去分析非功能需求了，所有的这些非功能需求只是停留在项目经理或者某些成员的脑子里。这种情况存在着非常大的隐患，如果产品发布了，我们没有对这些非功能需求进行测试和验证，导致我们的产品中存在许多定时炸弹。这些炸弹在某些场景下就有可能爆炸，炸了用户，也可能炸了自己。对于以上问题，业界有一定分析工具可以有效的解决该问题，即“目标-场景-对策”分析法。举例来说：目标场景决策性能客户端频繁访问页面，WEB服务器负荷大代理服务器客户端大量访问后台图片图片服务器程序频繁访问IO，磁盘压力大数据库拆分以上举了我们对非功能需求中的“性能”大类进行了分析，比如对月客户端大量访问后台图片的场景，我们采取了图片服务器的应对策略。这种分析方法和原有的“存而不论”的方法相比，有以下优点：1、它在流程上就规定了分析人员必须对产品中的非功能需求进行分析；2、它针对非功能需求的目标进行了归类整理；3、对于每个目标中可能发生的场景进行了梳理；4、最后就是比较关键的一条就是，对于每种场景，我们都仔细思考了针对性的决策分析，这些决策为后续的设计起到了指导作用。

三：我们应当怎样做需求分析：功能角色分析与用例图

在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。

但是，当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来以后，我们应当怎样进行分析呢？不少团队对此都比较迷茫，没有一个统一和有效的方法，往往采用想到哪里做到哪里的方式。一些问题想到了就做了，没有想到则忽略掉了。实际上，需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。

需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。按照这个思路，我们对需求的分析，首先应当从功能角色分析开始。所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。

对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是UML的4+1视图中的一种，准确地说就是那个“+1”。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。

一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。但是，通常情况下系统边界只是一个概念而不用真正绘制出来，因为被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。从这个意义上讲，用例图中的参与者不仅包括人，还包括那些外部系统和自动触发器。根据这样一个思路，我以往常常将外部系统和自动触发器绘制成一个小人，这常常令客户感到困惑。随后我改变了思路，将外部系统和自动触发器绘制成另一种表达形式——类元符号表示法，并在构造型上标注为Actor。

上图是一个考核系统中一个子模块的用例图。图中的用例就是这个系统提供给用户的各项功能。注意，这里仅仅是在罗列功能而不表示它们之间诸如流程调用等相互关系，这是一些初学者常常犯的毛病。参与者与用例通过实线关联起来，代表的是一种使用关系。箭头代表的是一种导航，即动作施与的方向。在这个用例图中，普通用户执行查询操作，查询系统提供的“预警监控单项查询”、“预警监控汇总查询”等查询报表；每日......余下全文>>

四：软件需求分析报告主要是由哪些部分组成的?它的作用是什么?

大概有：引言，综合描述，外部接口需求，系统功能需求，其他非功能需求，词汇表，数据定义，分析模型，待定问题列表几部分。

开发软件系统最为困难的概念性工作便是要编写出详细的技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。对于我们开发人员来说，编写出完美的需求文档，对于项目的开发有着重要意义，一方面绩们可以和通过它客户交流去不断地完善系统设计，另一方面，先将需求报告定稿之后再进行开发可以很大程度上避免返工，毕竟重新编码的代价远远超过重写一份需求文档的代价。

五：软件需求分析报告中的“需求规定------对功能的规定”怎么写？？？ 10分

对功能的规定是最接近用户实际业务操作的描述。

例如，描述成绩管理的业务，应该分为成绩录入和成绩修改两个功能点来描述。

成绩录入时，输入就代表需要录入的有哪些数据；输出表示将数据都录完后，会产生什么结果的单据。

我的理解是这样的，供参考。

六：软件需求分析的需求类型

下面这些定义是需求工程领域中常见术语的定义。软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。1．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。2．用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本说明中予以说明。3．功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。下面以一个子处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。

七：需求分析中的功能描述

给个例子吧：

=================================================================

第3章 功能描述

3.1 系统管理

系统管理主要是完成目录管理、栏目建设与调整、数据初始化、界面设定与调整、界面修改与增加、主页风格调整及用户权限管理等工作，是系统管理员的一套专用系统，操作界面应该以Web界面为主，管理员操作时可以方便的选择相关的管理内容。

建立统一的信息站维护管理系统，各级维护人员（包括信息站维护人员、部门维护人员及其他维护人员）登录系统后，可以根据系统管理员分配的角色进行权限范围内的管理维护工作。信息站维护人员能够方便快捷地维护信息站主页内容、更换信息站主页风格，设置修改信息站主页的各种链接信息，决定待发布的信息在信息站主页是否发布和发布期限；部门维护人员可以修改本部门主页和部门的相关内容。系统管理员可以根据工作需要灵活地修改和设置各公共栏目的维护人员所维护的内容。

在系统和栏目创建与安装或升级时，系统能够在系统管理员的简单干预下，能够进行相应的数据更新。

3.2 用户管理

注册用户实行实名制，分级管理用户权限，并且按照我行的人员管理制度进行管理。信息站采用一套统一的用户管理机制，用户管理以人为单位，操作界面以Web界面为主，系统管理员可以灵活方便的创建和冻结用户，设置和修改用户的角色及权限等相关信息。

3.2.1 用户管理过程

用户注册采取用户申请、系统管理员审核批准的方式，申请时需提交个人用户名、真实姓名、性别、行别、部门、科室、职务、邮箱、联系电话等信息，系统管理员核准申请后，按照对应的岗位和应用权限分配列表，对用户进行授权；在用户发生工作岗位变动时，系统管理员确认后，按照权限分配表，调整授权；用户在离职或调离本系统或长时间暂离工作岗位时，系统管理员冻结该用户的所有权限并备案。用户在获取相应的授权后，只需进行一次验证，便能访问信息站中的相关信息，使用信息站的应用和功能以及整合后的其他应用系统的授权部分。新版信息站注册系统具有IP地址管理功能，只有属于本系统预先设置的IP地址范围内的用户可以申请注册。

对相关的部门事务，员工之间和部门之间信息浏览的授权问题：按照每个员工的级别，将其按照部门分组，部门之间不能浏览观看，上级可以看到下级，下级不能看到上级。

3.2.2 用户的分类

用户拟分为管理用户、维护用户和用户三类，并根据信息站管理工作需要和功能模块的划分分为7个级别。用户可以根据工作需要，被赋予不同的权限，担当多种角色。

 管理用户

信息站系统管理员：可以管理信息站的全局内容,使用信息站的全局功能，负责信息站新用户的审核，给用户赋予不同的权限和角色。

 维护用户(分为两个级别)

信息站维护人员：维护信息站主页的栏目设置与链接、信息站主页风格、信息站主页栏目内容和部门主页栏目设置，并具有部门、支行、栏目维护人员的权限。

部门维护人员：维护部门主页的栏目设置与链接、部门主页风格和部门主页栏目内容，可以审核、发布、删除、修改文档。

 用户（分为四个级别）

高级用户：可以浏览全部的信息站文档和数据信息，访问和使用集成的相关系统，可发布实名和匿名信息。

普通用户：可以浏览授权的信息站文档和数据信息，访问和使用集成的相关系统，可发布实名和匿名信息。

公共用户（建行ccb用户）：可以浏览信息站公开的信息和内容，可发布ccb实名和匿名信息。

匿名用户：只能浏览信息站匿名公开的信息和内容，可发布匿名信息和浏览匿名信息。

......余下全文>>

八：需求分析的详细分析

从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。狭义上理解需求分析指需求的分析、定义过程。 需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。 需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。 需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。原型主要有三种类型：探索型、实验型、进化型。探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。在使用原型化方法时有两种不同的策略：废弃策略、追加策略。废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。追加策略：先构造一个功能简单而且质量要求不高......余下全文>>

九：需求分析的作用及如何进行需求分析

过对应问题及其环境的理解与分析，分析需求规格的正确性和可行性，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，这一系列的活动即构成软件开发生命周期的需求分析阶段，并开始开展工作，自1994年起每两年举办一次需求工程国际会议(ICRE)，作为用户和开发者之间的一个协约，形成了软件工程的子领域——需求工程(requirementengineering。软件需求工程是一门分析并记录软件需求的学科：通过与用户的交流，对现有系统的观察及对任务进行分析。一些关于需求工程的工作小组也相继成立：为最终用户所看到的系统建立一个概念模型，将用户需求精确化。

需求工程是一个不断反复的需求定义、需求演进的过程，并通过一系列重复的分析、文档记录。后来软件开发引入了生命周期的概念，形成需求文档、测试直至维护的主要基础，在计算机发展的初期，可以把需求工程的活动划分为以下5个独立的阶段，改进软件质量：支持系统的需求演进，需求规格说明又是软件设计，为问题涉及的信息，从而开发，作为对需求的抽象描述，HerbKrasner定义了需求工程的五阶段生命周期、功能及系统行为建立模型。

需求工程是随着计算机的发展而发展的；另一方面、完全化，它贯穿于系统开发的整个生命周期、需求决策：

（1）需求获取、捕获和修订用户的需求。80年代中期，MatthiasJarke和KlausPohl提出了三阶段周期的说法，需求分析很少受到重视，从而提高软件生产率；

（3）形成需求规格、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数，需求工程成为研究的热点之一。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束。从1993年起每两年举办一次需求工程国际研讨会(ISRE)，确定客户需求、比较研究。

需求分析是介于系统分析和软件设计阶段之间的桥梁，需求分析成为其第一阶段，如欧洲的RENOIR(RequirementsEngineeringNetworkofInternationalCooperatingResearchGroups)、方法进行需求分析、需求实现与验证，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科，并尽可能多的捕获现实世界的语义。随着软件系统规模的扩大，最终形成需求规格说明，并最终在验证的基础上冻结需求，通过符号执行，把这些子系统或任务分配给软件；

（5）需求管理：生成需求模型构件的精确的形式化的描述，软件规模不大，并从软件角度对它们进行检查与调整，并对用户不断变化的需求演进给予支持，降低开发成本、实现。近来,RE)；

（2）需求建模。良好的分析活动有助于避免或尽早剔除早期错误，它把系统需求分解成一些主要的子系统和任务。80年代、形成需求规格、设计，软件开发所关注的是代码编写。一方面、需求演进管理。

需求工程是指应用已证实有效的技术，在1996年Springer-Verlag发行了一新的刊物——《RequirementsEngineering》、表示和验证；

（4）需求验证。

综合了几种观点，需求分析与定义在整个软件开发与维护过程中越来越重要。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，直接关系到软件的成功与否、模拟或快速原型等途径：需求定义和分析：以需求规格说明为输入。进入90年代以来，如需求变化和可跟踪性问题。RE可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）：获取...余下全文>>

十：从哪些方面如何具体做好需求分析

1. 访问并与有潜力的用户探讨

为找出新软件产品的用户需求，最直截了当的方法是询问他们。本章讨论如何寻找合适的用户代表，而在第8章讲述从这些代表中获取需求的技巧。

2. 把对目前的或竞争产品的描述写成文档

文档可以描述一种所必须遵循的标准或产品所必须遵循的政府或工业规则。

3. 系统需求规格说明

一个包含软、硬件的产品需要一个高档次的系统需求规格说明以介绍整个产品。系统需求的子集被分配到每个软件子系统中（ Nelsen 1990）。附加的详细软件功能需求将从有关软件的系统需求里获得。

4. 对当前系统的问题报告和增强要求

指导用户和提供技术支持的工作人员是最有价值的需求来源。他们收集了用户在使用现有系统过程中所遇到问题的信息，还接受了用户关于系统改进的想法。

5. 市场调查和用户问卷调查

调查有助于从广大有潜力的用户那里获得大量定量的数据，务必调查相关的用户并询问一些能产生反响的好问题。

6. 观察正在工作的用户

对当前系统的用户和将来系统的有潜力的用户，分析员观察“日常工作”以获得经验，这些经验能提供很有价值的信息。分析员可通过观察用户与所关联的任务环境的工作流程来预见用户在使用当前系统时所遇到的问题，并能分析新的系统可有效支持工作流程的方面（McGraw and Harbison 1997; Beyer and Holtzblatt 1998）。比起仅仅简单地询问用户，并记下用户在处理任务时的步骤来说，直接观察用户的工作流程可以对他们的活动有更正确的理解。分析员必须抽象和总结用户的直接活动，以确保所获得的需求具有普遍性，而不仅仅代表单个用户。一个富有技巧的分析员还可以为改进用户的当前事务处理过程提出一些见解。

7. 用户任务的内容分析

通常通过开发具体的情节（ s c e n a r i o）或活动顺序（有时称作“情节”），可以确定用户利用系统需要完成的任务，分析员由此可以获得用户用于处理任务的必要的功能需求。