销售管理系统需求获取报告

销售管理系统需求获取报告

一、 问题描述

本系统以“订单”为核心，构建出了以“客户”为中心的管理模式。 该系统具有以下一些特征：

（1） 先进的系统结构，面向销售流程，能适应原有销售工作流程并进行合理的改进，从而更贴近实际的应用；

（2） 针对大型企业销售管理人员多，销售管理复杂的特点，通过系统提供的灵活的人员权限设置和全面的财务核算方式，实现真正的销售网络化办公；

（3） 在实现订单的电子化、工作流程的数字化同时，帮助公司领导提高决策的科学化水平；

（4） 通过对客户信息的管理，实现对客户广告走势和重要客户情况统计和分析。

整个系统操作业务人员包括：销售员、销售经理、仓库管理员、审计员、公司销售主管、和系统管理员。各个角色承担不同的系统任务，通过网络和通信系统，连接到销售管理系统，使用统一的访问界面，进行日常的销售业务操作，最终实现销售部门业务的正常运转。 二、 文档概述

我采用的需求获取的方法是情景串联法。由于软件产品的抽象性，大部分涉众在脑海里未有一个清晰的产品轮廓，影响涉众

部分内容来源于网络，侵权请联系删除！

.

对产品的理解。基于此可考虑编写清晰、完整的情景描述文档。

需求场景是一种更接地气的分析和描述用户需求的方法。它应该拥有这样的结构：

“在某某时间(when)，某某地点(where)，周围出现了某些事物时(with what)，特定类型的用户(who)萌发了某种欲望(desire)，会想到通过某种手段(method)来满足欲望。”

将应用场景描述为需求场景，这种讲法更加形象。因为对场景的描述就是一个分析用户需求的过程，解读这个过程可以更容易的对用户需求做出分解并从中找到吸引用户的关键。 三、 计划 1. 分析涉众； 2. 根据涉众分析场景； 3. 思考其它可能的场景。 四、 实施 1. 分析涉众 涉众主要包括：

销售员：销售过程控制，包括订单的增、删、改、查，查看销售量等个人销售业绩；

销售经理：销售总控和主管，控制管理各个销售员以及每个订单的状态；

仓库管理员：仓库余量控制，进货控制，与生产部门的联系； 审计员：查看财务流动，事前事后审计财务；

部分内容来源于网络，侵权请联系删除！

.

人事主管：人事管理，如增、删、改、查销售员，销售经理账号等；

财务主管：财务管理，生成财务报表； 系统管理员：维护系统运行状态稳定；

销售顾问：销售专家，按需再添加顾问的信息与专业回答； 法律顾问：法律援助（注意法律法规，政策意向），按需再添加顾问的信息与专业回答；

开发者：希望系统能有用户使用反馈，便于改进升级系统。 2. 根据涉众分析场景

由于场景比较多，现在只列举典型的场景

(1) 当有新的订单时，销售员希望能通过这个系统增加新订单； (2) 无论销售经理在哪里，都可以通过此系统，实时地动态的看到各个销售员和每个订单以及的状态信息，以及每个客户的需求是否被满足的信息；

(3) 每天都有货物进出仓库，仓库管理员希望可以通过此系统随时查看仓库余量，能提交进货通知，能与生产部门良好沟通。 (4) 从项目开始前到项目结束后，审计员希望通过此系统能看到财务的流动，去向；

(5) 在招聘会到来之前，人事主管可以通过系统查看各个部门的人力资源情况，确定此次招聘职位及人数；

(6) 当月末，季末，年末时，领导希望看到本公司的财务报表，财务主管希望能通过此系统导出财务数据，按自己想要的方式

部分内容来源于网络，侵权请联系删除！

.

组织数据，如营业额按从大到小排序，最后生成财务报表； (7) 当系统发生故障时，系统管理员希望系统能报出故障源，能提出可选的故障处理方案；

(8) 为了方便系统更新，开发者希望系统能输出各个用户的使用反馈，希望系统能输出故障发生的频次，主要的位置等信息； (9) 当销售顾问提供了比较好的建议或者法律顾问提供了值得注意的注意事项时，公司的每个人员都希望系统能让自己存储这些好的建议或注意事项，并能在登录系统后，在个人的主页里显示这些好的建议或注意事项。 3. 思考其它可能的场景

其它场景主要是非功能性的需求。非功能性需求是指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求，包括安全性、可靠性、互操作性、健壮性等。

列举一些主要的非功能性需求：

(10) 当使用过程中，操作的数据量很大时，用户希望系统不会因此“卡死”；

(11) 用户的某些个人隐私资料不希望被其它某些用户查看，所以希望系统对每个用户都分配与现实合理的用户权限； (12) 用户希望自己的一个账号同时只能在一个设备登录系统，防止自己的账号被别人盗取。 (13)

部分内容来源于网络，侵权请联系删除！