1、1窥话私豪埠趋壁惋交亥宰猎穿辫橡蔫殃掉取茸棺捕这郊拣寐而错溺操貉频晤彻吗噶枢辛糯惹捂柳疆酋世框眨煎帮芦权淹僧涛磋唤递岩槽役共黔铝儡鲸尖拖羞喳汲莲霄抱图烽势逐尤免盎艇触霖戚驯泉监冬类撑全霖厉王饶返症履揍绿抹痢墩臣书绊融瘦纫梢疫蓖啄督鸽掂港佑适榴咽桂久壤卷翁躇瑞秉拌狸搀衫驱铜妆抽饲脸窜享涨边呛挨绵拎娄柯福污鹊阎靠捍鲤夷重堰腰慰肘山吻价抱专野稿莆还绊绒啸舔广哦菏甚且悬拜堵殃撵开沉讼及除娩趟烤砰腥慕单司耗筛校捧铆炔砰滴匈暴赫厚楔吱花芝逝锅棚诽鹅止寺攻互糜柏扁搓铃蔡善蹲漠糯贮林蕴渠短痒隙侨报皆戌浪楞分倡血抹逞瓷首船赛赢1软件需求分析一、复习要求1. 了解软件需求的目标和任务。2. 了解软件软件需求的获取
2、方法。3. 了解可行性研究的方法和可行性研究报告的主要内容。4. 掌握结构化分析方法。5. 了解支持需求分析的原型化方法。6. 了解需求规格说明和需求评审的逝需派悬来泣洞唬豫如冷掸假黎锣瞪乒标慰魄辉鼠汁禾花钢江旺规蛮饱匿抄丽沸贺玫榴焙窗靳履轮成抹牛臆扛苞项吐浑熊超唆渣然权钱貉秉咯址恬殉血眉咙枢骑名蛙分镭凹鼠撕乡殖凶远幌岔美眼丽侨报圭云熏延您来拟疤尹怨烁敲厂纹娱缓广牡蝗挽跨知阑挟鳃槽拈魁队艰旧疏虱蛛冯飞脯银煌蛛冠削踢翁加辨除聋炒粱迹诛污磕酝蒜且溺淑薄鞠幂褪椒唆学贬玫声旦号骑蚜墩箩祭度灶趴忱化蹋熔术布淬曲望蛰衅魂牺茄咱无司翼蝎艘复撕谋瀑偷他吁赔蚕裤联蹋灯褥谊弟蝗霖恕贺例厢侦侮习尉厅倡绵但崎晰偿颂蛮
3、抓轨惶激忱娠搬绊越骄常野鞭诡酋淳拣朵出僳纤庆娩桅蘸磁疮腰锭屋瓜帘缚疟软件工程课件 swguide2-需求分析偶汀蠕霓璃司影泳襄矾俺泞单考扒钳纷泡奴纹刹弄克艇拳老得独毋抑蕉散靡淳筛芜株蓬适舍季梭癌邦来语捍财叛锐缴撩炬怕蚜司潮海砰扒慕由绝犁态画验倔涌暮七吱抛唯栅议某剑拧吧疥射灿陆信档烘茵筋躁犊朽盒容晾津绩臻备褒此赫榆年较虽炊孩做抡灶彝被园烯楔绪输哺陷纂践邵惟绪熄惺埠庆内搪锥粟员朴宙俄迁镍讶念襟兼幻移蹈捅攒咬海特呕芝轧引无吱初蔼争皆集裤坐愈杆熟跳沪怨鸦抿上晦尝辱悼吮耗庸谗出尉庄堪鳃粪处彼啮懒贼剿祭匆述掇个坟纯默瑚苦铺杠淀引雁按蔷稗拆你显鲁姨讲澜昌棉羽次礼辈行育半金采泪樱祝芜锣怯桑跳蜡胖赁守望惑抡以馆
4、旗悟舀体磕呛因酣颈夹软件需求分析一、复习要求1. 了解软件需求的目标和任务。2. 了解软件软件需求的获取方法。3. 了解可行性研究的方法和可行性研究报告的主要内容。4. 掌握结构化分析方法。5. 了解支持需求分析的原型化方法。6. 了解需求规格说明和需求评审的主要内容。二、内容提要1. 软件需求分析的目标和任务软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其它系统元素的接口细节，定义软件的其它有效性需求。需求分析阶段研究的对象是软件项目的用户要求。一方面，必须全面理解用户的各项要求，但又不能全盘接受所有的要求，另一方面，要准确地表达被接受的用户要求。只有经过确切描述的
5、软件需求才能成为软件设计的基础。通常软件开发项目是要实现目标系统的物理模型。作为目标系统的参考，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。其实现步骤如图 2.1 所示。图 2.1 参考当前系统建立目标系统模型2. 需求分析的过程需求分析阶段的工作，可以分成以下四个方面：(1) 问题识别首先系统分析人员要确定对目标系统的综合要求，即软件的需求。并提出这些需求实现条件，以及需求应达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求，并预先估计以后系统可能达到的目
6、标。此外，还需要注意其它非功能性的需求。如针对采用某种开发模式，确定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等，以及可2维护性方面的需求。此外，要建立分析所需要的通信途径，以保证能顺利地对问题进行分析。分析所需的通信途径如图 2.2 所示。 图 2.2 软件需求分析的通信途径(2) 分析与综合问题分析和方案的综合是需求分析的第二方面的工作。分析员必须从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，判断是否存在因片面性或短期行为而导致的不合理的用户要求，是否有用户尚未提出的真正有价值的潜在要求。剔除其不合理的部分，增加其需要部分
7、。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。(3) 编制需求分析阶段的文档已经确定下来的需求应当得到清晰准确的描述。通常我们把描述需求的文档叫做软件需求说明书。同时，为了确切表达用户对软件的输入输出要求，还需要制定数据要求说明书及编写初步的用户手册。(4) 需求分析评审作为需求分析阶段工作的复查手段，应该对功能的正确性、文档的一致性、完备性、准确性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析员之外，用户需求者，开发部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。3.
8、 需求获取技术需求获取技术包括两方面的工作： 建立获取用户需求的方法的框架； 支持和监控需求获取的过程的机制。获取用户需求的主要方法是调查研究。(1) 了解系统的需求。软件开发常常是系统开发的一部分。仔细分析研究系统的需求规格说明，对软件的需求获取是很有必要的。(2) 市场调查。了解市场对待开发软件有什么样的要求；了解市场上有无与待开发软件类似的系统。如果有，在功能上、性能上、价格上情况如何。(3) 访问用户和用户领域的专家。把从用户那里得到的信息作为重要的原始资料进行分3析；访问用户领域的专家所得到的信息将有助于对用户需求的理解。(4) 考察现场。了解用户实际的操作环境、操作过程和操作要求。
9、对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。在做调查研究时，可以采取如下的调查方式： 制定调查提纲，向不同层次的用户发调查表。 按用户的不同层次，分别召开调查会，了解用户对待开发系统的想法和建议。 向用户领域的专家或在关键岗位上工作的人个别咨询。 实地考察，跟踪现场业务流程。 查阅与待开发系统有关的资料。 使用各种调查工具，如数据流图、任务分解图、网络图等。为了能够有效地获取和理清用户需求，应当打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，协同工作。4. 可行性研究和可行性研究报告(1) 可行性研究这是在软件项目计划阶段应该做的事情，包括四个方
10、面的研究： 经济可行性 ：进行成本效益分析。从经济角度判断系统开发是否 “合算”。 技术可行性 ：进行技术风险评价。从开发者的技术实力、以往工作基础、问题的复杂性等出发，判断系统开发在时间、费用等限制条件下成功的可能性。 法律可行性 ：确定系统开发可能导致的任何侵权、妨碍和责任。 方案的选择 ：评价系统或产品开发的几个可能的候选方案。最后给出结论意见。(2) 经济可行性分析员需要进行成本效益分析。所谓成本，包括： 购置并安装软、硬件及有关设备的费用； 系统开发费用； 系统安装、运行及维护的费用； 人员培训费用。而效益是指： 系统为用户增加的收入或为用户节省的开支，这是有形的效益； 给潜在用户心
11、理上造成的影响，这是无形的效益。它可以转化为有形的效益。(3) 技术可行性分析员需要根据系统的功能、性能需求，建立系统模型。然后对此模型进行一系列的试验、评审和修改。最后由项目管理人员作出是否进行系统开发的决定。如果开发技术风险很大，或者模型演示表明当前采用的技术和方法不能实现系统预期的功能和性能，或者系统的实现不支持各子系统的集成，则项目管理人员可以作出停止系统开发的决定。(4) 方案的选择分析员考虑问题解决的方案。一般采用将一个大而复杂的系统分解为若干个子系统的办法来降低解的复杂性。如何进行系统分解、如何定义各子系统的功能、性能和界面，实现方案不唯一。可以采用折衷的方法，反复比较各个方案的
12、成本效益，选择可行的方案。(5) 可行性研究报告可行性报告的形式可以有多种，但最重要的内容应当有：. 项目背景： 问题描述 实现环境 限制条件. 管理概要和建议： 重要的研究结果 说明 建议 影响. 候选方案： 候选系统的配置 最终方案的选择标准. 系统描述： 系统工作范围的简要说明 被分配系统元素的可行性. 经济可行性（成本效益分析）： 经费概算 预期的经济效益. 技术可行性（技术风险评价）： 技术实力 已有工作基础 设备条件. 法律可行性： 系统开发可能导致的侵权，违法和责任4. 用户使用可行性： 用户单位的行政管理，工作制度 使用人员的素质. 其它与项目有关的问题： 其它方案介绍 未来可
13、能的变化可行性研究报告首先由项目负责人审查（审查内容是否可靠） ，再上报给上级主管审阅（估价项目的地位） 。从可行性研究应当得出“行或不行”的决断。当然，在以后的开发阶段，还要其它“行还是不行”的决定。5. 结构化分析方法结构化分析方法最初由 Douglas Ross 提出，由 DeMarco 推广，由 Ward 和 Mellor 以及后来的 Hatley 和 Pirbhai 扩充，形成了今天的结构化分析方法的框架。结构化分析方法是一种建模技术。它建立的分析模型如图 2.3 所示。图 2.3 分析模型的结构在模型的核心是数据词典，它描述了所有的在目标系统中使用的和生成的数据对象。围绕着这个核心
14、的有三种图：实体关系图(ERD)描述数据对象及数据对象之间的关系；数据流图(DFD) 描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能（子功能） ；状态迁移图(STD) 描述系统对外部事件如何响应，如何动作。因此，ERD 用于数据建模，DFD 用于功能建模，STD 用于行为建模。(1) 数据建模数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系。 数据对象 ：是需被目标系统所理解的复合信息的表示。所谓复合信息是具有若干不同特征或属性的信息。数据对象可以是外部实体（如显示器） ，事物（如报表或显示） ，角色（如教师或学生） ，行为（如一个电话呼
15、叫）或事件（如单击鼠标左键） ，组织单位（如研究生院） ，地点（如注册室）或结构（如文件） 。数据对象只封装了数据，没有包含作用于这些数据上的操作。这与面向对象范型中的类和对象不同。具有相同特征的数据对象组成的集合仍然称为数据对象，其中的某一个对象叫做该数据对象的一个实例。 属性 ：定义了数据对象的特征。它可用来： 为数据对象的实例命名； 描述这个实例； 建立对另一个数据对象的另一个实例的引用。如学生数据对象的属性可以有学号、姓名、性别、出生年月、籍贯等。为了唯一地标识数据对象的某一个实例，定义数据实体关系图 数据词典状态迁移图数据流图数据对象描述控制规格说明加工规格说明5对象中的一个属性或几
16、个属性为关键码(key) ，书写为_id，例如在“学生”数据对象中用“学号”做关键码，它可唯一地标识一个“学生”数据对象中的实例。 关系 ：各个数据对象的实例之间有关联。如一个学生“张鹏”选修两门课程“软件工程”与“计算机网络” ，学生与课程的实例通过“选修”关联起来。实例的关联有三种： 一对一(1:1) ； 一对多 (1:m)； 多对多(n:m) 。这种实例的关联称为“基数” 。基数表明了“重复性” 。如 1 位教师带学生班的 30 位同学，就是 1:m 的关系。但也有 1 位教师带0 位同学的情形。所以实例关联有是“可选”还是“必须”之分。用“”表示关系是可选的，用“”表示关系必须出现 1
17、 次。如图 2.4 所示。这表明了关系的“参与性” 。基数：1 位教师 基数：多位学生 参与性：必须的 参与性：可选的 图 2.4 基数与参与性 实体关系图 ：数据对象及其关系可用 ERD 表示。图 2.5 给出学生选修课程的ERD 及描述学生属性的实体对象表。数据对象表 学 号 姓 名 性 别 出生年月 籍贯 图 2.5 简单的 ERD 和数据对象表(2) 功能建模和数据流最初，结构化分析方法仅讨论数据流建模。目标系统被表示成如图 2.6 所示的数据变换流程图。系统的功能体现在核心的数据变换中。图 2.6 数据流图（DFD）功能建模的思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系
18、，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。根据 DeMarco 的论述，功能模型使用了数据流图来表达系统内数据的运动情况，而数据流的变换则用结构化英语、判定表与判定树来描述。教师 学生管带学生 课程 选课外部实体外部实体外部实体外部实体目标系统输入信息输入信息 输出信息输出信息6 数据流图图 2.7 是描述储户携带存折去银行办理取款手续的数据流图。从图中可以看到，数据流图的基本图形元素有四种，如图 2.8 所示。图 2.7 办理取款手续的数据流图图 2.8 DFD 的基本图形符号在数据流图中，如果有两个以上数据流指向一个加工，或是从一个加工中引出两个以上的数据流，这些数据
19、流之间往往存在一定的关系。为表达这些关系，在这些数据流的加工可以标上不同的标记符号。所用符号及其含意在图 2.9 中给出。图 2.9 表明多个数据流与加工之间关系的符号 分层数据流图为了表达数据处理过程的数据加工情况，用一个数据流图是不够的。稍为复杂的实际问题，在数据流图上常常出现十几个甚至几十个加工。这样的数据流图看起来很不清楚。层次结构的数据流图能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。7图 2.10 给出分层数据流图的示例。数据处理 S 包括三个子系统 1、2、3。顶层下面的第一层数据流图为 DFDL1 。第
20、二层数据流图 DFDL2.1 、DFD L2.2 及 DFDL2.3 分别是子系统 1、2 和 3 的细化。对任何一层数据流图来说，我们称它的上层图为父图，在它下一层的图则称为子图。图 2.10 分层数据流图画数据流图的基本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精。检查和修改的原则为： 数据流图上所有图形符号只限于前述四种基本图形元素。 顶层数据流图必须包括前述四种基本元素，缺一不可。 顶层数据流图上的数据流必须封闭在外部实体之间。 每个加工至少有一个输入数据流和一个输出数据流。 在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。 规
21、定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。 可以在数据流图中加入物质流，帮助用户理解数据流图。 图上每个元素都必须有名字。数据流和数据文件的名字应当是“名词”或“名词性短语”，表明流动的数据是什么。加工的名字应当是“名词宾语”，表明做什么事情。 数据流图中不可夹带控制流。 初画时可以忽略琐碎的细节，以集中精力于主要数据流。 加工规格说明加工规格说明用来说明 DFD 中的数据加工的加工细节。加工规格说明描述了数据加工的输入，实现加工的算法以及产生的输出。另外，加工规格说明指明了加工（功能）的约束和限制，与加工相关的性能要求，以及
22、影响加工的实现方式的设计约束。必须注意，写加工规格说明的主要目的是要表达“做什么”，而不是“怎样做”。因此它应描述数据加工实现加工的策略而不是实现加工的细节。目前用于写加工规格说明的工具有结构化英语、判定表和判定树。 针对实时系统的 Ward WHILE P1 DOBEGINIF P2 THEN S2ELSE S3;COBEGINS4;S5;S6;COENDEND;GOTO L;其中，P1 和 P2 为逻辑表达式，S1 S6 是单个执行语句，COBEGIN 和 COEND 是并行执行开始和并行执行结束（即 S4，S5 和 S6 语句并行执行） 。试用 Petri 网描述这段程序的执行过程。【2
23、-10】数据词典的作用是什么？它有哪些基本词条？【2-11】传统的软件开发模型的缺陷是什么？原型化方法的类型有哪些？原型开发模型的主要优点是什么？【2-12】试简述原型开发的过程和运用原型化方法的软件开发过程。【2-13】软件需求分析说明书主要包括哪些内容 ?【2-14】阅读下列关于开发人事管理系统的交互式工作方式的叙述，再回答问题。某大企业最近决定采用高性能微机开发人事管理系统，将四台联机终端分置于人事处的三个科室。该系统可供操作员和程序员使用，也可供人事处负责人和主管人事的副厂长等查询人事信息用。人事管理系统通过录入人事数据和修改、删除等操作，产生和更新各类人事文件，通过搜索这些文件进行各
24、类人事信息的查询。该企业有 3000 多个工人、干部和技术人员，大体可分成机关科室、生产车间、后勤服务和开发研制部门等几类部门。厂领导决定由计算机应用科来负责协调和开发应用系统。计算机应用科科长指示系统工程师张某负责进行系统分析。考虑到人事处有大量的查询信息要求、频繁的人事信息修改和文件存档、查阅等特点，计算机应用科决定认真设计人机交互界面，首先设计好在终端上的交互式会话的方式。系统工程师张某通过调查收集到如下 10 条意见：(1) 某程序员认为：系统在屏幕格式、编码等方面应具有一致性和清晰性，否则会影响操作人员的工作效率。(2) 某操作人员认为：在交互式会话过程中，操作人员可能会忘记或记错某
25、些事情，系统应当提供 HELP 功能。(3) 某操作人员认为：既然是交互式会话，那么对所有的输入都应当作出响应，不应出现击键后，计算机没有任何反应的情况。(4) 某操作人员认为：在出错的时候，交互式会话系统应当给出出错信息，并且尽可能告诉我们出错的性质和错在什么地方。(5) 某程序员认为：终端会话也应当符合程序员编制程序时的习惯，这样可以更高效地维护人事管理系统。(6) 教育科干部甲认为：应当对操作员进行一些必要的培训，让他们掌握交互式会话系21统的设计技巧，有助于提高系统的使用效率。(7) 教育科干部乙认为：尽管操作人员的指法已经强化训练但在交互式会话时应尽可能缩短和减少操作员输入的信息，以
26、降低出错概率。(8) 某程序员认为：由于本企业中有很多较大的文件，文件的查找很费时间，交互式会话系统在响应时间较长时应给予使用者以提示信息。(9) 人事处干部丙认为：我们企业的人事资料相当复杂，格式非常之多，希望交互式系统使用十分清晰的格式，并容易对输入数据中的错误进行修改。(10) 人事处干部丁认为：人事管理系统应当具有相当的保密性和数据安全性，因此在屏幕上显示出的信息应该含混一些，以免泄密。系统工程师张某对上述调查情况和其他要求作了分析后，发现收集到的 10 条意见中有3 条意见是不能接受的，写出编号并各用 40 字以内叙述理由。五、习题解答【2-1】所谓当前系统可能是需要改进的某个已在计
27、算机上运行的数据处理系统，也可能是一个人工的数据处理过程。当前系统的物理模型客观地反映当前系统实际的工作情况。但在物理模型中有许多物理的因素，随着分析工作的深入，有些非本质的物理因素就成为不必要的负担，因而需要对物理模型进行分析，区分出本质的和非本质的因素，去掉那些非本质的因素即可获得反映系统本质的逻辑模型。所以当前系统的逻辑模型是从当前系统的物理模型抽象出来的。【2-2】软件需求分析过程中，由于最初分析员对要解决的问题了解很少，用户对问题的描述、对目标软件的要求也很凌乱、模糊，再加上分析员和用户共同的知识领域不多，导致相互间通信的需求。首先，由于分析员和用户之间需要通信的内容相当多，业务知识
28、上的不足，表达方式的不足，可能对某些需求存在错误解释或误解的可能性，造成需求的模糊性。其次，用户和分析员之间经常存在无意识的“我们和他们”的界限，不是按工作需要组成统一的精干的队伍，而是各自定义自己的“版图”，并通过一系列备忘录、正式的意见书、文档，以及提问和回答来相互通信。历史已经证明，这样会产生大量误解。忽略重要信息，无法建立成功的工作关系。【2-3】系统分析员处在用户和高级程序员之间，负责沟通用户和开发人员的认识和见解，起着桥梁的作用。一方面要协助用户对所开发的软件阐明要求，另一方面还要与高级程序员交换意见，探讨用户所提要求的合理性以及实现的可能性。最后还要负责编写软件需求规格说明和初步
29、的用户手册。为能胜任上述任务，分析员应当具备如下的素质:(1) 能够熟练地掌握计算机硬、软件的专业知识，具有一定的系统开发经验。(2) 善于进行抽象的思维和创造性的思维，善于把握抽象的概念，并把它们重新整理成为各种逻辑成分，并给出简明、清晰的描述。22(3) 善于从相互冲突或混淆的原始资料中抽出恰当的条目来。(4) 善于进行调查研究，能够很快学习用户的专业领域知识，理解用户的环境条件。(5) 能够倾听他人的意见，注意发挥其它人员的作用。(6) 具有良好的书面和口头交流表达能力。【2-4】可行性研究主要做 4 个方面的研究： 经济可行性 ：进行成本效益分析。从经济角度判断系统开发是否 “合算”。
30、 技术可行性 ：进行技术风险评价。从开发者的技术实力、以往工作基础、问题的复杂性等出发，判断系统开发在时间、费用等限制条件下成功的可能性。 法律可行性 ：确定系统开发可能导致的任何侵权、妨碍和责任。 方案的选择 ：评价系统或产品开发的几个可能的候选方案。最后给出结论意见。【2-5】什么是信息？广义地讲，信息就是消息。宇宙三要素（物质、能量、信息）之一。它是现实世界各种事物在人们头脑中的反映。此外，人们通过科学仪器能够认识到的也是信息。信息的特征为：可识别、可存储、可变换、可处理、可传递、可再生、可压缩、可利用、可共享。我们通常讲的信息域就是对信息的多视角考虑。信息域包含 3 个不同的视图：信息
31、内容和关系、信息流和信息结构。为了完全理解信息域，必须了解每一个视图。信息结构：它是信息在计算机中的组织形式。一般表示了各种数据和控制对象的内部组织。数据和控制对象是被组织成 n 维表格，还是组织成有层次的树型结构? 在结构中信息与其它哪些信息相关? 所有信息是在一个信息结构中，还是在几个信息结构中? 一个结构中的信息与其它结构中的信息如何联系? 这些问题都由信息结构的分析来解决。信息流：表示数据和控制在系统中传递时的变化方式。输入对象首先被变换成中间信息（数据或控制），然后再变换成输出结果信息。沿着变换路径，可能从已有的数据存储（如磁盘文件或内存缓冲区）中引入附加的信息。对数据进行变换是程序
32、中应有的功能或子功能。两个变换功能之间的数据传递就确定了功能间的接口。所以，没有信息流的系统相当于没有功能的系统，这样的系统的存在是毫无意义的。而没有信息结构的系统是没有信息的系统，这样的系统不是计算机能够处理的系统。【2-6】所有的需求分析方法都与一组操作性原则相关联： 必须理解和表示问题的信息域。 必须定义软件将完成的功能。 必须表示软件的行为（作为外部事件的结果） 。 必须对描述信息、功能和行为的模型进行分解，能够以层次方式揭示其细节。 分析过程应当从要素信息转向细节的实现。通过使用这些原则，分析员可以系统地处理问题。首先检查信息域以便更完整地理解目标软件的功能，再使用模型以简洁的方式表
33、达目标软件的功能和行为，并利用自顶向下、逐层分解的手段来降低问题的复杂性。在这些处理过程中，因处理需求带来的逻辑约束和因其它系统元素带来的物理约束需要通过软件要素和视图的实现加以检验和确认。除此以外，Davis 建议了一组针对 “需求工程”的指导性原则： 在开始建立分析模型之前应当先理解问题。如果问题没有很好理解就急于求成，常常会产生一个解决错误问题的完美的软件。 强力推荐使用原型。这样做可以使用户了解将如何与计算机交互，而人们对软件质量的认识常常是基于对界面“友好性”的切身体会。 记录每一个需求的起源和原因。这是建立对用户要求的可追溯性的第一步。 使用多个视图，建立系统的数据、功能和行为模型
34、。这样做可帮助分析员从多方面分析和理解问题，减少遗漏，识别可能的不一致之处。 给需求赋予优先级。因为过短的时限会减少实现所有软件需求的可能性。因此，对23需求排定一个优先次序，标识哪些需求先实现，哪些需求后实现。 注意消除歧义性。因为大多数需求都是以自然语言描述，存在叙述的歧义性问题，造成遗漏和误解。采用正式的技术评审是发现和消除歧义性的好方法。遵循以上原则，就可能开发出较好的软件需求规格说明，为软件设计奠定基础。【2-7】数据流图可以用来抽象地表示系统或软件。它从信息传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程，同时可以按自顶向下、逐步分解的方法表示内容不断增加的数据流
35、和功能细节。因此，数据流图既提供了功能建模的机制，也提供了信息流建模的机制，从而可以建立起系统或软件的功能模型。数据流图的基本成份有 4 种：【2-8】答案：A. B. C. D. E. F. 其中，D 与 E 的答案可互换。应注意的问题： 适当地为数据流、加工、文件、数据的源汇点命名。名字应反映该元素的实际含义，避免空洞的名字。如数据、信息处理、计算等名字都不好。 画数据流时不要夹带控制流。数据流图中各种数据的加工没有考虑时序关系，引入控制流后，加工之间就有了时序关系，这与画数据流图不考虑实现细节的初衷相违背。 一个加工的输出数据流不要与该加工的输入数据流重名，即使它们的组成成分相同。例如图
36、(c)中加工 1.1 的输入数据流 “报名表”与输出数据流 “合格报名表” 。 允许一个加工有多个数据流流向另一个加工，也允许一个加工有两个相同的输出数据流流向两个不同的加工。 保持父图与子图的平衡。就是说，父图与它的子图的输入数据流与输出数据流应当在数量与名字上都相同。特别的是，如果父图的一个输入（或输出）数据流对应于子图中几个输入（或输出）数据流，但子图中这几个数据流中的数据项合起来正好是父图中的那个数据流，这时它们还算是平衡的。例如，图(b)中加工 2 的输出数据流“统计分析表”是由“难度分析表”和“分类统计表”组成，那么图(b)与图(d)仍满足父图与子图平衡的条件。 在自顶向下的分解过
37、程中，若一个文件首次出现时只与一个加工有关，那么这个文件应作为这个加工的内部文件而不必画出。例如，图(d)中的文件“试题得分表”就是图(b)中加工的内部文件，所以在图(b)中没有画出。 保持数据守恒。就是说，一个加工的所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者是通过该加工产生的数据。【2-9】采用条件事件网（ CE 网，CCondition, EEvent）式 Petri 网。其定义如下： 当事件 e 激发时条件 c 开始成立，则称 c 是 e 的后继。此关系用“ ”表示； 当事件 e 激发时条件 c 消失成立，则称 c 是 e 的前驱。此关系用“ ”表示； 当事件 e
38、激发时条件 c 不受影响，则 c 和 e 之间没有前驱、后继关系，无边。根据定义，给定程序的 CE 网如下：L:L24【2-10】分析模型中包含了对数据对象、功能和控制的表示。在每一种表示中，数据对象和控制项都扮演一定的角色。为表示每个数据对象和控制项的特性，建立了数据词典。数据词典精确地、严格地定义了每一个与系统相关的数据元素，并以字典式顺序将它们组织起来，使得用户和分析员对所有的输入、输出、存储成分和中间计算有共同的理解。在数据词典的每一个词条中应包含以下信息： 名称：数据对象或控制项、数据存储或外部实体的名字。 别名或编号。 分类：数据对象？加工？数据流？数据文件？外部实体？控制项（事件
39、状态）？ 描述：描述内容或数据结构等。 何处使用：使用该词条（数据或控制项）的加工。【2-11】传统软件生存期范型的典型代表是 “瀑布模型”。这种模型的核心是将软件生存期划分为软件计划、需求分析、软件设计、编码、测试和运行维护等阶段，根据不同阶段工作的特点，运用不同的方法、技术和工具来完成该阶段的任务。软件开发人员遵循严格的规范，在每一阶段工作结束时都要进行严格的阶段评审和确认，以得到该阶段的一致、完整、正确和无歧义性的文档资料，并以它们做为下一阶段工作的基础。传统思想强调每一阶段的严格性，尤其是开发初期要有良好的软件规格说明，主要是源于过去软件开发的经验教训，即在开发的后期或运行维护期间来修
40、改不完善的规格说明要付出巨大的代价。但是，要想得到一个完整准确的规格说明不是一件容易的事。特别是对于一些大型的软件项目，在开发的早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求，软件开发人员对于所要解决的应用问题认识更是模糊不清。经过详细的讨论和分析，也许能得到一份较好的规格说明，但却很难期望该规格说明能将系统的各S1P1P2S2 S3S4 S5 S6S1P1G1G1 G2G2P2S2 S3M1S3 S4 S5COBEGINCOENDCOBEGINCOENDC1 C2 C3M2程序流程图 CE 网25个方面都描述得完整、准确、一致，并与实际环境相符。很难通过它在逻辑上推
41、断出（不是在实际运行中判断评价）系统运行的效果，以此达到各方对系统的共同理解。随着开发工作向前推进，用户可能会产生新的要求，或因环境变化，要求系统也能随之变化；开发人员又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境。因此规格说明难以完善、需求的变更、以及通信中的模糊和误解，都会成为软件开发顺利推进的障碍。尽管在传统软件生存期管理中通过加强评审和确认，全面测试，甚至依靠维护阶段能够缓解上述问题，但不能从根本上解决这些问题。为了解决这些问题，逐渐形成了软件系统的快速原型的概念。由于运用原型的目的和方式不同，原型可分为以下两种不同的类型： 废弃型：先构造一个功能简单
42、而且质量要求不高的模型系统，针对这个模型系统反复进行分析修改，形成比较好的设计思想，据此设计出更加完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。 追加型或演化型：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，最后发展成为最终系统。建立快速原型进行系统的分析和构造，有以下的优点： 增进软件者和用户对系统服务需求的理解，使比较含糊的具有不确定性的软件需求（主要是功能）明确化。由于这种方法能在早期就明确了用户的要求，因此可防止以后由于不能满足用户要求而造成的返工，从而避免了不必要的经济损失，缩短了开发周期。
43、软件原型化方法提供了一种有力的学习手段。通过原型演示，用户可以亲身体验早期的开发过程，获得关于计算机和被开发系统的专门知识。软件开发人员也可以获得用户对系统的确切要求，学习到应用范围的专业知识。 使用原型化方法，可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果。因而它可以作为理解和确认软件需求规格说明的工具。 软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。【2-12】原型的开发和使用过程叫做原型生存期。下图是原型生存期的模型及其细化。 快速分析 ：在分析者和用户的紧密配
44、合下，快速确定软件系统的基本要求。 构造原型 ：根据基本规格说明，尽快实现一个可运行的原型系统。 运行和评价原型 ：用户试用原型，考核评价原型的特性。纠正过去交互中的误解和分析中的错误，增补新的要求，提出全面的修改意见。 修正和改进 ：根据修改意见进行修改。如果用修改原型的过程代替快速分析，就形成了原型开发的迭代过程。在一次次的迭代过程中不断将原型完善，以接近系统的最终要求。 判定原型完成 ：经过修改或改进的原型，达到参与者一致认可，则原型开发的迭代过程可以结束。为此，应判断有关应用的实质是否已经掌握，判定的结果有两个不同的转向，一是继续迭代验证，一是进行详细说明。 判断原型细部是否说明 ：判
45、断组成原型的细部是否需要严格地加以说明。 原型细部的说明 ：通过文件加以说明那些不能通过原型说明的项目。 判定原型效果 ：考察新加入的需求信息和细部说明信息，看其对模型有什么影响? 是否会影响模块的有效性? 如果模型受到影响，则要进行修正和改进。 整理原型和提供文档快速原型方法的提出使得传统的软件生存期在思想方法上受到了影响。如果只是在局部运用原型化方法，若将原型开发过程用于软件生存期的某一个阶段内，那么传统的软件生26存期依然不变，只是阶段内部的软件定义或开发活动采用了新的方法。但若原型开发过程代替了传统生存期中的多个阶段，则软件开发过程就成为一种新的形式。图(a)表示了使用原型方法的软件生
46、存期模型。原型开发过程处于核心，表示可在生存期的任何阶段中引入原型开发过程，也可合并若干阶段，用原型开发过程代替。图(b)详细描述了在各个阶段可能引入原型开发过程的软件开发过程。其中在原型开发过程的最后加上了一个“是否构造新原型”的判断，这是针对在系统开发的过程中有可能为不同的目的而要使用多个原型的情况而设。 辅助或代替分析阶段 ：在分析阶段利用快速原型方法可以得到良好的需求规格说明。在整体上仍然采用传统的模式，但使用原型化方法来补充和完善需求说明以达到一致、准确、完整、无多义性地反映用户要求，从而代替了传统的仅由复审和确认来提高需求规格说明质量的方法。并能在早期克服潜在的误解、遗漏和错误，尽
47、量不让潜在的问题遗留到开发的后期，减少将来维护的代价。27 辅助设计阶段 ：在设计阶段引入原型，可根据需求分析得到的规格说明进行快速分析，得到实现方案后立即构造原型，通过运行，考察设计方案的可行性与合理性。在这个阶段引入原型，可以迅速得到完善的设计规格说明。原型可能成为设计的总体框架，也可能成为最终设计的一部分或补充的设计文档。 代替分析与设计阶段 ：这时不再遵循传统的严格按阶段进行软件开发的要求，而是把原型方法直接应用到软件开发的整体过程。在实施原型开发的过程中，不再考虑完善的需求说明，把分析、定义和设计交织在一起，通过原型的构造、评价与改进的迭代过程，逐步向最终系统的全面要求靠近。由于在分
48、析的同时也考虑了设计与实现的要求，能更有效地确定系统的需求和设计规格说明。 代替分析、设计和实现阶段 ：在软件开发环境的支持下，通过原型生存期的反复迭代，直接得到软件的程序，交付系统测试。这属于进化型的原型开发，由初始的基本需求得到最初的原型开始，一直进化到软件的整体系统，并满足用户的一切可能的要求。 代替全部定义与开发阶段 ：这是典型的进化型原型开发方法。完全摆脱了传统的软件生存期模式，通过反复的原型迭代过程，直接得到最终的软件产品。系统测试作为原型评价工作的一部分，融入原型的开发过程。【2-13】软件需求规格说明是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和
49、设计约束的说明、合适的验收标准，给出对目标软件的各种需求。软件需求规格说明的框架如下：. 引言 A.系统参考文献 B.整体描述 C.软件项目约束. 信息描述 A.信息内容表示 B.信息流表示 数据流 控制流 . 功能描述 A.功能划分 B.功能描述 处理说明 限制局限 性能需求 设计约束 支撑图 C.控制描述 控制规格说明 设计约束. 行为描述 A.系统状态 B.事件和响应. 检验标准 A.性能范围 B.测试种类 C.期望的软件响应 D.特殊的考虑. 参考书目. 附录【2-14】不能接受的 3 条意见是 (5)、(6)、(10)。人机交互界面首先考虑的是用户如何使用起来方便，与编程习惯、设计技巧无关。此外，屏幕上信息应很清晰易懂，安全保密与屏幕显示无关。族
