软件需求与分析需掌握的内容

 

1.准备相应文档

开发商方的系统分析人员同用户的需求提供人员正式接触前，完成一个问询表及需求分析计划。
一般情况下只需要完成一个整体细节问询表，问询用户为明确需求已经完成的文档情况（如果可以在进行正式接触前可以得到并了解完成最好）、业务目的、当前目标、长远目标、当前准备情况、完成的业务功能列表、将来系统操作人员的业务及电脑技术了解情况、最终操作用户、当前及将来的硬件、软件及网络环境等问题。
由开发商系统分析人员根据对业务的了解程度，适当编写各业务功能细节问询表。不过业务功能细节问询表的使用，是在业务需求调研过程中用户表明其需求后，再根据问题还没有明确的情况下再进行问询的。
其他业务相关政策法规、技术文档、技术支持人员的通信录等也要进行相应的准备。

 

 

 

2. 调研过程

    调研的过程推荐开发商系统开发人员有专人进行会议记录，并在每日会议结束后，当场宣布本次会议的结果，并由参加会议人员进行签字。第二日复印或发送电子文件给参加会议人员及相关人员。以便做到有据可查，明确过程。
开发商系统开发人员每周对用户提供开发周报，告诉用户当前开发的进展、是否有问题、是否用户协助等，这是一个好的加强双方沟通的方法。
注意：在调研过程的中系统开发人员的变更会对计划产生重大的影响，不要简单认为是人员更换的问题。因为在调研过程中对业务的理解，不是通过看看文档就可以达到。3天通过讨论达到对需求理解的程序，9天对文档的学习也不一定能达到。

 

3 一般情况下需明确的问题

当前整体业务需求的目的
要求提供的需求功能列表
将来发展的设想
明确服务器、客户机的软、硬件及性能要求（容量、速度、可操作性等）
用户目前相关的技术人员和业务人员情况
将来最终系统操作人员的技术及业务人员情况
用户需求的系统及用户本身或其它系统的接口要求
用户的其它要求

4 需求分析的方法

1. 绘制系统关联图，这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。
2. 创建用户界面原型，当开发人员或用户不能确定需求时，开发一个用户界面原型——一个可能的局部实现，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。
3. 分析需求可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
4. 确定需求的优先级别，应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。
5. 为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
6. 依据分析阶段确定合适的客户方配合人员。

5 完成需求确认

    对于需求最终的确认需求先由系统开发人员对编写的文档进行内部审核及修订，然后交由用户业务人员进行确认，明确系统开发人员已经了解业务需求，并进行签字确认。

 1. 整体需求不变，具体细节变化。

 2.  界面风格与操作易用性是最容易发生变更的。

 3.  增加其它功能。软件是对现实的模拟，而现实也是复杂多变的。

                                                                                  软件需求