新项目管理怎样做需求分析.docVIP

假如将需求分析阶段工作归结为编写需求规格说明书，这种简化做法往往是造成项目后期层出不穷问题罪魁祸首。提议采取以下步骤形成 软件需求：获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）做法。 　　获取用户需求? 　　这是该阶段一个最关键任务。以下为获取用户需求需要实施活动（图1所表示）。 　　● 了解用户方全部用户类型和潜在类型。然后，依据她们要求来确定系统整体目标和系统工作范围。 　　● 对用户进行访谈和调研。交流方法能够是会议、电话、电子邮件、小组讨论、模拟演示等不一样形式。需要注意是，每一次交流一定要有统计，对于交流结果还能够进行分类，便于后续分析活动。比如，能够将需求细分为功效需求、非功效需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。 　　● 需求分析人员对搜集到用户需求做深入分析和整理。下面是几条常见准则： 　　⑴对于用户提出每个需求全部要知道“为何”，并判定用户提出需求是否有充足理由； 　　 　　图1 获取用户需求活动 　　⑵将那种以“怎样实现”表述方法转换为“实现什么”方法，因为需求分析阶段关注目标是“做什么”，而不是“怎么做”； 　　⑶分析由用户需求衍生出隐含需求，并识别用户没有明确提出来隐含需求（有可能是实现用户需求前提条件），这一点往往轻易忽略掉，常常因为对隐含需求考虑得不够充足而引发需求变更。 　　● 需求分析人员将调研用户需求以合适方法呈交给用户方和开发方相关人员。大家共同确定需求分析人员所提交结果是否真实地反应了用户意图。需求分析人员在这个任务中需要实施下述活动： 　　⑴明确标识出那些未确定需求项（在需求分析早期往往有很多这么待定项）； ⑵使需求符合系统整体目标； 　　⑶确保需求项之间一致性，处理需求项之间可能存在冲突。 　　分析用户需求 　　在很多情形下，分析用户需求是和获取用户需求并行，关键经过建立模型方法来描述用户需求，为用户、用户、开发方等不一样参与方提供一个交流渠道。这些模型是对需求抽象，以可视化方法提供一个易于 沟通桥梁。用户需求分析和获取用户需求有着相同步骤，区分在于分析用户需求时使用模型来描述，以获取用户更明确需求。分析用户需求需要实施下列活动： 　　● 以图形表示方法描述系统整体结构，包含系统边界和接口； 　　● 经过原型、页面流或其它方法向用户提供可视化界面，用户能够对需求做出自己评价； 　　● 系统可行性分析，需求实现技术可行性、环境分析、费用分析、时间分析等； 　　● 以模型描述系统功效项、数据实体、外部实体、实体之间关系、实体之间状态转换等方面内容。 　　 　　图2 DFD示意图 　　用于需求建模方法有很多个，最常见包含数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方法。DFD作为结构化系统分析和设计关键方法，已经得到了广泛应用，DFD尤其适适用于MIS系统表述。DFD使用四种基础元素来描述系统行为，过程、实体、数据流和数据存放。DFD方法直观易懂，使用者能够方便地得到系统逻辑模型和物理模型，不过从DFD图中无法判定活动时序关系。图2描述是某个项目标DFD示意图。 　　ERD方法用于描述系统实体间对应关系，需求分析阶段使用ERD描述系统中实体逻辑关系，在设计阶段则使用ERD描述物理表之间关系。需求分析阶段使用ERD来描述现实世界中对象。ERD只关注系统中数据间关系，而缺乏对系统功效描述。假如将ERD和DFD两种方法相结合，则能够更正确地描述系统需求。 　　在面向对象分析方法中通常使用Use Case来获取 软件需求。Use Case经过描述“系统”和“活动者”之间交互来描述系统行为。经过分解系统目标，Use Case描述活动者为了实现这些目标而实施全部步骤。Use Case方法最关键优点，在于它是用户导向，用户能够依据自己所对应Use Case来不停细化自己需求。另外，使用Use Case还能够方便地得到系统功效测试用例。 上一期，我们介绍了需求分析五个步骤中前两个步骤（获取用户需求、分析用户需求），本期将继续介绍后三个步骤（编写需求文档、评审需求文档、管理需求），并和大家讨论相关实践问题。 　　1、编写需求文档 　　需求文档能够使用自然语言或形式化语言来描述，还能够添加图形表述方法和模型表征方法。需求文档应该包含用户全部需求（功效性需求和非功效性需求）。 　　2、评审需求文档 　　需求文档完成后，需要经过正式评审，方便作为下一阶段工作基础。通常评审分为用户评审和同行评审两类。用户和开发方对于 软件项目内容描述，是以需求规格说明书作为基础；用户验收标准则是依据需求规格