需求分析(一)概念、方法、实践步骤

需求分析(1)概念、方法和实践程序1 .概念、方法和实践程序需求分析阶段主要是以收集、分析、推导的方式，将客户、业务、用户需求转化为对应(软件)系统需求的过程。 典型工作产品：软件要求描述(SRS )主要包括系统的基本概述、业务功能、系统功能(性能、安全性、可靠性、可扩展性、可移植性、多语言兼容性等要求)、接口功能要求等。1.1需求分析阶段的主要活动需求分析阶段的主要活动可分为需求开发、需求管理两大类需求开发通过客户、业务、用户、原系统等调查获得原需求，通过需求分析识别业务，具体化，通过制作规格书(或SRS )来结构业务，项目团队与客户、用户分阶段协商最终确认需求，在此期间进行系统建模、POC等需求管理在需求开发过程中，通过需求范围认定、需求形式化记录、需求数据库的构筑、需求状态跟踪、需求变更分析和变动评价、需求评审管理等活动，使用需求管理工具等手段，实现系统需求的基线管理。 其核心内容变更管理、版本控制和需求跟踪。1.2需求开发的主要概念和核心步骤业务需求反映了企业和组织(软件)系统的业务需求，通常包括问题和机会定义。 问题是企业和组织运营过程中遇到的问题，比如物资供给不足、用户投诉量多、客户流失率高等。 机会就是抓住外部环境变化带来的机会，给企业带来新的发展。 例如电子商务、网上银行、基于即时通讯的工作协同系统等。 业务需求通常由管理人员提出，解决业务需求应结合制度、人员能力、系统功能等多个方面综合解决。 业务需求反映了企业和组织对(软件)系统的高水平目标要求，即系统建设的目的和目标。用户需求通常是根据问题定义(业务需求)来进行用户访谈和调查，以说明用户需要使用(软件)系统来实现什么，以及需要如何实现什么，从而组织用户的视点需求(软件)解决如何使用系统完成具体任务。软件系统的需求在业务需求的指导下，对用户的需求进行整理、分析、精制，指导开发出的更加准确、规范化的需求。 一般来说，软件需求可以被签约作为软件检查的依据。 软件系统的需求可以分为业务功能的需求，系统功能的需求，设计制约等。n业务功能要求：(软件)系统必须完成的业务功能，即为了向用户提供有用功能而必须执行的操作。 该部分的工作以结构化的方式定义了分散用户的不均匀需求，支持后续的设计、开发和测试。n系统功能要求：(软件)系统所需的功能、性能和属性。 包括系统性能(功能速度、响应时间、恢复时间等)、可靠性、易用性、安全性、移植和部署等内容要求。n设计约束需求：影响系统实现的各种设计约束。 开发语言、数据完整性方针、资源限制、执行环境要求等。2 .主要趋势需求分析阶段的主要活动以需求开发为中心，包括需求开发计划的制定和修改、需求调查和分析、需求验证、需求规则说明制定、需求确认的几个步骤。1 .制定和修改需求开发计划包括需求小组组织和认可、分解需求分析阶段的WBS、制定协商和调查分析、重新评估计划、评估工作量等方面的内容，其目的是保证各项活动的秩序和控制。2、需求调查和分析过程，主要活动是通过联系和收集项目中各级相关人员的需求，形成需求调查报告。 需求调查通过现场参观、调查会、业务专家培训、咨询交流、问卷设计、收集调查记录等方法，由客户、客户各级组织获得(软件)系统需求，分析识别客户和客户的需求、期待、业务需求，汇总编制需求调查报告书。3 .需求验证环节主要以原型(Prototype )、POC(Proof of Concept )、用例(Use Case )或简单的功能列表方式与顾客、用户沟通，以满足业务需求、用户需求等软件系统的需求原型模拟最终软件的屏幕显示，用户可以看到最终的软件将是什么样的，一些原型可以模拟实际的操作，而重要的输入和输出数据也可以模拟一些以用户体验为中心的系统往往会产生良好的效果。POC(Proof Of Concept )旨在“为观点提供证据”。 针对关键技术和业务模式，论证需求、设计的可行性，评估和确认概念设计方案，POC评估可能导致需求和设计调整。 一般来说，进行POC的条件：1.论证与业务相关的模型和算法的可行性。 2 .论证技术模式的可行性、成本等。用例：系统如何响应外部请求的描述是从用户的使用场景获得需求的技术。 每个用例提供一个或多个场景，说明系统如何与最终用户或其他系统交互。 这意味着谁可以使用系统来实现明确的业务目标。4 .需求规则说明(SRS )制作：通过需求调查和初步的需求验证，包括确认需求规则说明(SRS )的内容、制作方法、制作工具、质量标准等，可以确立需求制作的标准。 根据需求创建标准创建需求规格说明(SRS )，良好的需求规格说明(SRS )应遵循正确、无模糊、完整、一致、等级(重要性或稳定性)、可验证、可修改和可跟踪原则。5 .需求确认：通过组织层次审查，确认需求分析阶段的产品，特别是最重要的结果产品的需求规格说明(SRS )，确保相关人员的理解。 根据审查方法，可以根据情况分为需求开发集团内的审查、顾客外部的审查、重要相关人员的审查等。需求分析过程在项目规模、工作人员、系统类型方面存在很大差异，必须根据实际情况进行合理的削减。 下面列举几个不同情况的具体过程/简单的需求开发流程第一步：确定实现的目的、目标、基本业务需求、业务定义和相关审查。从目的、实现目标的观点出发，重新审视业务定义，总结业务需求。 (确认客户实施的业务要求)第2步骤：具体化业务，进行软件系统的定义(系统要件定义)。从目的角度进行业务定义(功能、步骤)，研究系统构成，定义系统化或计算机化的功能、流程。在定义步骤：业务需求和系统需求的同时，总结相关的运营需求(非功能需求)运行时间、安全应对、访问权等系统需求和设计约束是根据业务需求，考虑系统上的约束条件而逐渐形成的。示例：软件工程类的典型过程主要特点：强调客户合作，提高运营效率，切断技术风险，加强边界管理强调与顾客的合作，确定各种约定，包括期限、交流方式、成果等强调计划管理，为目的确保进度和成本，合理使用人力资源问题回答管理票方式加强需求团队与客户合作，提高生产效率，确保质量加强需求边界管理，控制整个项目的成本预先论证技术关键环节(技术解决方案、技术框架)，控制技术风险，减少技术造成的成本损失强调需求的最终确认案例3 :软件产品类的典型过程主要特点：缩短开发周期，支持跨部门运营，提高创造性，强调用户体验设计。强调计划性，加快开发流程，缩短产品开发周期。强调跨部门协调组织，建立统一的需求团队。强调行业学习、创新和交流。为了适应产品的创造、快速的变化、市场需求的适应性、流程、成本管理，按版本进行制作。强调交互原型的重要性，加强用户体验性设计。需求分析(2)内容需求分析阶段的产物可以包括需求调查报告、需求规格说明书、可行性报告等多方面的内容，一般来说需求规格说明书(硬件、软件)是最终产物。 过程的重要产物还包括需求调查报告。3.1需求调查报告通过现场参观、调查会、业务专家培训、咨询交流、问卷设计与调查、调查记录收集等方式，客户、用户各级组织获得(软件)系统需求，分析识别客户及用户的需求、期望、业务需求，并总结出需求调查报告书需求调查总是作为中间过程的成果，强调主要归纳整理业务系统的现状，同时记录整理业务中的问题各种期待优化方案，通过初步分析形成结构化描述。 一般需求调查报告包括目的、目标、范围、业务域概述、组织和相应的职场权限、业务现状、业务优化期望、业务规则(算法、逻辑)、输入/输出数据以及其他系统的交互(如果有)。1 .业务领域业务领域主要是在整理和整理项目工作范围的同时，理解和描述业务上各领域之间的关系。例业务领域和相关关系2 .业务现状业务现状主要描述了当前业务中的各种处理，可以通过业务流程描述(很好地用游泳图描述)、每个业务场景描述、系统功能需求描述、相关输入输出信息、优化分析期望等几个方面来描述。 如果有与原业务对应的(软件)系统，也可以收集原系统对应的资料进行整理。1 )描述业务场景描述：业务的各处理，通过记录和整理形成结构化的场景描述。 场景描述通常包括场景名称、与场景相关的角色、详细描述场景、生成结果、当前问题以及相应的期望。 需要注意的是，任何系统的引进都会在一定程度上改变当前的工作模式和工作方法，当前的问题和对应的期待的支持度会左右系统的价值，也必然会成为今后(软件)系统的焦点。 当然，这些问题和期待可以通过管理制度的建设、人员能力的强化、计算模型的优化、系统化(计算机化)等来解决。 实际上，需求分析阶段的主要工作是识别、分析这些工作是可以系统化或计算化的工作，辅助制度化管理程序，提高人员能力等工作提高工作效率和质量。 举例来说，移动终端想要改进购物的便利性是可实现什么系统化的，例如，支付是系统化的且可移动支付，同时第三方的支付需要合法的支持等。2 )商业功能需求的说明：根据商业场景，说明系统的商业功能。 一般包括先决条件、输入、输出、业务规则和典型操作。 业务功能的需求记述着眼于业务的具体化，进行(软件)系统的需求调查和定义，记述方法也更加结构化。 在该步骤中，业务规则是重要的核心，是业务场景中具体处理的详细请求，通常包括详细处理流程、计算重要数据的方法、样式请求等。3 )业务数据的记述：将业务场景、业务功能需求中的输入输出数据结构化整理的程序。 在许多新系统中，商业数据通常是分散的，并且需要通过这一过程来结构化相关数据，以为后续规范定义提供基础。4 )其他：关于整理业务现状的过程，采取过程性资料，如原始文件、扫描表格等方法进行收集。 原系统可以通过收集设计资料和截图等进行整理。3.2软件规格书(SRS )通过需求调查和分析、需求验证的一环等程序，需求规格书将业务具体化，最终明确定义软件和硬件系统的功能。 需求规格说明(SRS )为了指导后续的设计、开发、测试作业的开展，对功能进行结构化的说明。 需求规格说明定义系统愿景、系统范围、业务功能、系统功能、约束条件等的需求。 主要记述系统“What to do”，之后的设计记述系统“How to do”。1 .项目目标系统范围项目的目标系统范围，描述项目开始的背景，要解决的问题，系统的目标和目标，评估项目的范围。 一般而言，“项目背景”(Project Background )、“当前位置”(Current Situation )、“当前面临的问题”(The issues we are facing now )、“项目目标”(Objectives Goals )、“项目范围”(Project Scope )、 业务流程/功能范围(Business Process/Function Scope )、组织范围(Organization Scope )。1 )项目的目标和目标应该着眼于未来的价值，它应该具有定量、可评价、可实现和价值。 系统的设计、开发、测试、验证、公开、执行等工作都是以项目的目的和目标为中心进行的。需要注意：项目的目的和目标必须细分，分解为若干核心指标。 这些指标今后可以量化和评定。 例如，“节约人力和物理投资，同时提高顾客满意度”可以设定为“将传统维护人员的规模减少75%，将物理投资减少80%等。 制定明确的指标，能够更有效地推进系统、人员、制度的有效结合，这也是项目成功的必要条件。 许多软件项目到后期为止都是在线的，因此往往无法取得实际效用，这与前期目标无明显关系。 事实上，一个项目经过几个或几百个月或几年的辛勤工作，经过设计、开发、测试、反复修复缺陷、在线和运行，令人高兴的可能是实现了项目的目标和目标。 最悲剧的故事是“不知道本来的目标是什么”。项目的目的和目标可以是多方面的，如为用户、操作者、管理者、决策者分别设定不同的目标也是今后系统化和设计的指南。制定项目目的和目标，需要多方面的讨论和确认，尤其是项目的重要决策者。 通过这些目的和目标，至少我们能够明确该系统的未来价值。 在某些情况下，决策者不是这些领域的专家，而是需求开发者针对需求和目标提出建议和解决方案，耐心等待决策环境的成熟，减少决策迟缓的好处之一就是决策失误。2 )范围可以包括项目范围、业务范围、职能范围、组织范围等内容，这些工作应该做，不应该做。 在项目中在预算、成本、WBS、计划等方面发挥决定性作用。2 .业务职能需求业务功能的需求往往主动描述系统“What to do”，不同类型的系统业务功能的需求方面也不太相同，描述的方法和内容也不同。不同类型的系统业务功能需求方面不同n在线事务处理