预览加载中,请您耐心等待几秒...
1/10
2/10
3/10
4/10
5/10
6/10
7/10
8/10
9/10
10/10

亲,该文档总共30页,到这已经超出免费预览范围,如果喜欢就直接下载吧~

如果您无法下载资料,请参考说明:

1、部分资料下载需要金币,请确保您的账户上有足够的金币

2、已购买过的文档,再次下载不重复扣费

3、资料包下载后请先用软件解压,在使用对应软件打开

第一章软件需求缩略词CIA机密性,完整性,可用性DAG定向非循环图FSM功能规模度量INCOSE系统工程国际委员会UML统一建模语言SysML系统建模语言介绍软件需求知识领域(KA)涉及软件需求的引出、分析、说明和验证,以及软件产品整个生命周期中需求的管理。在研究人员和行业从业者中,人们普遍认为,当需求相关的活动表现不佳时,软件项目是非常脆弱的。软件需求表达了对软件产品的需求和约束,这些产品有助于解决一些实际问题。术语“需求工程”在这个领域被广泛使用,表明系统地处理要求。出于一致性的原因,“工程”这个词除了用于软件工程之外,不会被用于在KA中。出于同样的原因,“需求工程师”这一术语出现在一些文献中,也不会被使用。相反,术语“软件工程师”或某些特定情况下将使用“需求专家”,后者通常是由软件工程师以外的其他人扮演。但这并不意味着软件工程师无法执行该功能。一个固有风险被提议要分解:一个瀑布式的过程可以被推断出来。为了防范这一问题,主题2被设计为通过阐述流程运行的资源和限制因素以及确定流程的方式来提供需求流程的高级概述。另一种分解可以基于产品的结构(系统需求、软件需求、原型、用例等等)。基于过程的故障反映了这样一个事实:如果要成功,需求过程必须被看作是一个涉及复杂的、紧密耦合的活动(包括顺序和并发)的过程,而不是在软件开发项目开始时执行的离散的、一次性的活动。软件要求KA与软件设计,软件测试,软件维护,软件配置管理,软件工程管理,软件工程流程,软件工程模型和方法以及软件质量KA密切相关。软件需求主题的分解软件需求的主题的分解KA如图1.1所示。软件需求基本元素[1*,c4,c4s1,c10s1,c10s4][2*,c1,c6,c12]1.1软件需求的定义在最基本的情况下,软件需求是为了解决现实世界中的一些问题必须展现的一个属性。它的目的可能是使某些任务的一部分自动化,以支持组织的业务流程,纠正现有软件的缺陷或控制设备-仅列举可能的软件解决方案的许多问题中的一些。用户,业务流程和设备的功能通常很复杂。因此,通过扩展,对于特定软件的要求通常是来自组织的不同级别的各种人以及与软件将在其中运行的环境中涉及或与该特征相关联的人的复杂组合。软件需求软件需求基本原理需求过程需求获取需求分析需求规范需求验证实际问题软件需求模型软件需求的定义过程模型需求来源需求分类系统定义文件需求评审需求过程的迭代性质产品和过程需求过程参与者获取技巧概念建模系统需求规范原型设计变更管理功能和非功能需求过程支持和管理结构设计和需求分配软件需求规范模型验证需求属性应急属性过程质量和改进需求协商验收测试需求跟踪可量化的需求正式分析需求测量系统需求和软件需求图1.1软件需求的主题的分解KA所有软件要求的一个基本属性是,它们作为功能要求的单个功能可视为系统级别的非功能要求。验证某些软件需求可能是困难或昂贵的。例如,对呼叫中心的吞吐量要求的验证可能需要开发仿真软件。软件需求,软件测试和质量人员必须确保可以在可用的资源限制内验证该项目。除了行为属性之外,需求还有其他属性。常见的例子包括在有限资源面前实现权衡的优先等级,以及使项目进度得到监控的状态值。通常,软件需求被唯一识别,使得它们可以在特征和软件的整个生命周期中经受软件配置管理。1.2产品和过程需求产品需求是所开发的软件的一个需求或限制(例如,“该软件将在其注册课程之前验证学生满足所有先决条件”)。过程需求本质上是对软件开发的约束(例如,“软件应该使用RUP过程来开发”)。一些软件需求产生了隐式的过程需求。验证技术的选择就是一个例子。另一个可能是使用特别严格的分析技术(如正式指定方法)来减少可能导致可靠性不足的故障。过程要求也可由开发组织,其客户或第三方(如安全监管者)直接施加。1.3功能性和非功能性需求功能需求描述了软件执行的功能;例如,格式化一些文本或调制信号。它们有时被称为功能或特性。功能需求也可以被描述为一个可以编写有限的测试步骤来验证其行为的方法。非功能性需求是限制解决方案的需求。有时称为非功能性需求是约束或质量需求。它们可以根据性能需求,可维护性需求,安全需求,可靠性需求,互操作性需求或许多其它类型的软件需求之一进一步分类(参见软件质量KA中的型号和质量特性)。1.4应急属性一些需求代表了软件的应急特性,即不能由单个组件解决的需求,但这取决于所有的软件组件是如何互操作的。例如,呼叫中心的吞吐量要求取决于电话系统、信息系统和操作人员如何在实际操作条件下进行交互。应急属性非常依赖于系统体系结构。1.5可量化的需求软件需求应尽可能清楚明确地说明,并酌情定量说明。重要的是要避免模糊和不真实的需求,这些需求依赖于他们对主观判断的解释(“软件应该是可靠的”;“软件应该是用户友好的”)。这对于非功能性需求尤其重要。量化需求的两个例