软件工程需求分析.pptx

《软件工程需求分析.pptx》由会员分享，可在线阅读，更多相关《软件工程需求分析.pptx（44页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、3.1 案例分析一 高校工资管理系统设计与实现 1.沿数据流图回溯6754321第1页/共44页3.1 案例分析一 高校工资管理系统设计与实现 2.写文档初稿主要组成:数据流图,数据字典,黑盒形式的算法描述(IPO图).6754321第2页/共44页第3页/共44页3.1 案例分析一 高校工资管理系统设计与实现 3.定义逻辑系统6754321对高层数据流图进行细化第4页/共44页对高层数据流图进行细化第5页/共44页3.1 案例分析一 高校工资管理系统设计与实现 4.细化数据流图“加工事务处理”分解为5个功能:取数据,计算正常工资,计算超额课时费,更新每月数据,输出表格.6754321第6页/

2、共44页详细的数据流图第7页/共44页3.1 案例分析一 高校工资管理系统设计与实现 5.系统数据字典“工资明细表”描述如下数据流：“工资明细表”来源：印表格处理去向：工资明细表存储组成：教职工编号、教职工姓名、基本工资、职务、职称、生活补贴、书报费、交通费、洗理课时费、岗位津贴、工资总额、个人所得税、住房公积金、保险费、实发工资6754321第8页/共44页3.1 案例分析一 高校工资管理系统设计与实现 6.书写正式文档细化的数据流图,数据字典和黑盒形式的算法描述,是需求规格说明书的主要内容.7.技术审查与管理复审数据流图是技术审查的重点,用数据字典和IPO图辅助说明.管理方面的复审:由领导

3、对经费支出和开发进度进行审查.6754321第9页/共44页3.2 案例分析二 招聘考试成绩管理系统1234561.考生情况分析每年报名参加招聘考试的学生有几千名，分三个专业：法律、行政、经济。考生报名时登记如下内容：姓名、性别、出生年月、地址、报考专业。考生报名后，招聘办要为考生安排考场，编排准考证号、打印准考证。考生分别来自全市各区，考生参加考试的考场一般就近安排。第10页/共44页3.2 案例分析二 招聘考试成绩管理系统1234561.考生情况分析考场管理：考场有编号、考场地址，假设每个考场可容纳的人数预先确定，一个考场安排考生人数满了，再安排下一考场。同一考场安排专业相同的考生。准考证

4、号采用六位数字编码，编码规则如下：第一位是专业号，第二位是所在区号，第三四位是考场号，第五六号是考场内顺序号。第11页/共44页3.2 案例分析二 招聘考试成绩管理系统2.成绩输入考生的试卷再每个科目考试结束偶按考场分别装订成册的，同一考场的试卷按准考证号的先后顺序排列的。因而，考试成绩的输入是按考场、分科目进行的，同一考场、同一门科目的成绩按准考证号的顺序一次进行输入。123456第12页/共44页3.2 案例分析二 招聘考试成绩管理系统3.录用考生成绩输入后，由计算机计算每位考生三门考试科目的成绩总分。然后每三个专业分别将考生按总分从高到低进行排序。排序后的考生名单供用人单位录用时作参考。

5、被某单位录用的考生，应在供录用的名单中去除，同时添加到已录用名单中。123456第13页/共44页3.2 案例分析二 招聘考试成绩管理系统4.输出需求 需要输出以下几种内容：考生的准考证；发给每位考生的考试成绩单；招聘考试办公室留存的按准考证号顺序排列的成绩表；三个专业分别按总分从高到底排序的考生成绩表；发给每位考生的录用通知书；录用名单。123456第14页/共44页3.2 案例分析二 招聘考试成绩管理系统5.数据流图和数据字典本系统数据流图如下图所示：123456第15页/共44页第16页/共44页3.2 案例分析二 招聘考试成绩管理系统123456本系统数据字典如下：数据项定义专业代号=

6、【1=法律|2=行政|3=财经学】准考证号编排规则：第一位是专业代号，第二位是所在区号，第三四位是考场号，第五六位是顺序号。考生=准考证号+姓名+性别+出生日期+地址+1课程名+成绩3+总分+名词+录用否+录用单位准考证=准考证号+姓名+专业+考场号+考场地址第17页/共44页3.2 案例分析二 招聘考试成绩管理系统123456本系统数据字典如下：数据项定义考生文件分两种：一种按准考证号码的顺序排列，另一种按考生成绩总分由高到低排列。录用通知书=准考证号+姓名+专业+1课程名+成绩3+总分+地址第18页/共44页3.2 案例分析二 招聘考试成绩管理系统123456 处理算法排序：输出三个专业的

7、考生分别按总分由高到低的次序排列名单，供录用参考。录用原则：各专业按考生成绩总分从高分到低分的次序录用，总分相同时专业课成绩高的优先录用。第19页/共44页3.2 案例分析二 招聘考试成绩管理系统6.IPO图123456第20页/共44页3.3 需求分析的任务需求分析的任务不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。第21页/共44页3.3 需求分析的任务只有用户才真正知道自己需要什么，但是他们并不知道怎样用软件实现自己的需求，用户必

8、须把他们对软件的需求尽量准确、具体地描述出来；用户分析员分析员知道怎样用软件实现人们的需求，但是在需求分析开始时他们对用户的需求并不十分清楚，必须通过与用户沟通获取用户对软件的需求。第22页/共44页3.3 需求分析的任务必须理解并描述问题的信息域，根据这条必须理解并描述问题的信息域，根据这条准则应该建立准则应该建立数据模型数据模型。必须定义软件应完成的功能，这条准则要必须定义软件应完成的功能，这条准则要求建立功能模型求建立功能模型。必须描述作为外部事件结果的软件行为，必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。这条准则要求建立行为模型。必须对描述信息、功能和行为的模型进行必

9、须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。分解，用层次的方式展示细节。需求分析遵循下述需求分析遵循下述准则准则第23页/共44页3.3 需求分析的任务1.功能需求这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。2.性能需求性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。3.3.1 确定对系统的综合要求第24页/共44页3.3 需求分析的任务3.可靠性和可用性需求可靠性需求定量地指定系统的可靠性。可用性与可靠性密切相关，它量化了用户可以使用系统的程度。4.出错处理需求

10、这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么?第25页/共44页3.3 需求分析的任务5.接口需求接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求硬件接口需求软件接口需求通信接口需求第26页/共44页3.3 需求分析的任务6.约束设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。在需求分析阶段提出这类需求，并不是要取代设计(或实现)过程，只是说明用户或环境强加给项目的限制条件。应使用的硬件平台精度工具和语言约束设计约束应使用的标准常见的约束有常见的约束有常见的约束有第27页/共44页3.3 需求分

11、析的任务7.逆向需求逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。8.将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。第28页/共44页3.3 需求分析的任务分析系统的数据要求通常采用建立数据模型的方法。为了提高可理解性，常常利用图形工具辅助描绘数据结构。常用的图形工具有层次方框图和Warnier图。3.3.2 分析系统的数据要求第29页/共44页3.3

12、需求分析的任务综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。3.3.3 导出系统的逻辑模型第30页/共44页3.3 需求分析的任务根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。3.3.4 修正系统的开发计划第31页/共44页3.4 与用户沟通获取需求的方法3.4.1 访谈正式访正式访谈谈正式访谈时，系统分析员将提出一些事先准备好的具体问题。非正式访谈非正式访谈在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自

13、己的想法。第32页/共44页3.4 与用户沟通获取需求的方法信息处理系统的基本功能都是把输入数据转变成需要的输出信息。数据决定了需要的处理和算法。在可行性研究阶段许多实际的数据元素被忽略了，需求分析阶段是定义这些数据元素的时候了。通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。为此，通常从数据流图的输出端着手分析。3.4.2 面向数据流自顶向下求精第33页/共44页3.4 与用户沟通获取需求的方法可行性研究阶段产生的数据流图，许多具体的细节没有包括在里面，因此沿数据流图回溯时常常遇到下述问题：为了得到某个数据元素需要用到数据流图中目前还没有

14、的数据元素，或者得出这个数据元素需要用的算法尚不完全清楚。为此，往往需要向用户和其他有关人员请教与讨论，他们的回答使分析员对目标系统的认识更深入更具体了，系统中更多的数据元素被划分出来了，更多的算法被搞清楚了。第34页/共44页3.4 与用户沟通获取需求的方法通常把分析过程中得到的有关数据元素的信息记录在数据字典中，把对算法的简明描述记录在IPO图中。通过分析而补充的数据流、数据存储和处理，应该添加到数据流图的适当位置上。随着分析过程的进展，经过问题和解答的反复循环，分析员越来越深入具体地定义了目标系统，最终得到对系统数据和功能要求的满意了解。第35页/共44页面向数据流自顶向下求精过程第36

15、页/共44页3.4 与用户沟通获取需求的方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。首先进行初步的访谈，通过用户对基本问题的回答，初步确定待解决的问题的范围和解决方案。3.4.3 简易的应用规格说明技术第37页/共44页3.4 与用户沟通获取需求的方法然后开发者和用户分别写出“产品需求”。选定会议的时间和地点，并选举一个负责主持会议的协调人。邀请开发者和用户双方组织的代表出席会议，并在开会前预先把写好的产品需求分发给每位与会者。面向团队的需求收集方法的优点：开发者与用户不分彼此，齐心协力，密切合作；即时讨论并求精；有能导出规格说明的具体步骤。第38

16、页/共44页3.4 与用户沟通获取需求的方法快速建立软件原型是最准确、最有效、最强大的需求分析技术。构建原型的要点是，它应该实现用户看得见的功能，省略目标系统的“隐含”功能。3.4.4 快速建立软件模型第39页/共44页3.4 与用户沟通获取需求的方法快速原型应该具备的第一个特性是“快速”。快速原型的目的是使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。因此，原型的某些缺陷是可以忽略的，只要这些缺陷不严重地损害原型的功能，不会使用户对产品的行为产生误解。快速原型应该具备的第二个特性是“容易修改”。如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型

17、的第二版。第40页/共44页3.5 分析建模与规格说明所谓模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成。为了开发出复杂的软件系统，系统分析员从不同角度抽象出目标系统的特性，使用精确的表示方法构造系统的模型，验证模型是否满足用户对目标系统的需求，并在设计过程中逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型。3.5.1 分析建模第41页/共44页3.5 分析建模与规格说明实体-联系图，描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形。数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能，因此，数据流图是建立功能模型的基础。状态转换图，指明了作为外部事件结果的系统行为，描绘了系统的各种行为模式和在不同状态间转换的方式，是行为建模的基础。第42页/共44页3.5 分析建模与规格说明自然语言的规格说明具有容易书写、容易理解的优点，为大多数人所欢迎和采用。为了消除用自然语言书写的软件需求规格说明书中可能存在的不一致、歧义、含糊、不完整及抽象层次混乱等问题，人们主张用形式化方法描述用户对软件系统的需求。3.5.2 软件需求规格说明第43页/共44页感谢您的观看！第44页/共44页