需求分析

工作自由（项目）：www.worksolo.cn 什么是需求分析 需求分析也称为 软件需求分析 、系统需求分析或需求分析工程等，是开发人员经过深入细致的 调研和分析 ，准确理解用户和项目的 功能、非功能（性能、可靠性） 等具体要求，将用户非形式的需求表述转化为完整的 需求定义 ，从而确定系统必须 做什么 的过程。可能很多人已经了解了需求分析的过程，这里补充一点：需求分析包括 竞品分析 ： 了解竞品、分析竞品、对竞品的功能进行微改造并加入自己的功能，这也是周鸿祎经常说的“微创新”，创新的过程不一定是全新的，可以是逐步迭代，小步快跑的过程。 这里列出一些可能的竞品，如果后期发现不合适将定期修改删除掉（关键的思路是：在家办公、远程办公、自由职业）： 钉钉：提倡远程 企业微信：类似钉钉，远程办公 BOSS直聘：参考招聘功能 拉勾网：参考招聘功能 自由人： http://www.freemancn.com/ 自由职业功能 如果你有看到其他竞品，麻烦发评论告诉我 看到上面两个知名竞品有人不经会问，如果你如何竞争过阿里和腾讯的竞品呢，人力物力不可比，当然以上竞品的思想和这个项目有类似的地方，但我们的方向是完全实现远程办公，让更多公司加入到这个行列中来，甚至有人来这个平台开一家虚拟公司（也可以是现实注册的公司），让更多人加入进来协作，而不是只是在已有的企业中倡导远程办公

需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题。 　　有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 　　本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 　　 1 什么是软件需求和需求工程 　　1.1 软件需求的定义 　　在IEEE软件工程标准词汇表(1997年)中定义软件需求为： 　　1）用户解决问题或达到目标所需的条件或能力。 　　2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 　　3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标

如何对需求不确定的创新产品进行分析和设计？ 众所周知，需求问题是造成软件工程项目失败的主要原因，能否开发出高质量的软件，很大程度上取决于对要解决的问题的认识，以及如何准确地表达出用户的需求。 需求分析的方法： 结构化分析方法 结构化分析方法是最经典的面向数据流的需求分析方法，适用于分析大型的数据处理系统。 结构化方法以数据流分析作为需求分析的出发点，任何信息处理过程均看成是将输入数据变换成所要求的输出信息的装置。而当分析人员面对一个复杂的问题时，结构化分析的策略是基于问题分解的观点，用抽象模型概念，按照软件内部的数据传递关系，采用自顶向下、逐层分解技术，知道找到满足功能需求的可实现软件元素为止。 该方法的特点是使用数据流图来帮助人们理解问题，对问题进行分析，即利用图形工具来模拟数据处理过程。 原型法 原型法改变了系统的分析、设计和实现三个顺序阶段的观点，改变了传统的自顶向下的开发模式，降低了软件需求的风险，因此得到了广泛的应用。 原型法在获取一组基本需求说明后，通过快速分析构造出一个可运行的、满足用户基本要求的软件系统的架构，通过运行原型系统，使得用户通过亲身感受得到启发，提出具体的要求和评价。然后开发者根据用户的意见对原型加以改进。随着不断运行原型、评价和修改，获得新的原型版本。如此周而复始，逐步澄清模糊概念和误解，明确各种需求细节，适应需求的变更，从而提高了最终产品的质量

如今，软件开发越来越复杂，软件功能也越来越丰富。而几乎所有成熟的商业软件，都是靠一个开发团队齐心协力的血汗结晶。“罗马不是一天建成的！”，当我们震撼于Microsoft Windows的惊世巨著的同时，也道听途说了微软公司软件工程是如何的完善规范。的确，集数百名员工几年的共同努力之大成，软件项目管理的成败是控制开发成本的关键环节。这里面，少不了贯穿其中的重要步骤----软件文档。 　　软件文档可以分为开发文档和产品文档两大类： 　　开发文档包括：《功能要求》、《投标方案》、《需求分析》、《技术分析》、《系统分析》、《数据库文档》、《功能函数文档》、《界面文档》、《编译手册》、《QA文档》、《项目总结》等。 产品文档包括：《产品简介》、《产品演示》、《疑问解答》、《功能介绍》、《技术白皮书》、《评测报告》、《安装手册》、《使用手册》、《维护手册》、《用户报告》、《销售培训》等。 一、开发文档 　　1. 《功能要求》--来源于客户要求和市场调查，是软件开发中最早期的一个环节。客户提出一个模糊的功能概念，或者要求解决一个实际问题，或者参照同类软件的一个功能。有软件经验的客户还会提供比较详细的技术规范书，把他们的要求全部列表书写在文档中，必要时加以图表解说。这份文档是需求分析的基础。 　　2. 《投标方案》--根据用户的功能要求，经过与招标方沟通和确认，技术人员开始书写《投标方案》

软件需求规格说明书模板 修订历史 版本 说明 编制 批准 批准日期 1.1 初次编写 SEPG 目　录 1. 引言 1 1.1. 背景 1 1.2. 参考资料 1 1.3. 假定和约束 1 1.4. 用户的特点 1 2. 功能需求 1 2.1. 系统范围 1 2.2. 系统体系结构（二层架构的系统可剪裁本小节） 1 2.3. 系统总体流程 2 2.4. 需求分析 2 2.4.1. XXXXXXX(功能需求名称) 2 2.4.1.1. 功能描述 2 2.4.1.2. 业务建模 2 2.4.1.3. 用例描述 3 2.4.1.4. 用户界面 5 2.4.2. XXXXXXX(功能需求名称) 5 3. 非功能需求 5 3.1. 性能要求 5 3.1.1. 精度 5 3.1.2. 时间特性要求 6 3.1.3. 输人输出要求 6 3.2. 数据管理能力要求 6 3.3. 安全保密性要求 6 3.4. 灵活性要求 6 3.5. 其他专门要求 6 4. 运行环境规定 6 4.1. 设备 6 4.2. 支持软件 7 4.3. 接口 7 4.4. 控制 7 5. 需求跟踪 7 6. 签批单 7 1. 引言 1.1. 背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.2.

传统需求分析 一、生命周期 传统软件工程的6个软件生命周期阶段 软件定义 需求分析 软件设计 编码 测试 运行与维护 二、传统软件过程需求分析阶段的任务 确定对系统的综合要求 分析系统的数据要求 抽象并确立目标系统的逻辑模型 编制软件需求规格说明 三、传统需求分析任务 （1）基本任务 回答“系统必须做什么”？确定目标系统功能和性能。 （2）具体任务 确定对系统的综合要求:功能要求;性能要求;运行要求;将来可能提出的要求 分析系统的数据要求:E-R图(概念模型) 导出系统的逻辑模型:数据流图，数据字典，加工处理说明书等 修正系统开发计划 开发原型系统：使用户对目标系统有一个更直接、更具体的概念，从而能更准确提出用户需求(关键的困难在于成本) （3）综合要求（功能要求、性能要求、运行要求） 功能要求包括系统应该实现的功能 性能要求包括系统的响应时间、资源限制、数据精确性、系统适应性等 运行要求包括系统硬件环境、网络环境、系统软件、接口等的具体要求 其他要求报刊安全保密、可靠性、可维护性、可移植性、可扩展性等 （4）分层数据流图（五原则） 连续性一定有 局部文件一定有 外部文件不一定 加工编号一定有 第一层DFD应当是基本系统模型 注意父图和子图的平衡，维护信息的连续性 区分局部文件和局部外部项 掌握分解的速度，上快下慢 遵守加工编号原则 验证软件需求 一致性、完整性 来源： CSDN

需求工程活动分为需求获取和需求分析、需求规格说明、需求验证、需求管理。需求获取是从人、文档或环境中获取需求的过程，需求工程师必须要利用各种方法和技术来 “发现”需求。需求开发的过程包含有学习和认知的过程，而学习和认知的过程是递进的，因此需求获取和分析是交织在一起的，需求工程师需要获取一些信息，随即进行分析和整理，理解、认知到一定程度后在确定要进一步获取内容。在需求获取中，需求工程师需要执行任务包括收集背景资料、获取问题与目标，定义项目前景与范围，识别涉众，选择信息的来源，选择获取方法，执行获取，获取功能与非功能需求，记录获取结果。需求分析阶段，需求工程师主要任务包括 1 背景分析 2 问题分析、目标分析、业务分析、确定系统边界 3 软件需求建模 4 细化需求 5 确定优先级 6 需求协商。 获取的需求下需要编写成文档，业务需求被写入项目前景和范围文档，用户需求被写入用户需求文档（或用例文档），系统级需求被写入需求规格说明。需求工程师在这个阶段主要工作包括定制文档模板好编写文档。需求验证主要任务包括 执行验证、问题修正 。 需求管理主要任务包括 1 建立和维护需求基线集 2 建立需求跟踪信息 3 进行变更控制。需求开发过程是迭代的和并发的，而且它的两个重要活动 - 需求获取与需求分析 - 还是交织的，共同构成一个学习过程。相比与编程，需求是众多因素影响的不确定性，是实践与理论并用。

目前，大多数的应用系统都属于数据库应用程序，都离不开数据库的支持。数据库设计方案的优劣对于应用程序的运行至关重要。数据库设计过程就是针对具体的应用环境，设计优化的逻辑模式，并根据所采用的数据库系统设计物理结构，最后建立应用程序的数据库。 数据库设计过程可以理解为提出问题、分析问题、解决问题的过程，具体包含6个步骤：需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库运行和维护。下图是数据库的总体设计过程。 需求分析的的主要任务是熟悉系统的业务，明确用户的需求。终点是调查与分析用户在信息管理中的数据要求、处理要求、安全性与完整性的要求。需求分析一般采用自上而下的需求分析方式，用数据流图和数据字典维护系统。 数据流图用来描述系统的逻辑模型，它描述数据流在系统中的流动情况和处理情况，是逻辑系统图形表示。在组织方式上，数据流图以分层的形式表示结构关系。 数据字典是各类数据集合的描述，是进行详细的数据收集和数据分析后的结果。数据字典包括对数据项、数据结构、数据流、数据处理、存储过程的规范和描述。 来源： https://www.cnblogs.com/ggz19/p/4095101.html

架构设计需求分析: 主要目的是明确架构要解决当前什么问题， 先调研需求方的诉求。 如果公司的架构部自high，做一些根本没有人使用的框架，组件，系统: 以“晋升”为目的的架构设计都应该拉出去祭天。 脱离业务的架构设计都是耍流氓。 一、架构设计的需求分析从哪来 需求分析的前期工作是愿景描述及愿景分析, 即愿景分析就是需求的前期调研. 从软件过程来看，需求分析是一个承上启下的阶段–“上承”愿景，“下接”设计。需求分析的工作内容包含如下三方面： 需求捕获: 理解沟通 需求分析:做什么,有哪些问题 系统分析:原因是什么, 怎么做 三者不是独立无关的阶段，而是相互伴随、交叉进行的。 需求捕获: 从各个方面收集需求, 并理解需求.典型的需求捕获是使用“需求采集卡”：需求描述、需求提出者、需求记录者、需求类型等。 需求分析: 需求捕获得到的是“原始需求”，而需求分析则对各方面收集到的需求进行分析、整理、归纳、论证形成明确的需求。比如, 产品经理说,现在系统不稳定, 需要重构架构保证系统稳定. 这只是一个愿景, 我们需要把这个需求形成一个明确的需求: 可行性99.99%, 要完成这个指标,需要做哪些工作. 二、需求分类:需求结构化 收集需求是多而杂, 我们需要理解并整理, 通过二维需求观，将“需求=列表”的传统观念，一下子拓宽了维度。有了视野和思维上的提升。 二维需求观: 首先，需求是分层次的:

需求工程复习 1.2.1需求工程简介 定义 简单地说，需求工程是所有需求处理活动的总和，它收集信息，分析问题，整合观点，记录需求并验证其正确性 从细节上说，需求工程是软件工程的一个分支，它关注软件系统所应实现的现实目标，软件系统的功能和软件系统应当遵守的规约 3个任务： 必须说明软件系统将应用的环境与目标，‘“做什么”，“怎么做” 必须将目标，功能，约束反映到系统软件中 妥善处理目标，功能和约束随着时间的演化 基本活动 需求工程分为 需求开发 与 需求管理 需求管理 ：需求管理是对需求开发所建立的需求基线的管理。它在需求基线完成后正式开始，在需求工程结束之后继续存在 需求开发 需求获取：从项目战略规划开始建立的最初原始需求 需求分析：保证需求的 完整性 与 统一性 需求规格说明：将完整性，一致性的需求与能够满足需求的软件行为以文档方式明确固定下来 需求验证：保证需求及其文档的 正确性 ， 完整性 与 一致性 ，最后统一意见，得出需求规格文档 2.2.2 问题与与解系统 问题域与解系统的关系 问题域：是需求的背景，解决问题必须涉及的事件和事物，即解决问题的基本范围（用户关注的问题） 解系统：指的是软件系统，软件系统通过影响问题域帮助人们解决问题，是软件解决方案在计算机上的实现（开发人员关注的问题） 关系：两者通过接口连接起来，这个接口就是**(模拟性)共享对象**