如何进行软件需求分析

如何进行软件需求分析，简而言之不是几句话可以描述清楚的，这里给你一些方法功能参考。
首先，在进行软件需求分析之前，得有一份软件说明书或者软件需求规格说明书，因为这个是我们进行需求分析的对象。但是这个需求规格书写的质量怎么样，实际上是决定了软件项目的进度、成本甚至成败的？为什么这么说呢？因为当前软件开发这个行业最大的问题是需求质量低下，这个导致了项目成本至少增加了30%以上，这也是为什么软件这个行业有钱的公司不多的主要原因。或者说能做出一份有质量的需求规格说明书将体现这个企业的挣钱能力，但现实是绝大多数企业都像人月神话中描述的一样：一步一步踏入了泥潭。。。由于这个工作产品如此重要，因此通过过个步骤来保证它的质量：需求策划、获取、分析、确认以及后期需求管理，尤其是变更管理。如果想了解具体的每个步骤的详细内容可以联系我。
其次，如果需求规格说明书有了，我们怎么分析呢？在具体说明分析方法之前，首先我们要明确一个问题：需求分析到底是在分析什么？其目的是什么？其实我们绝大多数的需求工程师都不太清楚或者不能明确的回答这些问题，从而导致他们花费了大量的时间来写用例（user case），写了很多关系复杂甚至连需求人员都看不明白或者越看越糊涂的东西，因为他们认为这样后续的开发、测试人员就能开明白了，事实上是这样的吗？根本不是，如果是的话，我们的软件行业中的绝大多数企业活的普遍不那么悲惨了。。。回到软件开发，我们来想一下，我们开发这个东西给谁用？是自己吗？？？如果是自己事情就简单了，因为需求都在自己脑子里面了，就算不完整起码也不会缺多少，但问题正好相反，99999999%的情况下我们是为别人或者说我们的用户开发的，也就是说需求其实是在客户的脑子了，而不是我们的脑子里！！！我们的首要目的应该是如何通过一套完整的套路把需求从客户的脑子里面传输到我们的脑子里面，然后按照规格化（这个是另外一个重点）的方式把它按照说明书一样描述出来让后续人员能够看得清清楚楚、明明白白，这个步骤是最关键的一环，因为我们的绝大多数客户都不会写需求规格说明书，所以这个任务落在我们的身上。那么我们到底都问什么不会丢需求呢？这个是有一套方法和模板来指导需求人员和UI工程师（调研时就需要画原型，可以稍微想一下这么做的好处）来获取完整的需求。只有这样，才能获取有质量的需求。
那么说了这么多，分析到底是干什么的呢？分析就是需求人员首先自己要系统的检查一下需求来保障需求的质量，记住不是保证，是保障，它就像软件开发中的评审或测试一样，是保障产品的质量进行的检查活动，它们不能保证质量，只是保障作用。就像我们考试一样，你认真的答完题了，还是需要认真的检查一遍，因为这个是人的天性之一。那么问题来了，怎么进行检查或者从哪些方面进行检查呢？我推荐的策略是先外后内、先系统后模块、先功能后非功能、先业务后属性，通过整套方法下来可以帮我们查到不少之前遗漏、写错、或者矛盾的地方，当然也包括可能不是客户需要的needs，只是expectation。这个工作比获取要简单一些，但是是一个繁杂的活，要逐项逐项的检查每一个需求的内容以保障需求的质量。到底检查哪些内容呢？这个太多了，就不罗列了，需要的网友可联系我。
同样，需求评审就是另外一帮人帮我我们再次检查一下需求，看看里面是否有什么问题存在，是进行需求质量保障的另外一个重要环节。
因此，分析与评审其实是很类似的工作，只是参加检查的人员角色从单一角色变为多角色，因为需求规格说明书要被他们拿来进行实现和测试。
我们常规的需求分析，基本上可以认为是在 盲人摸象，在主观的发挥着他们的想象力去判断，而忘记了 需求其实在客户脑子里 这个基本的原则，你用一套方法和模板问出来就是了。。。当然前提是套路要实用，模板要详尽。。。
就说这么多，希望对你能有所帮助。。

一个软件开发项目通常要经历需求分析、设计、编程、测试等几个大的阶段。其中设计又包括整体设计、系统设计（把整体架构变成一块块系统）、详细设计几个环节。详细设计之后软件就变成了一块块模块，这以后才进入编程。 一个软件开发项目通常要经历需求分析、设计、编程、测试等几个大的阶段。其中设计又包括整体设计、系统设计（把整体架构变成一块块系统）、详细设计几个环节。详细设计之后软件就变成了一块块模块，这以后才进入编程。到了编程阶段时，最后就剩下软件蓝领为模块的Coding工作，在印度通常由受过一两年训练的高职毕业生担任。 软件最后的测试又是一个复杂过程——有单元测试（小模块测试）、系统测试（块与块的联系整合）、总体功能测试。期间由测试编程工程师编写测试工具，制定测试规则，其难度不亚于系统框架的制定。最后才由测试工程师完成测试的任务。

需求分析项目名称：公司人事管理系统
一、用例视图写出用例图的介绍，包括功能包、用例的简述等。不少于1000字。
二、用例描述1 Login 英文名称：<Login> 中文名称：<登录> 参与者 ：<User>
11 简要说明 对登录的流程进行描述， *** 作者输入用户名、密码、选择用户类型进行登录。12 事件流 121 基本流 (1) 系统：显示登录界面； (2) 用户：输入登录信息，登录信息包括：用户名、密码、用户类型； (3) 用户：可能进行下面两种 *** 作： (a) 用户：选择登录，则执行基本流(4)； (b) 用户：选择重置，则返回到基本流(1)； (4) 系统：检查用户的登录信息，可能有下边两种情况； (a) 登录成功：执行基本流(5)； (b) 登录失败：执行备选流(1)； (5) 登录成功，结束此用例。122 备选流 (1) 登录失败：如果系统检测到用户名、密码不存在或错误，则提示用户输入的登录信息不正确，系统返回到选择登录前的状态，用户可以重新输入/修改登录信息，重新执行基本流(3)。 13 特殊需求(约束和非功能性需求)
131 第一特殊需求 要求用户密码安全。
14 前置条件 141 第一前置条件 系统已启动到登录界面。
15 后置条件 151 第一后置条件 用户登录成功后，根据用户类型进入到相应界面。Administrator用户进入到管理员界面，Employee用户进入到个人用户界面。 152 第二后置条件 用户登录失败，返回到登录界面。
16 扩展点 没有与此相关的内容。
17 附加说明 171 附加说明1 登录过程要求安全性。
18 优先级 没有与此相关的内容。2 略3 略三、领域模型与用户字典1 领域建模2 用户字典21 Employee实 体 名Employee(员工)说 明公司的一个雇员，具有一定的职务或岗位，按照职务或岗位或工作量领取薪水基本属性编号、姓名、级别、职务、当月薪水实 体 名ID（编号）说 明员工的编号，由系统自动生成。4位阿拉伯数字，例如： 1234从属实体Employee实 体 名Name（姓名）说 明员工的姓名姓名最多8个汉字或16个英文字母从属实体Employee
22 <略><第二条词汇> 的定义在此处提供。应提供读者理解该概念所需的全部信息
23 <第一组词汇>[有时，可利用术语分组来提高可读性。例如，如果问题领域包含与建筑项目的统计和建设两方面都相关的术语（当开发建筑项目管理系统时就会出现这种情况），提供两个不同子领域中的术语会使读者混淆不清。为了解决这种问题，我们采用了术语分组的方法。当提供分组术语时，应提供一段简短说明来帮助读者理解<一组词汇>的含义。为了便于查找，同组内的术语应按字母顺序排列。] [<第一组词汇> 的定义在此处提供。应提供读者理解该概念所需的全部信息。]
四、非功能性需求
1 质量属性性能暂无要求安全性密码安全存储的安全易用性简单易用快捷 *** 作持续可用性程序稳定可伸缩性暂无要求互 *** 作性可更换数据库或存储成标准格式CSV可靠性不易死机测试严格鲁棒性能容忍非法 *** 作易理解性易被开发人员看懂设计文档和代码规范可扩展性能增加功能可重用性系统的类可被重用可测试性易测试可维护性易修改错误、代码易理解可移植性易换平台易换数据库
2 分析后的约束技术C++开发，程序员水平不高平台Win32数据库Csv文件或Access界面风格命令行时间一周其他暂无

给个例子吧：
=================================================================
第3章 功能描述
31 系统管理
系统管理主要是完成目录管理、栏目建设与调整、数据初始化、界面设定与调整、界面修改与增加、主页风格调整及用户权限管理等工作，是系统管理员的一套专用系统， *** 作界面应该以Web界面为主，管理员 *** 作时可以方便的选择相关的管理内容。
建立统一的信息站维护管理系统，各级维护人员（包括信息站维护人员、部门维护人员及其他维护人员）登录系统后，可以根据系统管理员分配的角色进行权限范围内的管理维护工作。信息站维护人员能够方便快捷地维护信息站主页内容、更换信息站主页风格，设置修改信息站主页的各种链接信息，决定待发布的信息在信息站主页是否发布和发布期限；部门维护人员可以修改本部门主页和部门的相关内容。系统管理员可以根据工作需要灵活地修改和设置各公共栏目的维护人员所维护的内容。
在系统和栏目创建与安装或升级时，系统能够在系统管理员的简单干预下，能够进行相应的数据更新。
32 用户管理
注册用户实行实名制，分级管理用户权限，并且按照我行的人员管理制度进行管理。信息站采用一套统一的用户管理机制，用户管理以人为单位， *** 作界面以Web界面为主，系统管理员可以灵活方便的创建和冻结用户，设置和修改用户的角色及权限等相关信息。
321 用户管理过程
用户注册采取用户申请、系统管理员审核批准的方式，申请时需提交个人用户名、真实姓名、性别、行别、部门、科室、职务、邮箱、联系电话等信息，系统管理员核准申请后，按照对应的岗位和应用权限分配列表，对用户进行授权；在用户发生工作岗位变动时，系统管理员确认后，按照权限分配表，调整授权；用户在离职或调离本系统或长时间暂离工作岗位时，系统管理员冻结该用户的所有权限并备案。用户在获取相应的授权后，只需进行一次验证，便能访问信息站中的相关信息，使用信息站的应用和功能以及整合后的其他应用系统的授权部分。新版信息站注册系统具有IP地址管理功能，只有属于本系统预先设置的IP地址范围内的用户可以申请注册。
对相关的部门事务，员工之间和部门之间信息浏览的授权问题：按照每个员工的级别，将其按照部门分组，部门之间不能浏览观看，上级可以看到下级，下级不能看到上级。
322 用户的分类
用户拟分为管理用户、维护用户和用户三类，并根据信息站管理工作需要和功能模块的划分分为7个级别。用户可以根据工作需要，被赋予不同的权限，担当多种角色。
 管理用户
信息站系统管理员：可以管理信息站的全局内容,使用信息站的全局功能，负责信息站新用户的审核，给用户赋予不同的权限和角色。
 维护用户(分为两个级别)
信息站维护人员：维护信息站主页的栏目设置与链接、信息站主页风格、信息站主页栏目内容和部门主页栏目设置，并具有部门、支行、栏目维护人员的权限。
部门维护人员：维护部门主页的栏目设置与链接、部门主页风格和部门主页栏目内容，可以审核、发布、删除、修改文档。
 用户（分为四个级别）
高级用户：可以浏览全部的信息站文档和数据信息，访问和使用集成的相关系统，可发布实名和匿名信息。
普通用户：可以浏览授权的信息站文档和数据信息，访问和使用集成的相关系统，可发布实名和匿名信息。
公共用户（建行ccb用户）：可以浏览信息站公开的信息和内容，可发布ccb实名和匿名信息。
匿名用户：只能浏览信息站匿名公开的信息和内容，可发布匿名信息和浏览匿名信息。
==================================================================

结构化分析中，常用到数据模型为实体关系图，功能模型是数据流图 DFD

可以认为，一个基于计算机的信息处理系统由数据流和一系列的转换构成，这些转换将输入数据流变换为输出数据流。数据流图就是用来刻画数据流和转换的信息系统建模技术的。它用简单的图形记号分别表示数据流、转换、数据源以及外部实体。

数据对象由其属性刻画 实体-关系图是表示数据对象及其关系的图形语言机制  数据对象彼此之间相互连接的方式称为关系，也称为联系。可以是一对一联系(1∶1)、一对多联系(1∶N)、多对多联系(M∶N)联系也可能有属性。

数据流图的功能主要为（1）描绘数据在系统中各逻辑功能模块之间的流动和处理过程，是一种功能型模型 （2）主要刻画“功能的输入和输出数据”、“数据的源头和目的地” （3）在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。它与数据字典一起用来构成系统的逻辑模型。

 数据流图中个个对象的表示一般来说源点与终点：通常指外部对象，用长方形或长方体表示。处理（加工）:可以代表一系列程序、单个程序或者程序的一个模块，还可代表人工过程等，用圆形或圆角矩形表示。数据存储：表示需要保存的数据流向，指处于静止状态的数据，用平行线或开口矩形表示。数据流：指处理运行中的数据，用箭头表示。

数据流图的设计原则：

（1）：父图-子图平衡原则：

子图可以理解为父图中部分环节的细化。例如我们给出父图：

我们想对其中的成绩处理环节进行细化，画成如下数据流图：

其中一定要保证父图输入输出数据流 = 子图输入输出数据流

（2）数据守恒原则：

所有的输出数据流必须是通过加工的，且通过加工能直接产生。一般情况下要注意一下3个错误：

    1 外部实体与外部实体间无数据流。

    2 外部实体与数据存储文件无数据流。

    3 数据存储文件间无数据流。

（3）守恒加工原则：

对于同一个加工，其输入与输出的名字必须不同。通常来说要注意一下2点：

1 对于每一个加工，都应该有输入、输出。

2 数据流与加工有关，且必须经过加工。

在数据流方法中，对数据的精化是伴随着对转换的精化而同步进行的。DFD是自顶向下分解的。顶层DFD图通过系统和尾部世界之间的联机来描述系统的范围，没有数据流图的雏形，只是一种思想的表达，所以也成为关联图。将顶层DFD的系统分解为若干个子系统，决定每个子系统间的数据接口和活动关系，得到0层DFD图，然后继续向下细化，得到1、2、3…DFD图。最后得到的那个叫做底层DFD图，底层的DFD图最为详细， *** 作也是基本 *** 作。参照底层的DFD图来实施。

例如：简单的考务处理系统

有如下的一个简单考务处理系统，要求完成一下工作：

1 对考生送来的报名单进行检查;

2 对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站;

3 对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格标准审定合格者;

4 制作考生通知单(含成绩及合格/不合格标志)送给考生;

5 按地区进行成绩分类统计和试题难度分析，产生统计分析表。

我们对需求进行关键字提取，并用绿色标出实体，红色标出关键的数据流。

答：（1）顶层数据流图：

（2）一层数据流图：

（3）二层数据流图：

例：图书预订系统

书店向顾客发放订单，顾客将所填订单交由系统处理，系统首先依据图书目录对订单进行检查并对合格订单进行处理，处理过程中根据顾客情况和订单数目将订单分为优先订单与正常订单两种，随时处理优先订单，定期处理正常订单。最后系统将所处理的订单汇总，并按出版社要求发给出版社。

答：（1）构建顶层数据流图

（2）构建0层数据流图（细化顶层数据流图）

（3）逐层细化数据流图

本小节主要介绍 产品架构图 的相关知识，整个内容框架分为三个部分，分别是： 产品架构图是什么（what） ； 为什么要画产品架构图 （why） ； 如何画产品架构图（how） ，下文将对各部分的内容做详细介绍。

1、产品架构图的定义

产品架构图是一种将具象产品的业务架构、功能架构、信息架构、技术架构，生态架构以及商业模式等，通过层级划分、模块组合，而设计出的可视化图形，其抽象且精简的表达形式，很适合用来介绍复杂产品体系。常见的产品架构图有业务架构图、功能架构图、信息架构图，以及混合架构图。

有句俗语叫做： 思考常常越复杂，形式往往越简单 。人类历史上许多伟大的知识和定律都是以精简而优美的形式表达出来的，例如亚里士多德的三段论表述、牛顿的三大定律、欧拉的上帝公式，达尔文的进化论表述等。思考的足够通透后，只需要用简单的形式就可以表达复杂的体系结构和逻辑关系，相反很多看似简单的表现形式，背后却承载着巨大的复杂。

对比各种产品输出物（文档、原型图，流程图等），产品架构图的形式最为精简，都是由单一的矩形控件排列组合形成，但却在所有的产品输出物中拥有最高的抽象程度和复杂度，输出产品架构图是对产品经理产品设计能力的衡量和体现。

2、为什么要画产品架构图

在进行产品设计的时候，首先应该输出的是产品功能架构图，思考这张图如何画的过程，是帮助你梳理产品设计思路以及确定产品边界过程。例如，现在让你设计一个CRM系统，可以试着先画出具体业务的CRM系统的功能架构图，在画的过程中，会辅助你思考整个CRM系统有哪些核心功能模块组成，各模块的关联关系是怎样的，每个阶段应该做什么，从而形成完成的产品设计思路。

其次，产品设计的过程就像是盖大楼的过程，输出产品功能架构图就好比是搭建大楼地基的过程，产品原型设计的过程就像是大楼建造的过程，地基没有问题，后面的添砖加瓦就不会有太大问题。如果一开始地基质量就有问题而没有被重视，后续盖了一半发现整个工程出现问题，修复重建则会浪费巨大的资源和成本。所以项目初期产品功能架构图是很重要的交付物，当你要开始设计一个完整的产品方案时，如果跳过画产品架构图的步骤，直接开始画原型、写PRD文档，就很容易发生改了又改，甚至是做了一版需求然后又推翻的情况。

最后，在产品上线后无论是对内普及还是对外推广都需要有高度抽象，简洁易懂的载体来介绍产品整个情况，介绍和推广的不可能去用繁杂的页面和文字去描述，这个时候产品架构图会是介绍整个产品理念，功能和设计的一个很好的传达媒介。

3、如何画产品架构图

上文介绍了什么是产品架构图以及为什么要画产品架构图，接下来要介绍如何画产品架构图，产品架构图的画法主要分为四个步骤，分别是：（1）确定对象；（2）拆解结构；（3）挖掘关系；（4）表达输出。

图5-1产品架构图的画法

（1）确定对象

首先要明确产品架构图描述对象的范围和边界是什么，例如，对于一个CRM系统，要画的是CRM系统的业务架构图、功能架构图、信息架构图、还是综合了多种元素混合在一起的混合架构图。

（2）架构拆解

确定好描述对象的类型后，要对其进行架构拆解，例如，输出一家借贷平台的业务架构图图，可以拆解为贷前业务、贷中业务，贷后业务等。又例如输出一个CRM系统的功能架构图可以拆解出整个CRM系统的功能模块，如账户管理模块、客户管理模块、用户管理模块、权限管理模块，系统设置模块等。

（3）关系挖掘

输出对象的架构拆解完成后，需要发掘出各个模块之间的关联关系，同样以CRM系统的功能架构图为例，在拆分完整个系统的功能模块时，接下来要分析出各个功能模块的关系，产品架构图内部元素之间的关联关系主要有四种：统计并列关系、父子包含关系、辅助支撑关系，底层支撑关系。

（4）表达输出

确定了各个功能模块的关系之后，则需要进行关系表达，层级相同的模块元素，则按照同级并列关系，需要排列在一起。

例如，在CRM系统中，客户管理模块和权限管理模块就属于同层级的并列关系。而权限管理模块和权限分配这个功能模块之间则属于父子包含关系，在表达父子包含关系时，通常父级模块会包含住子级模块。

其次，一些产品的非核心的功能模块或者产品之外的一些功能模块，例如第三方平台的短信功能模块，这些模块对产品自身功能的实现起到了一定的辅助作用，与其他产品功能模块呈现出辅助支撑的关系，辅助支撑模块一边画在产品架构图的右侧。

最后是底层支撑关系，例如产品的 会员体系 是建立在账户体系的基础上的，所以账户体系与会员体系属于底层支撑关系。底层支撑关系的表达方式一般是支撑模块在底下，被支撑模块在上面。这些基本关系的图形化表达方式，会在后面小节结合实际的案例做详细介绍。

整个边界范围内的结构关系表达完成后，整体检查一遍是否有遗漏和错误，检查完毕后配上整个架构图的标题，架构图标题往往是对整个架构图内容的说明，一般放在最上面或者框架左右两边，最终输出完整的产品架构图。

爱因斯坦说过： 如果你不能把一件事情用最简洁的语言描述清楚，说明你还没有理解他。 对于产品架构图而言： 如果你不能用简单的矩形， 通过 排列组合的方式 ， 把一个复杂的产品 结构描述 清楚，说明你还没有真正理解 你做的产品 。 所以，在日常的产品工作中，要培养自己去画产品架构图的习惯，培养抽象思考能力的同时，辅助自己高效的完成产品方案设计。

原文地址：>