• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

软件工程之需求分析(二)

发布: 2008-8-20 09:57 | 作者: 网络转载 | 来源: yesky | 查看: 51次 | 进入软件测试论坛讨论

领测软件测试网

状态转换图:实时系统和过程控制应用程序可以在任何给定的时间内以有限的状态存在。当满足所定义的标准时,状态就会发生改变,例如在特定条件下,接收到一个特定的输入激励。这样的系统是有限状态机的例子。大多数软件系统需要一些状态建模或分析,就像大多数系统涉及到转换过程、数据实体和业务对象。

  对话图:在许多应用程序中,用户界面可以看作是一个有限状态机。在任何情况下仅有一个对话元素(例如一个菜单,工作区,行提示符或对话框)对用户输入是可用的。在激活的输入区中,用户根据他所采取的活动,可以导航到有限个其它对话元素。因此,许多用户界面可以用状态转换图中的一种称为对话图来建模。对话图描绘了系统中的对话元素和它们之间的导航连接,但它没有揭示具体的屏幕设计。

  类图:面向对象的软件开发优于结构化分析和设计,并且它运用于许多项目的设计中,从而产生了面向对象分析、设计和编程的域。类图是用图形方式叙述面向对象分析所确定的类以及它们之间的关系 

4. 需求验证

  1)审查需求文档:对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个由不同代表(如分析人员,客户,设计人员,测试人员)组成的小组,对需求规格说明书及相关模型进行仔细的检查。另外在需求开发期间所做的非正式评审也是有所裨益的。

  2)依据需求编写测试用例:根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求。还要从测试用例追溯回功能需求以确保没有需求被疏忽,并且确保所有测试结果与测试用例相一致。同时,要使用测试用例来验证需求模型的正确性,如对话框图和原型等。

  3)编写用户手册:在需求开发早期即可起草一份用户手册,用它作为需求规格说明的参考并辅助需求分析。优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能。而辅助需求如质量属性、性能需求及对用户不可见的功能则在需求规格说明书中予以说明。

  4)确定合格的标准:确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。将合格的测试建立在使用情景描述或使用实例的基础之上。 

二、需求管理

  需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。经评审批准,这些文档就定义了开发工作的需求基线。这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。需求约定是需求开发和需求管理之间的桥梁,需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动。



   1.确定需求变更控制过程,确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程,商业化的问题跟踪工具都能支持变更控制过程。

  2.建立变更控制委员会,组织一个由项目风险承担者组成的小组作为变更控制委员会,由他们来确定进行哪些需求变更,此变更是否在项目范围内,估价它们,并对此评估作出决策以确定选择哪些,放弃哪些,并设置实现的优先顺序,制定目标版本。

  3.进行需求变更影响分析,应评估每项选择的需求变更,以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。影响分析可以提供对建议的变更的准确理解,帮助做出信息量充分的变更批准决策。通过对变更内容的检验,确定对现有的系统做出是修改或抛弃的决定,或者创建新系统以及评估每个任务的工作量。进行影响分析的能力依赖于跟踪能力数据的质量和完整性。

  4.跟踪所有受需求变更影响的工作产品当进行某项需求变更时,参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例,这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会,这种变更在变更需求的情况下是必须进行的。

  5.建立需求基准版本和需求控制版本文档确定一个需求基准,这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明,以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。

  6.维护需求变更的历史记录记录变更需求文档版本的日期以及所做的变更、原因,还包括由谁负责更新和更新的新版本号等。版本控制工具能自动完成这些任务。版本控制是管理需求的一个必要方面。需求文档的每一个版本必须被统一确定。组内每个成员必须能够得到需求的当前版本,必须清楚地将变更写成文档,并及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传,应仅允许指定的人来更新需求。这些策略适用于所有关键项目文档。

  7.跟踪每项需求的状态建立一个数据库,其中每一条记录保存一项功能需求。保存每项功能需求的重要属性,它包括状态(如已推荐的,已通过的,已实施的,或已验证的),这样在任何时候都能得到每个状态类的需求数量。

  8.衡量需求稳定性记录基准需求的数量和每周或每月的变更(添加、修改、删除)数量。过多的需求变更"是一个报警信号",意味着问题并未真正弄清楚,项目范围并未很好地确定下来或是政策变化较大。

  9.使用需求管理工具商业化的需求管理工具能帮助你在数据库中存储不同类型的需求,为每项需求确定属性,可跟踪其状态,并在需求与其它软件开发工作产品间建立跟踪能力联系链。

文章来源于领测软件测试网 https://www.ltesting.net/

33/3<123

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网