项目需求分析报告

                              

目   录

1．引言... 3

1.1编写目的... 3

1.2项目背景... 3

1.3定义... 3

1.4参考资料... 3

2．项目概述... 4

2.1产品描述... 4

2.2系统功能... 4

2.3用户特点... 4

3．功能需求分析... 5

3.1系统功能模块... 5

3.2系统业务流程图... 5

3.3 系统中实体的详细说明（ER）... 6

4．其他需求描述... 6

1．引言

1.1编写目的

此系统是为中小型药品流通公司进行日常业务管理而开发，但开发者和用户之间的行业、领域差异，使得开发者和用户对此系统功能的理解存在一定的差别。为了能使开发者明白用户的目的，开发出让客户满意的系统，更好地实现用户的要求；同时也为了用户能清楚地知道此系统的功能和作用，所以要进行需求分析，并以文档的形式来记录。通过需求分析报告，开发者与用户之间的沟通更为方便，也有利于开发者充分分析客户的需求，从而开发出具有功能强大，客户满意的系统。

1.2项目背景

a． 待开发的软件系统的名称：药品信息管理系统

b． 本项目的任务提出者为中原工学院信息商务学院；开发者为胜超、冯军浩、赵庆合、陈奇奇、魏莉、徐鹏鹏、曹松松。

c． 该软件系统同其他系统或其他机构的基本的相互来往关系：通过此系统，可以与财务管理等系统来共同完成医院的日常药品管理工作。

1.3定义

E-R图：E-R图也称实体-联系图(Entity Relationship Diagram)，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。

Power designer：Power Designer 是Sybase公司的CASE工具集，使用它可以方便地对管理信息系统进行分析设计，他几乎包括了数据库模型设计的全过程。利用Power Designer可以制作数据流程图、概念数据模型、物理数据模型，还可以为数据仓库制作结构模型，也能对团队设计模型进行控制。

1.4参考资料

[1] GB-T_8567-1988计算机软件产品开发文件编制指南

[2]《医药进销存数据库管理系统的报告》，2008.09

[3]崔巍，数据库系统及应用（第二版），北京：高等教育出版社，2003.07

[4]吴中、朱君璇等，信息系统分析与设计（第一版），北京：清华大学出版社，2011.10

2．项目概述

2.1产品描述

该药品信息管理系统的功能包括基本信息管理、药品进销存业务管理、系统维护等三个基本的模块。通过以上三个模块系统管理员除了可以查询药品信息、员工信息、客户信息、供应商信息、某一时段药品入库信息、某一时段药品销售信息还可以修改和删除药品或员工的信息，而员工只能查询信息不能修改或删除信息。

2.2系统功能

根据中小型药品流通公司的实际需求， 要求本系统具有以下功能：

①  统一友好的操作界面，保证系统易用性；

②  规范完善的基本信息设置；

基本信息包括：客户信息、药品信息、员工信息、供应商信息；这些基本信息都会以基本表的形式存在于系统中。

③  全方位多功能的信息处理；

    对于上面的基本信息，系统管理员可以进行增加、删除、更改、查询信息等处理，而其他用户只能查询信息，不能对信息进行其他操作。

④  连续录入式的用户添加及维护；

公司内部员工可以凭借自己的员工编号在系统中注册，注册成功后可以查询有关信息。非公司内部员工不可以注册，以便与维护系统的安全。

⑤  对药品的采购、销售、盘点等数据信息进行全面的管理。

药品的采购入库单、销售单和库存盘点存在于系统进销存业务管理模块，通过这个模块可以查询某一时段公司的采购情况、销售情况以及现有药品库存情况

2.3用户特点

此系统的最终用户为最终用户为中小型药品流通公司的药品管理员。

此系统最终将直接面对医务人员，而用户可能在其自身领域内经验丰富，但面对一个其他领域的事物时，可能就不具备使用或操作的经验。这就要求本系统在使用时要尽可能的简单方便。系统管理员虽然可不具备计算机领域的相关知识，但是要经过有关技术人员的培训达到可以操作并熟练使用此系统。

3．功能需求分析

3.1系统功能模块

 

3.2系统业务流程图

3.2.1采购入库业务流程图

 

3.2.2销售出库业务流程图

3.3 系统中实体的详细说明（ER）

     该系统中的实体有：供应商、订单、员工、客户、销售员、仓库。系统E-R图使用power designer工具设计。

4．其他需求描述

    新系统可以设置不同的访问权限，用户单位为了安全可以针对不同级别的用户来设置不同的访问权限。用户使用系统时操作简单方便，同时系统具有可维护性、可补充性、易读性、可靠性等。

 

第二篇：怎么做项目需求分析报告

项目需求分析，看了听棠的“客户需求何时休”，深有感触，何曾自己不是被这个问题整天困扰：客户需求，为什么总在变阿？做项目真辛苦阿！这样的感叹整天都挂在口上。客户需求变动确实是一个软件开发永远不变的话题。为什么小的软件企业面对经常变动的需求是如此的狼狈？到底要怎么做才能满足客户的需求？

听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。

需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。其实，都是缺乏分析所一手造成的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。

听棠所说到的几点，感受特别深：

“其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析”

“客户本身是不怎么懂技术的，客户只知道自己的业务需求，而在软件设计时，是在把业务需求抽象到系统中实现的，把业务转变为逻辑时，一切都应该符合逻辑的，但客户的业务思想有时候在软件系统实现时会有问题的，这就需要分析时分析出来的。少了分析，问题也会在后面的开发中暴露出来，到时可就更麻烦了。”

还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。

项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。

客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。这其实也体现了系统的扩展性。

需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。我们拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。

谨记一点，需求是经常变动的，只有先做好需求的分析，了解业务以后的发展趋势，做好具有拓展性的系统设计，才会给系统更大的扩展空间，从而在需求发生变化的时候可以更从容的修改。