数据库需求分析报告如何做需求分析

系统的需求分析怎么做？

个人认为需求分析要根据你所设计的程序的使用方（即客户）的要求来定，通常有： 1.要考虑到系统的应用性，要求有良好的人机界面。

2.原始数据修改简单方便,支持多条件修改 3.方便的数据查询，支持多条件查询; 4.删除数据方便简单，数据稳定性好； 5.数据计算自动完成，尽量减少人工干预; 6.强大的报表打印功能; 7.退出系统

系统需求分析报告的用途？

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

开发软件系统最为困难的概念性工作便是要编写出详细的技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。

对于我们开发人员来说，编写出完美的需求文档，对于项目的开发有着重要意义，一方面我们可以和通过它客户交流去不断地完善系统设计，另一方面，先将需求报告定稿之后再进行开发可以很大程度上避免返工，毕竟重新编码的代价远远超过重写一份需求文档的代价。

仓库管理系统需求分析

原发布者:klss暖 仓库管理系统需求分析报告1需求分析1．1系统的目的货物仓库管理系统主要针对于日常库存信息的管理，它针对仓库日常发生的业务，分为了两大类，即入库和出库，用户通过相应的模块，对仓库里的物品的基本情况进行操作，对库存数量进行查询，用户通过简单的操作即可轻松的管理仓库。

1．2系统功能及用户需求分析1．功能需求（1）系统功能包括　：产品入出库登记、确认入出库信息、删除库内信息、借出信息登记、产品分类管理、，报表生成，事件记录，数据检测、数据警告。

（2）系统管理员功能：添加人员、删除人员、查询库内信息、系统配置、查看系统事件，用户管理，人员权限区分。

（3）用户功能包括：查询库内信息、查询出库信息、查询入库信息、修改本用户密码。

2．用户需求根据用户需求，该系统应该实现以下功能：（1）进、出库管理。

对进、出库信息进行记录。

（2）查询功能。

仓库管理对查询要求高，通过主菜单记录当前操作用户的用户编号，保证了对进、出库信息录入负责人的确认。

（3）部门资料管理与库存报表生成。

资料管理包括了人员信息管理，财政支出信息管理，以及各项业务单据的资料管理。

报表主要分类为：日报表，月报表，销售报表，入库报表等等。

（4）应用计算机管理后，由于计算机能存贮大量的数据，而且数据只要一次存入，便可多次重复使用，所以管理数据达到完整，统一，原始记录能保证及时，准确。

（5）应用计算机管理后，许多重复性的工作，都可由计算机去执行，从而使管理人

简述数据库需求分析阶段的主要任务以及系统分析报告的主要内容

数据库需求分析阶段的主要任务：对现实世界要处理的对象（组织、部门、企业）等进行详细的调查，通过对原系统的了解，手机支持新系统的基础数据并对其进行处理，在此基础上确定新系统的功能。

系统分析报告的主要内容：1.系统概况，系统的目标、范围、背景、历史和现状；2.系统的原理和技术，对原系统的改善；3.系统总体结构域子系统结构说明；4.系统功能说明；5.数据处理概要、工程体制和设计阶段划分；6.系统方案及技术、经济、功能和操作上的可行性。

如何做需求分析

随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。

网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web 服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。

）等项目管理中。

按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制： 1. 需求分析及变更管理 2. 项目模型及业务流程分析 3. 系统分析及软件建模 4. 界面设计、交互设计及程序开发 5. 系统测试和文档编写 6. 客户培训、技术支持和售后服务 需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。

（一）如何做好需求分析及变更管理？ 业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。

项目是以客户的需求为中心，而不是为技术而迁就需求。

一：让客户畅所欲言，罗列出所有的需求 让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。

这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。

很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！ 二：透过现象分析潜在的需求 很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。

客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。

比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下了更好的基础。

笔者曾负责一个大型新闻网站的设计，当客户拿着将近五十页厚的一本设计要求报告时，我发现有四十页的内容对程序开发来说都是重复的，而在其中一页的角落却画了个“搜索其他网站相关新闻”的按钮，并且没有做任何说明，仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作，客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发，通过协商，客人同意了修改成站内搜索的引擎。

三：利用自然的语言描述项目模型 在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然的语言进行描述，虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。

对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。

请比较以下两份关于需求的描述， “用户在访问首页的时候可以在点击‘客户通道’按钮，弹出填写‘用户名’和‘密码’的窗口，输入正确后在新窗口打开客户通道的首页，在该页显示所有可操作的功能的导航条和最新的导读新闻链接列表 。

” “站点分为公开和加密两种状态，通过身份验证机制使特有的用户可以访问到加密信息，并提供不同于普通用户的功能。

” 前段描述我们就很容易想象的出来设计完成的网站是什么样子，而后一段的描述可能会做出无数不同的版本，造成对需求理解的歧意。

四：利用示意图和图表将用户的需求表现出来 需求分析无论文字上怎么样表述都还是抽象的，对客户而言理解毕竟是困难的，将基本确定的需求制作出示意图是最直观有效的。

制作示意图可以有很多种方式，用PowerPoint或Visio制作流程示意，用Html文档制作界面示意都是可行的，最简单利用画图和Word表格方式也完全可以，关键是利用示意图将客户的需求和即将开始设计的系统体现起来，在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，换言之，就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时客户更容易地参与到项目的开发过程，保证项目往正确的方向进行。

在RUP中有这样的描述： 利用电影、卡通、图片、表格和动画片等制作示意图开始，告诉我们用户是谁，要发生什么事情，如何发生。

以用户友好的方式帮助收集并改进用户需求。

鼓励更有创造性、更加创新的设计解决方案。

鼓励团队复审，并避免所有人都不希望出现的特征。

确保以可理解、直观的方式实施特征。

使访谈过程变得轻松，避免出现访谈没有结果的现象。

简单地说，制作示意图就是使用工具向用户 (主角) 说明（有时是动画演示）系统如何适应组织的需要，并表明系统将如何运转。

协调员将初始示意板展示给小组，小组成员提供意见。

之后，在举办研讨班期间，示意板也进行“实时”演进。

所以，您需要一种可以轻松更改示意板的画图工具。

为了避免分散注意力，一般最好使用简单的工具，比如图表、白板或PowerPoint。

五：什么人要看需求分析报告 项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析，并进行共同的讨论，达成一致的意见。

我们经常会遇到业务人员辛辛苦苦谈下来的项目，对开发人员来说却是难以实现的，而技术人员设计的产品却常常得不到客户的认可，甚至发生纠纷，因此参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定项目实现的目标。

例如： 项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期。

开发周期的限制和功能上的要求可能会影响到程序员采用什么样的语言和工具进行编写； 操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度； 界面设计人员根据项目的性质和定位确定表现方式。

测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测； 通过下表，我们可以看的出不同角色根据需求的变更所进行的工作流程： 六：建立需求变更日志，制作新版本的需求分析报告 尽管我们费了许多功夫在需求分析进行了最大可能的努力，但几乎可以肯定的是，这份需求分析在开发过程中一定会发生变化，也许是出自客户的遗漏，也可能是在开发过程中被激发出来的，这种变更有时是如此的频繁和琐碎，以至于往往不能将变更及时反馈到项目的各个角色中，那么做好需求变更日志就显得非常重要。

在需求分析后面附上变更日志，并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。

在新版本的需求分析中，将变更多部分用特殊方式表明出来，并在日志中记录变更多重的明细。

关于需求分析和变更管理可以参照下图示意： 七：本阶段重点工作角色 在需求分析和变更管理的过程中，工作量最大的角色为客户代表、业务员和项目经理。

客户代表提出需求，业务员帮助整理和分析，项目经理对整个项目进行评估。

在实际工作中，很多项目失败的起因都和需求分析有关。

客户代表和业务员通常并非从事技术开发的专业人员，在讨论需求的时候往往对项目的技术难度、工作量、时间进度把握不准确，这时候需要项目经理或技术人员进行参谋。

为了降低项目的风险，提高工作效率，有必要设计规范的需求管理计划书，帮助客户代表和业务员更好的完成任务。

以下提供一份需求管理计划的模板可作为参考： 八：总结 根据笔者的经验，要尽快做好需求分析掌握以下要点，也许能事半功倍： 仔细聆听，罗列客户的所有要求； 将需求进行分析，确认可操作的系统模型； 利用最自然的语言将系统进行描述，使每个开发人员不会产生歧意； 迅速确定网站的用户角色； 比如访客、会员、重要客户、前台管理员、网站管理员、业务员等； 分析确定每个角色的权限及可操作的功能； 比如会员可以查看特别信息、修改个人信息、退出登陆等； 前台管理员能够登录管理系统，能够发布编辑修改信息，能够审查会员资格等； 网站管理员可以更改栏目、修改网站界面等； 制作流程图和示意图将需求表现出来； 让客户参与到示意图的设计中，及时正确的反应出需求变更。

制作需求变更日志，保留升级版本，通过版本控制进行需求管理； 通过需求《管理计划书》使每个参与人员看到共同的努力目标。