项目管理：怎样做需求分析.doc

如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。建议采用以下步骤形成软件需求：获取用户需求分析用户需求编写需求文档评审需求文档管理需求。下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。 获取用户需求 这是该阶段的一个最重要的任务。以下为获取用户需求需要执行的活动（如图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、评审需求文档 需求文档完成后，需要经过正式评审，以便作为下一阶段工作的基础。一般的评审分为用户评审和同行评审两类。用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的；用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档时用户的意见是第一位的。而同行评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。 3、管理需求 图1 需求变更流程 需求的变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。对于需求变更的管理，则主要使用需求变更流程和需求跟踪矩阵的管理方式。需求变更流程和需求跟踪矩阵分别如图1和图2所示。 图2 需求跟踪矩阵 常见问题及建议 Q、客户与最终用户的区别是什么？ A、可以借助图3来说明它们之间的区别。 图3 需求获取渠道示意图 软件需求来自系统工程与客户两个方面，其中客户是主要的需求提供者（系统工程需求也来自于客户）。客户需要搜集其最终用户的需求并考虑自身的需求，然后再提供给开发方。假如客户并未去认真搜集最终用户的需求，开发方便需要做到这一点，因为系统最终要满足最终用户的需求。 Q、如何进行用户访谈？ A、首先，一定要事先确定访谈的目的和提纲。其次，因为用户往往并不知道应该提供哪些方面的需求，所以需要开发人员引导。 Q、用户访谈内容是什么？ A、首先，请用户描述他们如何完成自己当前的工作，并与用户一起抽象出一个工作流程或工作模型。然后，在得到用户的认可后，向用户解释自己是怎样来实现这些功能的，并说明哪些环节可以用自动化方式实现等。 Q、采用哪一种方式做需求分析最好？ A、不同的需求分析有不同的特点。还没有哪一种方法可以完全替代别的方法，否则，现在就不会存在不同的需求建模方式了。一般来说，可以使用DFDERD来描述那些功能层次比较清晰的需求；而USE CASE则适于描述功能结构复杂的需求。做需求分析的目的是为了建立需求的模型，不同的子系统有可能使用不同的建模方法。 Q、怎样做原型，原型的目的是什么？ A、通常使用原型分析方法来帮助开发方进一步获取用户需求或让用户确认需求。开发方往往先向用户提供一个可视界面作为原型，并在界面上布置必要的元素以演示用户所需要的功能。可以使用第四代语言（例如Visual Basic、Delphi等）来快速生成用户界面，也可以使用FrontPage等网页制作工具来生成用户可视的页面流。 原型的目的往往是获取需求。但有时也使用原型的方式来验证关键技术或技术难点。对于技术原型，界面则往往被忽略掉。 物业安保培训方案 为规范保安工作，使保安工作系统化/规范化,最终使保安具备满足工作需要的知识和技能，特制定本教学教材大纲。一、课程设置及内容全部课程分为专业理论知识和技能训练两大科目。其中专业理论知识内容包括：保安理论知识、消防业务知识、职业道德、法律常识、保安礼仪、救护知识。作技能训练内容包括：岗位操作指引、勤务技能、消防技能、军事技能。二培训的及要求培训目的1）保安人员培训应以保安理论知识、消防知识、法律常识教学为主，在教学过程中，应要求学员全面熟知保安理论知识及消防专业知识，在工作中的操作与运用，并基本掌握现场保护及处理知识2）职业道德课程的教学应根据不同的岗位元而予以不同的内容，使保安在各自不同的工作岗位上都能养成具有本职业特点的良好职业道德和行为规范）法律常识教学是理论课的主要内容之一，要求所有保安都应熟知国家有关法律、法规，成为懂法、知法、守法的公民，运用法律这一有力武器与违法犯罪分子作斗争。工作入口门卫守护，定点守卫及区域巡逻为主要内容，在日常管理和发生突发事件时能够运用所学的技能保护公司财产以及自身安全。2、培训要求1）保安理论培训通过培训使保安熟知保安工作性质、地位、任务、及工作职责权限，同时全面掌握保安专业知识以及在具体工作中应注意的事项及一般情况处置的原则和方法。2）消防知识及消防器材的使用通过培训使保安熟知掌握消防工作的方针任务和意义，熟知各种防火的措施和消防器材设施的操作及使用方法，做到防患于未燃，保护公司财产和员工生命财产的安全。3) 法律常识及职业道德教育通过法律常识及职业道德教育，使保安树立法律意识和良好的职业道德观念，能够运用法律知识正确处理工作中发生的各种问题；增强保安人员爱岗敬业、无私奉献更好的为公司服务的精神。4) 工作技能培训