软体需求  文件类型：PPT/Microsoft Powerpoint   文件大小：字节

软体需求
系统的描述与规格说明
需求工程
依据客户对系统的需求以及系统运作与开发时的限制来建立服务的程序
需求本身是需求工程程序期间所产生的系统服务与限制的描述
何谓需求
从某个服务或系统限制的高阶抽象叙述到详细的数学式功能规格
需求通常有两种功能
它可以当成合约招标的基础,因此必须容易解释
它可以当成合约本身的基础,因此必须详细定义
这两项叙述均可称为需求
需求类型
使用者需求
以自然语言和图表所形成的叙述,用来描述系统能够提供的服务以及运作时的一些限制条件.这些需求是专为客户所撰写的
系统需求
以结构化的文件更详细的定义系统的服务与限制条件.以客户和承包商之间的合约方式撰写
软体设计规格
详细的软体描述,用来当成设计和实作的基础.专为开发者所撰写
定义与规格
需求的读者
功能与非功能需求
功能需求(Functional requirements)
描述系统应该提供的服务,系统对特殊输入的回应方式以及系统在特殊情况下的行为等叙述 .
非功能需求(Non-functional requirements)
服务的限制条件或是系统提供的功能,包括时间上的限制,开发程序上的限制和标准等.
领域需求(Domain requirements)
来自系统应用领域的需求以及该领域所反映的特性,这种需求可以是功能性或非功能性的需求.
功能需求
描述系统功能或服务
依据软体的类型,预期的使用者以及应用此软体的系统类型而定
功能性的使用者需求可以是说明系统应该做什麼的高阶叙述;功能性的系统需求则应该详细描述系统的服务
功能需求的范例
使用者必须能够搜寻整个资料库或是选择某个子集做搜寻.
系统必须提供适当的检视器,让使用者可以阅读文件资料库中的文件.
每一笔预定的书单必须配置一个唯一的识别码(ORDER_ID),而且必须能够让使用者将这个码复制到其帐户的永久储存区.
需求不精确
当需求没有精确的描述就会发生的问题
模凌两可的需求会被开发者和使用者解释成各种可能
以前面范例中的「适当检视器 」为例
使用者的目的 – 为每个不同文件类型所使用的特殊用途检视器
开发者的解释 – 提供能够显示文件内容的文字检视器
需求的完整性与一致性
原则上,需求应该是完整且一致的
完整
它们应该包含所有需求功能的描述
一致
系统功能描述中不应该有冲突或矛盾的地方
实际上,不太可能产生完整且一致的需求文件
非功能需求
定义系统特性与限制,例如:可靠度,回应时间以及储存需求.限制则如 I/O 装置的容量,系统表示方式等.
非功能需求也可以指定程序需求,限制使用特定的 CASE 系统,程式语言或是开发方法等
非功能需求可能比功能需求还重要,如果没有符合这些需求,系统就没有用
非功能需求的分类
产品需求
指定交付的产品必须以某种特定方式运作的需求,例如:执行速度,可靠度等.
组织需求
因应组织政策与程序的需求,例如:使用的程序标准,实作需求等.
外部需求
系统与开发程序之外的影响因素所引起的需求,例如:互通需求,法律需求等.
目的与需求
非功能需求可能不容易精确的陈述,而不精确的需求则更难以进行验证.
目的
使用者的一般目的,例如容易使用
可验证的非功能需求
使用某些可以客观测试的度量值来叙述
这些目的对开发者是有帮助的,因为它们可以传送系统使用者的目的
需求的度量值
已处理交易/秒,使用者/事件回应时间,画面重新整理时间
速度
故障后重开机次数,造成故障的事件比例,故障时的资料毁损机率
强固性
平均故障次数,无法使用的机率,故障出现率,可用性
可靠性
训练时间,辅助说明的数量
容易使用
K位元组,RAM晶片的数量
大小
已处理交易/秒,使用者/事件回应时间,画面重新整理时间
速度
量测方式
性质
需求的互动
不同的非功能需求产生冲突的情形在复杂系统中是常见的现象
太空船系统
为了减轻重量,系统使用的晶片数量必须减少
为了减少电力的消耗,必须使用低电力的晶片
然而,若使用低电力的晶片可能需要更多的晶片数量.这时候,哪一个需求是最重要的需求
领域需求
衍生自应用领域,描述能够反应领域的系统特性与功能
可能是新的功能需求,对现有需求的限制或是定义特定的运算条件
若不能满足领域需求,系统可能就无法运作
领域需求的问题
理解性
需求是以某应用领域特定的语言来表示
开发系统的软体工程师对这些语言通常都不太能够了解
隐含性
领域专家非常熟知他的领域,所以通常不会以明确的方式来订定领域需求
使用者需求
应该以功能或非功能需求来描述,以便让不熟悉详细技术知识的系统使用者能够理解
使用者需求是以自然语言,表格和图表来定义
自然语言的问题
不够清楚
使用语言时有时候很难精确,清楚的描述
需求混淆
功能与非功能需求可能会产生混淆
需求混合
将好几种不同需求一同表示
需求的问题
资料库需求包含了概念和详细的资讯
它描述了组态控制功能的概念
又包含一些详细资讯,指出物件可以使用不完全的名称来存取
格线需求混合了三个不同的需求
概念性的功能需求 (格线的需求)
非功能需求 (格线单位)
非功能的 UI 需求 (格线切换)
撰写需求的指引
创造一个标准的格式,并且确保所有需求定义都支持这个格式.
使用更一致性的言语,特别要将强制和渴望的需求区分清楚.强制的需求通常使用「必须」(shall)来定义,渴望的需求则使用「应该」(should)
利用其他字型(粗体和斜体字)强调需求的主要部分
尽量避免使用电脑术语
系统需求
比使用者需求更详细的规格
设计系统的基础
可以用来当成系统合约的一部分
系统需求可以利用第 7 章即将介绍的系统模型来表示
需求与设计
原则上,需求应该陈述系统应该做什麼;而设计应该描述如何做到
事实上,需求和设计是不可分的
利用系统架构可以建立需求的结构
系统可以和其他系统互动以产生设计需求
使用的特定设计可能是领域的需求
NL 规格的问题
意义不明确
撰写与阅读需求的人必须使用同样的方式来诠释相同的文字,不过因为自然语言的特性具有模糊性,所以可能会造成许多误解
太过弹性
规格中,同一件事情可能会有许多不同讲法
缺乏模组化
NL 的结构并不适合建构系统需求的结构
NL 规格的替代表示法
它是根据数学观念所形成的标示法,例如有限状态图或集论.这些清楚的规格可以减少顾客和承包商对系统功能的争执.不过,大部分的顾客都不懂这些正规化的规格,所以不愿意使用它当作系统的合约.我们将在第9章说明正规化规格.
数学式规格
加上文字注记的图形化语言,用来定义系统的功能性需求.这种图形化语言最早的例子是SADT (Ross, 1977;Schoman与Ross, 1977),最近的例子则是使用案例描述(Jacobsen 等人, 1993).我们将会在稍后的章节进行讨论.
图形标示法
这个方法使用类似程式设计的语言,但是更具抽象特徵,经由定义系统的操作模式来指定需求.
设计描述语言
这个方法是经由定义标准表格或范本来表示需求的规格.
结构化自然语言
说明
标示法
结构化语言的规格
使用自然语言的限制格式可以表示需求
它可以消除模糊与弹性所造成的问题,并且可以让规格有某种程度的统一性
通常是以表单式的方式来支援
表单式规格
定义功能或实体
描述输入资料以及它们的来源
描述输出资料以及它们的去处
指示其他所需的实体
前条件与后条件
副作用
需求文件
需求文件是一份用来说明系统开发者需求的正式文件
它必须包含需求的定义和规格
但是它不是一份设计文件,它必须设定系统应该「做什麼」(What);而不是「如何做」(How)
需求文件的使用者
需求文件的需求
指定外部的系统行为
指定实作的限制
容易做变更
当成维护时的参考工具
记录系统生命周期的未来考虑,亦即预期的变更
列出非预期事件的回应特徵
IEEE 的需求标准
简介
一般说明
特定需求
附录
索引
这只是通用的结构,必须针对特定的系统做修正
需求文件结构
简介
词汇
使用者需求定义
系统架构
系统需求规格
系统模型
系统演化
附录
索引
需求工程程序
发现,分析以及确认系统需求的程序
RE 使用的程序会根据应用领域,参与人员以及发展需求的组织有很大的差异
然而,下列几项通用活动则是所有程序共通的
需求撷取
需求分析
需求确认
需求管理
需求工程程序
可行性研究
可行性研究可决定提出的系统是否有价值
它是一项短暂活动,著重於检查下列几个重点
此系统对组织的整体目标是否有贡献
此系统是否可以利用目前的技术,在有限的成本以及时程限制下制作完成
此系统是否可以和其他现有系统做整合
可行性研究实作
依据对资讯的评估(需要什麼),资讯的收集以及报表的撰写
询问组织中的人员下列问题
若系统无法实现,组织会如何处理
目前的程序有哪问题
提议的系统有何帮助
有哪些整合上的问题
是否需要新的技术 需要哪些技能
提议的系统必须支援哪些功能
撷取与分析
有时候称为需求撷取或发现需求
它包括让技术人员与客户一起合作找出相关的应用领域,应该提供的服务以及系统的操作限制等
还可能牵涉到终端使用者,经理人员,负责维护的工程师,领域专家或是工会等.这些都称为「专案关系人」(stakeholders)
需求分析的问题
专案关系人不知道他们真正要什麼
专案关系人会以自己的辞汇来表示需求
不同专案关系人可能会产生互相冲突的需求
组织和政治的因素可能也会影响系统的需求
分析过程中若需求遭变更可能会出现新的专案关系人,而造成商业环境的变更
需求分析程序
程序活动
了解领域 (Domain understanding)
收集需求 (Requirements collection)
分类 (Classification)
解决冲突 (Conflict resolution)
排列优先顺序 (Prioritisation)
检查需求 (Requirements checking)
系统模型
在需求分析活动中可能会产生不同模型
需求分析可能牵涉到造成这些不同模型的三种结构化活动
分割(Partitioning).识别实体之间的结构化关系(部分关系)
抽象化(Abstraction).识别出各实体的一般化
投射(Projection).识别出观察问题的不同方法
系统模型将在第 7 章做介绍
观点式撷取法
专案关系人代表观察问题或问题观点的不同方法
这种多重观点的分析非常重要,因为分析系统需求时没有唯一正确的方法
观点的类型
资料来源或消化处 (Data sources or sinks)
负责产生或使用资料的观点,分析过程包括辨识产出或消耗的资料以及视资料来源与消化处为合法的假设
表示架构 (Representation frameworks)
此观点可被视为是一种特殊的系统模型.使用单一表示方式可能会漏掉某些需求.这种观点尤其适用於即时系统
服务接收者 (Receivers of services)
系统外部以及从系统接收到服务的观点,大部分适用於互动式系统
外部观点
很自然的可以将终端使用者视为系统服务的接收者
这些观点可以很自然的构筑需求的撷取
很容易决定观点是否合理
这些观点和服务可以用来构筑非功能需求
以方法为主的分析
需求分析中广泛运用的方法,依据某个结构化方法的应用来了解系统
这些方法有不同的强调处,有些是特别为需求撷取而设计,有些则与设计方法比较接近
这里使用观点式方法(viewpoint-oriented method, VORD)为例,它也可以用来说明观点的使用方式
VORD 方法
VORD 程序模型
识别观点
找出接收系统服务的观点,以及辨识出提供给各个观点的特定服务
建构观点
将相关的观点组成阶层架构,共通的服务放在阶层架构的上层,下层观点则继承自上层观点
观点文件
修饰已辨识出的观点和服务的描述
对应观点与系统
将分析转换为物件导向式的设计
VORD 标准格式
系统物件上可提供的服务
供应者:
非功能需求上的限制性服务
非功能需求:
子观点名称
子VPs:
可收到的服务上的观点名称
观点:
服务描述文件
服务:
关於服务规格
规格:
事件情境是描述系统针对观点事件如何回应
事件:
观点资讯的属性
原理:
观点资讯的属性
属性:
服务名称
文件:
观点名称
文件:
服务范本
观点范本
情境法 (Scenarios)
情境用来描述系统实际的使用方式
这个方法有助於需求撷取,因为用这个方法比抽象叙述更容易得到系统的需求
情境法对概略的需求描述加入详细资讯尤其有帮助
情境描述
情境开头的系统状态描述
情境中正常的事件流程描述
可能发生的问题以及解决方法的描述
同一时间可能发生的其他活动
情境完成后的系统状态描述
事件情境法
事件情境法可以用来描述系统如何回应某些特殊事件,例如「开始交易」事件
VORD 使用下列几个惯用的图形来表示事件情境
欲提供与交付的资料
控制资讯
例快处理
下一个预期的事件
资料与控制分析的表示符号
由观点提供的资料以及要交给观点的资料以椭圆表示
进入或离开方块的控制资讯表示在每个方块的上方
离开此方块的资料表示在每个方块的右边
例外状况则出现在方块的下方
预期发生的下一个事件名称则以灰底颜色显示在方块中
例外状况描述
大部分的方法都不包含描述例外状况的工具
此例中,例外状况有
逾时:客户可能在限定的时间内输入错误的PIN,卡片会被退回.
无效卡:无法辨识卡片,卡片也会被退回.
遗失卡:卡片被辨识出为遗失卡,机器会自动收回此卡片.
使用个案
使用个案是 UML 中以情境为主的技术,它可以识别互动中的行为者,以及描述互动本身
利用一组使用个案来描述系统中所有可能的互动
利用顺序图在使用个案中加入详细资讯,显示系统处理事件的顺序
需求确认
用来确定需求是否定义了顾客真正想要的系统
需求错误造成的成本非常高,所以确认的动作很重要
在系统交付之后修正需求错误的成本可能会比修护实作的错误高出100倍之多
需求检查
确实性:系统提供的功能是否能够支援客户的需求
一致性:是否有任何需求产生冲突
完整性:是否包含客户所需的所有功能
实现性:需求是否可以在有限的预算和可用技术下实作完成
可验证性:需求是否可以接受检查
需求确认技术
需求审查
有系统的人为分析需求
雏形法
使用可执行的系统模型来检查需求,参见第 8 章
测试案例产生法
为需求发展测试案例以检查其测试性
自动化一致性分析
检查结构化需求描述的一致性
需求审查
在拟定需求定义时必须定期的进行审查
客户和承包商的人员都应该参与审查
审查可以是正式的 (有完整的文件)或非正式的.开发者,客户和使用者之间若有良好的沟通便可以提早解决问题
审查检查
可验证性(Verifiability):需求是否如叙述情形一样能够真的进行测试
可了解性(Comprehensibility):系统的采购人员或直接使用者是否能够适当的了解这些需求
可追踪性(Traceability):是否清楚的记录需求来源
可调适性(Adaptability):需求是否可调整改变,而不会造成其他系统需求太大的影响
自动化需求一致性检查
需求管理
需求管理是在需求工程程序及系统开发期间管理需求变更的程序
需求通常是不完整且不一致的
在程序期间,当商业需求改变或是对正在开发的系统有更好的了解,就会出现新的需求
不同观点会不同的需求,而这些需求通常会产生矛盾
需求变更
不同观点产生的需求,其优先顺序在开发过程中会有所改变
系统的客户可能会以商业的观点来指定需求,而这些观点可能会与终端使用者的需求产生冲突
系统的商业和技术环境在开发的过程中也会有所改变
需求演化
持久和短暂的需求
持久需求(Enduring requirements):指非常稳定的需求,来自组织的核心活动.例如,医院通常会有医生和护士.这些需求可能是从领域模型而来
短暂需求(Volatile requirements):系统开发期间或系统开始运作之后可能发生改变的需求.若以医院为例,政府的健保政策可能就会有随时改变的需求
需求分类
易变的需求 (Mutable requirements)
因组织的营运环境改变而造成的需求改变
新出现的需求 (Emergent requirements)
顾客在系统开发期间了解系统的发展之后所出现的新需求
随之发生的需求 (Consequential requirements)
引进电脑系统之后所造成的需求
相容需求 (Compatibility requirements)
根据某个特殊系统或组织中商业流程而来的需求
需求管理规划
在需求工程程序期间,你必须规划:
需求识别
如何识别每一项个别的需求
变更管理程序
分析需求变更时的程序
追踪策略
有关需求之间的关系,且需要进行维护的大量资讯
支援的 CASE 工具
帮助管理需求变更时所需的支援工具
可追踪资讯(Traceability)
可追踪资讯是指需求,需求来源以及系统设计之间的关系
来源可追踪资讯
将需求与提出这些需求的专案关系人做一个连结
需求可追踪资讯
将相依的需求做连结
设计可追踪资讯
将需求和设计做连结
需求变更管理
应该将所有提出的变更套用至需求中
主要阶段
问题分析:讨论需求的问题并且提出变更
变更分析与成本预估:评估变更对其他需求的影响
变更实作:修改需求文件和其他文件,以反映变更
需求变更管理