基于android的物流客户端的需求分析

1.        引言

1.1    目的

 

1.2    背景

1.3    参考资料

1.4    术语

列出本报告中用到的专门术语的定义。

2.        任务概述

2.1    目标

叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。

2.2    系统（或用户）的特点

如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度；

如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。

3.        假定和约束

列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。

4.        需求规定

4.1    软件功能说明

逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。

4.2    对功能的一般性规定

本处仅列出对开发产品的所有功能（或一部分）的共同要求，如要求界面格式统一，统一的错误声音提示，要求有在线帮助等。

4.3    对性能的一般性规定

4.3.1 精度

说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。

4.3.2 时间特性要求

说明对于该系统的时间特性要求。

4.3.3 灵活性

说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。

4.4    输入输出要求

解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对系统的数据输出及必须标明的控制输出量进行解释并举例。

4.5数据管理能力要求（针对软件系统）

说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储作出估算。

4.6 故障处理要求

列出可能的软件、硬件故障以啊对各项性而言所产生的后果和对故障处理的要求。

4.7其他专门要求

如用户对安全保密的要求，包括信息加密、信息认证（确定穿过系统或网络的信息没有被修改）方面的要求。

对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。

5.        运行环境规定

5.1    设备

列出运行该软件所需要的硬件设备。

5.2    支撑软件

1）操作系统

2）数据库管理系统

3）其他支撑软件

5.3    接口

简要说明该软件同其他软件之间的公共接口、数据通信协议等，

5.4控制

说明控制该产品的运行的方法和控制信号，并说明这些控制信号的来源。

6.        尚需解决的问题

以列表的形式列出在需求分析阶段必须解决但尚未解决的问题

测试计划

7.       1. 引言

7.1 1.1 目的

说明本项目测试目的、预期达到的目标。

7.2 1.2 背景

说明本项目测试的背景。

7.3 1.3 测试范围

说明本项目测试的内容。

1.4 项目文件列表

列出编写本报告及测试整个过程中所要参考的文件、资料。

相关文件列表

8. 2. 测试需求

8.1    2.1 分析各种信息

反复检查并理解各种信息，和用户交流，理解他们的要求。可以按照以下步骤执行：
1）确定软件提供的主要商业任务
2）对每个商业任务，确定完成该任务所要进行的交易。

　3）确定从数据库信息引出的计算结果。

　4）对于对时间有要求的交易，确定所要的时间和条件。这些条件包括数据库大小、机器配置、交易量、以及网络拥挤情况。

　5）确定会产生重大意外的压力测试，包括：内存、硬盘空间、高的交易率
　6）确定应用需要处理的数据量。

　7）确定需要的软件和硬件配置。通常情况下，不可能对所有可能的配置都测试到，因此要选择最有可能产生问题的情况进行测试，包括：最低性能的硬件、几个有兼容性问题的软件并存、客户端机器通过最慢的LAN/WANF连接访问服务器。

8）确定其他与应用软件没有直接关系的商业交易。包括：
　　　　管理功能，如启动和推出程序
　　　　配置功能，如设置打印机
　　　　操作员的爱好，如字体、颜色
　　　　应用功能，如访问email或者显示时间和日期。

9）确定安装过程，包括定置从哪安装、定制安装、升级安装。

10）确定没有隐含在功能测试中的户界面要求。大多界面都在功能测试时被测 试到。还有写没有测到，如：操作与显示的一致性，如使用快捷键等；界面遵从合理标准，如按钮大小，标签等。

8.2 　2.2 需求组织成层次图

9.  3. 测试策略

　

10.4. 测试内容

根据软件项目的实际特点确定确认测试的测试内容。对部分软件项目除基本的功能测试外，可能还包括性能测试、安全性测试、极限测试、并发操作测试等。

1）功能测试

2）用户界面测试

3）性能测试

4）压力测试

5）容量测试

6）配置测试

7）   安装测试

11.5. 资源

 

 

11.15.1 人力资源

11.25.2 系统资源

12.6. 人员安排

6.1 估计测试工作量
　　∑(每个测试的时间*每个需求的测试的数目*测试需求的数目)
　　（测试设计、开发、….）

12.1　 6.2 创建工程调度表

13.7. 附

1)  软件元件

2)  测试特性（Assets）

3)  测试日记

4)  缺陷报告

 

第二篇：软件开发需求分析过程者

软件开发需求分析过程者

软件的需求分析必须要有对原业务的一个深入了解、提取、抽象、升华的过程，管理软件需求分析尤其如此。

软件的需求分析是从用户的业务中提取出软件系统能够帮助用户解决的业务问题，通过对用户业务问题的分析，规划出我们的软件产品。这个步骤是对用户业务需求的一个升华，是一个把用户业务管理流程优化，转化为软件产品，从而提升管理而实现的质的飞跃，这一步是否成功，直接关系到开发出来的软件产品能否得到用户认可，顺利交付给客户，客户能否真正运用我们的产品帮助他解决业务或管理问题。

按照软件工程对软件开发过程的描述，需求阶段我们可以细分为需求调研和需求分析两个小阶段，需求调研需要充分细致的了解客户目标，用户业务内容、流程等，这是一个对需求的采集过程，是进行需求分析的基础准备。当我们已经了解、理解了用户的业务，于是可以开始分析需求了。软件系统的需求分析可以由产品工程师或系统分析员或两者分阶段合作完成全部的需求分析工作。

一、 提取出核心、主要、急迫的业务，明晰业务流程

通过需求调研，我们会发现用户各方面的业务很多，从大处着眼，包括用户的各种业务项目、业务流程，再明细到业务过程的每一个单据，每一条记录，如生产过程中每一个环节的记录，办公中的每一个通知，甚至包括文件报刊的收发，计划生育指标统计等等。如此繁杂的各类业务，我们从何下手？这时需要我们回头去查看软件的项目规格说明书，再次温故客户对软件项目或产品的最初提出的需求目标和范围，我们的软件主要是为用户解决什么样的问题。从众多的业务中提取出用户核心的、主要的、急需的业务，这些是我们软件需求主要关心所在。写一篇文章需要重点突出，主次分明，我以为规划一个软件产品也是同理。

从用户繁杂的业务中进行业务、业务流程的提取，把那些分布在各个部门的同一种业务提取出来。比如物资的管理，涉及到生产部门的需用计划，汇总到物资部门的采购计划，计划的审批，采购合同，物资采购，物资部门的收发存业务，生产部门的物资领用消耗等等，我门需要分析用户的这个业务流程中哪些是系统能帮助管理的，哪些是要在系统外处理的，充分分析了用户现有的业务和业务流程，我们进入下一步骤。

二、 运用管理思想，优化业务流程

我们提供的是管理软件产品，要帮助用户解决的是管理问题，那么用户是这样的业务流程，就需要我们分析这样的流程合理吗，还有缺陷吗，怎样做能提高效率、解决问题，可以运用更先进的管理思想吗……。一般情况下，我们需要从两个方面考虑业务流程的优化。一是我们采用了网络计算机这些新的技术手段，较之原先手工、电话等方式在信息的传递、信息的共享、数据的处理等方面将会带来新的方式，必将改变原有的业务流程。另一方面就是我们根据对用户业务的理解，考虑是否可以运用先进的管理思想，比如MRPII、ERP、SCM、CRM、JIT、EIA、E-Business等等管理模型，进行现有业务流程的重组或优化。当然一旦牵涉到

业务流程的修改一定要与客户的中高层管理者进行充分的沟通，只有客户认同方可确定，因为这一定会在软件实施时需要相应的管理制度配套执行。

三、 进行业务分类，规划系统蓝图

以上都明确了以后，我们可以描绘系统蓝图了。系统有几个子系统，每个子系统有哪些模块，各个模块处理哪些业务，很重要的一点还有各子系统模块之间的数据接口关系，基础数据从哪里进入，通过哪些处理生成哪些结果等等。这个过程需要整理、抽象用户业务，规划软件实现，规划软件系统模块间的逻辑关系。因为系统的页面实现是按照系统模块的规划，所以应尽量采用用户易理解、熟悉的方式、词语进行模块的描述。例如ERP系统中的物资管理子系统，首先明确这个子系统是ERP系统中进行物资相关的业务处理系统，同时它为主生产系统、成本管理子系统提供生产物资供应、领用消耗核算等的数据支持。因此在规划子系统模块时，按照业务过程模型，应包含物资需用计划、物资采购计划、出入库管理、库存管理等主要业务模块，再考虑软件运行必须的初始数据设置，增加一个基础信息维护模块(包括物资大类、物资编码等信息维护)，还有考虑到不同用户对此系统的不同需求，如更多的生产人员、管理人员的需求，再单独增加一个综合查询和分析模块。另外还有与物资采购相关的业务如采购合同，可以放到合同管理子系统统一考虑，这里只做查询。这样规划出了软件系统对物资管理业务的处理，检查一下是否包含了物资管理中所有核心、主要的业务，这时我们发现还有比如物资采购、验收、盘库等业务还是需要物资管理业务人员来完成，系统可以做到的就是记录结果。软件系统是管理的辅助系统，不能完全代替人的所有工作。管理软件再加上管理制度、业务人员的操作才构成一套完整的管理体系。

四、 详细描述软件功能点

规划出了软件的功能模块，只是软件的功能框架结构，下一步就需要明确描述每个模块的具体内容了。包含什么内容、能做什么操作，每一个功能点的说明、优先级、业务规则、详细功能描述等等。这些也是软件需求规格必须描述的内容。

需求分析的表现方式，我们现在采用需求规格文档，UML语言描述的用例图、类图、活动图，还有实体关系图、界面原型等等，从不同角度、不同需求描述规划出的软件全貌。

五、 需求分析的质量控制

软件需求分析直接关系到软件产品的方向，所以需求分析的质量至关重要。对于这个关键点的质量控制，则可以通过内部评审和同行评审的方式，然后是客户方的评审。项目组内部评审或同行评审主要是根据公司规范和评审人员本身的经验对需求分析中不明确、不合理、不符合逻辑、不符合规范的地方予以指正。而客户的评审主要是对描述的软件实现是否真正符合他们的需求，能否帮助他们解决问题等方面作出评定。

软件的需求分析必须要有对原业务的一个深入了解、提取、抽象、升华的过程，管理软件需求分析尤其如此。