确定需求的五个步骤

《确定需求的五个步骤》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、收集、分类、绘图、评审需求。　　1、收集需求　　需求的来源　　蓝图（外貌）文档（visiondocument）。这个文档描述了业务需求和开发一个成功的系统需要蓝图。　　预排文档（walkthroughdocument）。这些文档是各种用户如何与系统交互式的一组“每日生活”的描述。　　域术语表。这是终端用户所用语言的指导。　　域专家和终端用户会谈。　　功能规范和工作陈述。　　２、需求分类　　根据Wiegers的示例（SoftwareRequirements,page8），将需求定义为如下７类：　　业务需求：提供

2、系统的高层次的“蓝图”（Ｖision）。构造系统的原因，期望达到的好处。　　用户需求：是具体的蓝图。表达了用户需求什么内容来完成他们的工作，包括他们将在这些工作中执行的过程。（流程）　　功能需求：更为具体的用户需求。　　非功能需求（ＮＦＲ）。　　约束：ＮＦＲ限制了实某些功能的方式，而约束限制了开发过程自身。　　约束可能进一步被划分为如下分类：　　操作约束（Operationconstraint），工作方法的约束。　　法定约束（Statutoryconstraint），必须遵守合法命令。　　合同约束（Contr

3、actualconstraint），合同中的义务。　　信用约束（fiduciaryconstraint），财务风险及限制。　　数据库约束（Databaseconstraint）。　　角色：角色表示任何外部系统，这些系统与正在设计的系统进行互操作。　　域对象：这些是客户希望系统代表或保持的任何对象或实体。　　Ｍartin模式　　指导员模式：希望显示有许多成功解决问题的方法，并描述其中之一的一些方法；　　专业人员模式：希望显示他所做的实际工作。　　分类需求的一个有用的技术：　　让每个团队成员阅读每个需求来源，每个

4、团队成员关注于不同种类的需求。每个团队成员都可以生成特定种类需求的目录或总结报告；然后所有团队成员进行评审。　　３、确定需求间的依赖　　根据需求来源确定哪些奢求依赖于其他需求。特别应该找用户需求、功能需求和受ＮＦＲ和约束影响的域对象。通过使用（RationalRequisitePro）等需求工具，可以定义一个跟踪矩阵，向人显示需求间的相互影响。有Ｘ的单元格表明是两个相关联的需求。　　4、绘图需求　　创建反映需求的ＵＭＬ图。要用到用例图、活动图和类图。　　５、评审需求　　开始构建系统的法则：　　对所有现有的用例

5、进行了绘图；　　９０％或更多的用例具有详细定义的基本场景和可选场景；　　９０％或更多的场景具有活动图；　　需求增量小于１０％；　　对于关键任务系统，没有任何分析员、客户或其它团队成员提出危险警告。标签： SRS 软件需求规格说明 需求分析培训 需求分析工具