确定需求的5个步骤.docVIP

　收集、分类、绘图、评审需求。 　　1、收集需求 　　需求的来源 　　蓝图（外貌）文档（vision document）。这个文档描述了业务需求和开发一个成功的系统需要蓝图。 　　预排文档（walkthrough document）。这些文档是各种用户如何与系统交互式的一组“每日生活”的描述。 　　域术语表。这是终端用户所用语言的指导。 　　域专家和终端用户会谈。 　　功能规范和工作陈述。 　　２、需求分类 　　根据Wiegers的示例（Software Requirements,page 8），将需求定义为如下７类： 　　业务需求：提供系统的高层次的“蓝图”（Ｖision）。构造系统的原因，期望达到的好处。 　　用户需求：是具体的蓝图。表达了用户需求什么内容来完成他们的工作，包括他们将在这些工作中执行的过程。（流程） 　　功能需求：更为具体的用户需求。 　　非功能需求（ＮＦＲ）。 　　约束：ＮＦＲ限制了实某些功能的方式，而约束限制了开发过程自身。 　　约束可能进一步被划分为如下分类： 　　操作约束（Operation constraint），工作方法的约束。 　　法定约束（Statutory constraint），必须遵守合法命令。 　　合同约束（Contractual constraint），合同中的义务。 　　信用约束（fiduciary constraint），财务风险及限制。 　　数据库约束（Database constraint）。 　　角色：角色表示任何外部系统，这些系统与正在设计的系统进行互操作。 　　域对象：这些是客户希望系统代表或保持的任何对象或实体。 　　Ｍartin模式 　　指导员模式：希望显示有许多成功解决问题的方法，并描述其中之一的一些方法； 　　专业人员模式：希望显示他所做的实际工作。 　　分类需求的一个有用的技术： 　　让每个团队成员阅读每个需求来源，每个团队成员关注于不同种类的需求。每个团队成员都可以生成特定种类需求的目录或总结报告；然后所有团队成员进行评审。 　　３、确定需求间的依赖 　　根据需求来源确定哪些奢求依赖于其他需求。特别应该找用户需求、功能需求和受ＮＦＲ和约束影响的域对象。通过使用（Rational RequisitePro）等需求工具，可以定义一个跟踪矩阵，向人显示需求间的相互影响。有Ｘ的单元格表明是两个相关联的需求。 　　4、绘图需求 　　创建反映需求的ＵＭＬ图。要用到用例图、活动图和类图。 　　５、评审需求 　　开始构建系统的法则： 　　对所有现有的用例进行了绘图； 　　９０％或更多的用例具有详细定义的基本场景和可选场景； 　　９０％或更多的场景具有活动图； 　　需求增量小于１０％； 　　对于关键任务系统，没有任何分析员、客户或其它团队成员提出危险警告。 标签：?SRS?软件需求规格说明?需求分析培训?需求分析工具