浅谈软件项目需求分析

       这里不是写标准化的理论知识，而是想写写对软件需求工作的感受。
        理论上的需求管理是要解决系统需求做什么的问题，以此界定系统功能和非功能性的内容。需求指的是由项目接受的或项目产生的产品和产品构件需要，包括由组织征集的对项目的需求，说通俗了，就是使用者真心想要的。
        需求管理的目的是确保各方对需求的一致理解；管理和控制需求变更；从需求到最终产品的双向跟踪。
从工程的角度理解需求，包括如下内容。

        需求获取本身不纯粹是一个技术的话题，按本人的理解它更涉及于市场和人际关系的内容，需求来源于其他的人、机、系统等。我们一般通过对客户单位进行调研获得，也可以通过第三方机构获得，也可以通过有经验的人获得。需求获取是要讲究策略的，如果您需要找他人了解需求，那么首先是能取得他人的同意取得他人的信任，让对方愿意给您介绍，然后是了解的方法，在有限的时间内尽可能多的了解到需求。

 

        需求调研是要讲究方法的，你需要在很短的时间内尽可能多的了解到用户的需要，有时我们要对一个大规模的企业业务进行调研了解，业务涉及方方面面的，而调研的时间只有一两天，那么我们一般是从一个企业的组织机构入手，了解企业的组织架构，各岗位的职责，所需要的数据表单等。第二部分是了解具体的业务流程，各环节的使用者操作者，如需要的数据是什么，以此逐步行成业务模型。调研的方式有访谈、参与现场工作等。
        资料搜集是通过各种渠道搜集与系统需求相关联的资料，当我们没有调研的机会，只没有与客户交流的机会时，我们就需要从其它各方去搜集资料，包括标准规范、管理制度等。
        不管是调研也好，搜集资料了罢，若要寻求到最佳答案，掌握到关键需求细节，已不仅仅是一事技术的问题，也不仅仅是一个管理的问题，而是包括了营销的问题，处理人员关系的问题综合管理体系。
        如果以上我们直接取得需求是困难的，那也可以寻求第三方的帮助，可以是咨询单位，可以是顾问团队，或是有类似系统经验的企业，通过他们在没有与客户或使用方接触的基础上掌握到需求。
        需求总是存在的，需要我们不断地挖掘。客户不会直接告诉你的需求细节，也许他只知道自己目标，有些想法，但并不与系统相关，或者阐述不是清楚到底是要个什么。那么就要我们的一套理论来甄别来深入挖掘出需求。
       需求分析与评估
        当我们获到足够的需求后，那仅仅还是用户的一些想法，以及业务上的一些业务信息。我们还不能拿来指导后面的系统设计，甚至还不知道哪些要进入系统的范围。需求分析的目的是要把系统需要的鉴定清晰,我们用需求分析报告或用户需求说明书来描述，然后系统化化的分析方法方法转化为可以指导设计和开发的软件需求规格。这一部分的内容是系统分析师要考虑的。系统分析是比较专业的岗位，那么我们来看看系统分析师要所要具备的技能和所做的工作吧。
        系统分析师职责:告诉我们系统应该做什么。

• 管理到技术的桥梁  各领域业务到信息化技术的通知翻译者。
• 对软件项目进行整体规划。
• 业务分析，理清业务的各个环节，并形成分析报告，形成业务模型。
• 需求分析，抽象出软件所要实现的目标，功能，形成软件规格说明。
• 描述软件的核心思想，设计最顶层的架构。
• 指导和领导项目开发小组进行软件开发和软件实现，
•  对整个项目需求的实现进行全面管控。
• 项目成本、工作量、经济分析。

      系统分析师技能

• 沟通协调能力强;
•  领导才能;：能够导引后续工作走向正确的路。
• 熟悉应用领域业务知识：应用软件分析必将是应用领域的专家。
• 文档编写能力；
• 开发方法和工具选择决策水平；要有战略意识、战略眼光；
• 项目管理技能；
•  熟练应用各类分析工具；
•  项目风险评估水平
•  项目运维知识；
• 随时把握IT时代脉搏，掌握IT最后动态，了解新技术。
• 网络知识；
• 计算机软、硬件知识；
•  数据库知识；
• 质量保证；
• 经济分析水平；
• 相关法律知识。

        需求管理: 
        需求明确下来之后，我们需要管理一个实现需求的过程，这是一个完整的软件开发过程。包括设计、开发、测试、部署安装、上线。在需求的完成过程中我们需要对过程进行跟踪，实时掌握状态，过程监控采用需求跟踪矩阵来完成，通过它可以了解到每一功能需求点的设计、开发、测试节点进程。
需实施过程中，出现在需求变更是很常见的，信息系统是智力型的产品，将人类各种思想和知识封装到软件中，人的思想是活跃的，社会是在发展变化的，所以反映这个世界的信息系统当然也是不断的变化的，或是因为客户考虑不到，或是实施过程中才发现路走不通。我们甚至可以将软件开发之初就进行维护阶段，软件从实施初始到寿终正寝整个过程都是一个变更和维护的过程。变更是客观存在的，只是变更需要控制，尽量避免。我们要对新问题点和需求点进行评估，评估要考虑的因素很多，有费用方面的，有对原系统的影响方面的，有可用性方面的，有兼容性方面的等等。每一次变更达到可用时，就形成一个新的版本，所以我们需求给版本定义迭代的内容。

        以上是需求在软件工程整个过程中各个环节的传递过程，每一个环节都需要进行管理控制，否则用户当初对桌子的需求最后会变成了一张床。
       我参与过的项目正，需求的获取分析工作中遇到各类情形，总节出几类觉的情况。
客户全过程参与：当你在准备建设一个信息系统页有客户人员全程参与时，那是一个非常幸运的系统。你将很轻松的获得系统需求。
  
        有现场调研机会：通过个人或公司 关系，当客户单位允许你进行现场调研时，那你也是非常幸运的，现场有机会了解客户单位的业务，这对系统来说就往前走了一大步。调研也是要有方法的，要能够在最短的时间内最大化的获取需求。
 
       没有需求调研机会：这是一个有关工程建设管理的系统，客户是一个集团公司，也是我们的间接上及单位。他们没有太多的时间给我们介绍他们需求甚至任何想法，他们只需要一个系统来解决这个工程项目过程中的信息化，其它你都是你要做的事，你要四处想法获取需求，你要了解工程管理的业务，还算幸运，我们从客户单位要到了一些管理制度，那个我们就从他们的管理制度开始。梳理业务、过程中不断到网上寻找一些问题条案，四处打听寻解。
        引领时代的系统：这是一种大众化的软件系统，比如公众互联取网平台，没有所谓的客户单位，只有用户个体，这人就要进行市场调研，通过产品经理的敏锐的头脑，抓住问题点，把握用户的需求要点，以期提高系统的可用性。
软件需求理论本就没有一成不变的公理定律，体现的只有在这个岗位之上人的智慧。