- 4
- 0
- 约1.49千字
- 约 63页
- 2019-02-02 发布于天津
- 举报
2019年用实例说明需求工程的设计原则和描述方法
用实例说明需求工程的设计原则和描述方法;需求的定义;内容摘要;Alan Davis 把需求工程定义为“直到(但不包括)把软件分解为实际架构构件之前的所有活动” (强调做什么)
Herb Krasner定义了需求工程的五阶段生命周期:需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理
;需求获取:资料收集
需求分析与协商:理解分析整理
系统建模:用模型描述(写下来)
需求规约:完善需求文档并定稿
需求验证:验证确认
需求管理:整体规划及变更管理;需求获取 ;需求分析与协商 ;系统建模 ;需求规约(Specification) ;需求验证 ;在实际的开发过程中,获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上,这些活动是交叉的、递增的和反复的。;需求管理 ;回顾:需求的各种形式;内容摘要;需求获取方法与策略 ;访谈与调查的原则 ;需求调研实例—学生选课系统;需求调研实例—学生选课系统;内容摘要;需求分析原则 ;信息域 ;信息流表示了数据和控制在系统中流动时的变化方式,输入对象被变换为中间信息(数据和/或控制),然后进一步被变换为输出
例如用数据流图表示的数据加工处理的全过程
信息结构表示了各种数据和控制项的内部组织(数据之间的关系)
数据或控制项将被组织为n维表还是树形结构?
在结构的语境内,什么信息是和其他信息相关的?
信息包含在单个结构中,还是使用不同的结构?
在某信息结构中的信息如何和在另一个结构中的信息相关? ;需求描述和分析技术;整个问题;2、问题抽象(1/2);问题抽象(2/2);3、需求建模(1/2);需求建模(2/2);4、多视点分析;多视点分析:
例如围绕着超市收银系统
顾客希望?
收银员希望?
经理希望?
系统管理员希望?
最终的软件系统是相关方的综合体,各种期望可能存在冲突,需要进一步分析权衡;需求协商 ;通常会议是解决冲突最快的方式
参加者:发现冲突、遗漏或重叠的分析员,以及可以解决发现的问题的项目相关人员
会议应该讨论那些非正式讨论不能解决的问题
通常会议分为三个阶段:
叙述阶段
讨论阶段
决策阶段 ;内容摘要;需求规约的原则-1;需求规约的原则-2;需求规约的原则-3;需求规约 ;引言:陈述软件目标,在基于计算机的系统语境内进行描述。
信息描述:给出软件必须解决问题的详细描述,记录信息内容和关系、流和结构。
功能描述:描述解决问题所需的每个功能。其中包括,为每个功能说明一个处理过程;叙述设计约束;叙述性能特征;用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。
行为描述:描述作为外部事件和内部产生的控制特征的软件操作。
检验标准:描述检验系统成功的标志。即对系统进行什么样的测试,得到什么样的结果,就表示系统已经成功实现了。它是“确认测试”的基础。
参考书目:包含了对所有和该软件相关的文档的引用,其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。
附录:包含了规约的补充信息,表格数据、算法的详细描述、图表以及其他材料。;需求验证 ;内容摘要;需求管理;需求变更的原因;关键实践;唯一地标识每一项需求;分级的用户需求管理;分级需求管理的好处;需求工程实例;需求获取;需求获取;需求获取;需求分析、协商;需求分析、协商;系统建模-系统数据流模型;系统建模-系统数据库模型;需求规约-功能描述;需求规约;需求规约-用???图;需求规约-流程图;需求规约-流程图;需求规约-流程图;性能需求与运行需求;性能需求与运行需求;需求验证
原创力文档

文档评论(0)