梁文新 办公室：综合楼108 电 话： 87571625 wxliang@dlut.edu.cn 软件工程导论 梁文新 办公室：综合楼108 电 话： 87571625 wxliang@dlut.edu.cn

答疑 系统流程图和数据流图有什么区别？ 相同点 不同点 具有相同功能和目标 都表达了系统中数据流动的情况 不同点 系统流程图涉及到目标系统的物理处理部件，如磁盘，磁带，显示器等，而DFD仅关注过程内数据的处理，而把具体处理数据的物理部件和物理分布忽略 系统流程图因为涉及到目标系统的物理处理部件，因而符号较多，而DFD中则仅有4种基本符号 DFD涉及到系统之外的人和组织（起点和终点），而系统流程图仅涉及系统的内部部件 2019/4/18 liang@computer.org

2019/4/18 liang@computer.org

第三章 需求分析(Requirement Analysis) 3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-关系图 3.5 数据规范化 3.6 状态转换图 3.7 其他图形工具 3.8 验证软件需求 2019/4/18 liang@computer.org

Why Requirement Analysis？ 软件开发最为重要的目的之一就是要开发出真正满足用户需求的软件产品 为此首先必须准确、清晰、深入地理解和获取用户的真正需求 全面准确地掌握软件需求是软件开发工作获得成功的前提和关键 不论设计和编码工作做得如何出色，不能满足用户的需求则一切都失去了意义 2019/4/18 liang@computer.org

Why Requirement Analysis？ 需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?（What）” 需求分析的任务不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作 即对目标系统提出完整、准确、清晰、具体的要求 2019/4/18 liang@computer.org

Why Requirement Analysis？ 需求分析是获取、求精、建模、书写规格说明和复审的过程 为发现真正的需求，首先应该从宏观角度调查、分析用户所面临的问题 即需求分析的第一步是尽可能准确地了解用户当前的情况和需要解决的问题 分析员对用户提出的初步要求应该反复求精多次细化，才能充分理解用户的需求，得出对目标系统的完整、准确和具体的要求 2019/4/18 liang@computer.org

Why Requirement Analysis？ 为了更好理解问题，常常采用建立模型的方法 模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述 模型=一组图形符号+组织这些符号的规则 结构化分析(SA)就是一种建立模型的活动，通常建立数据模型、功能模型和行为模型等三种模型 除了用分析模型表示软件需求之外，还要写出准确的软件需求规格说明书(Software Requirements Specification, SRS) 模型既是软件设计的基础，也是编写软件规格说明的基础 2019/4/18 liang@computer.org

Why Requirement Analysis？ 在分析软件需求和编写软件规格说明的过程中，用户与分析员都起着关键的、必不可少的作用 用户与开发者之间需要通信、沟通的内容非常多，在双方交流信息的过程中很容易出现误解或遗漏，也可能存在二义性 不仅在整个需求分析过程中应该采用行之有效的通信技术，集中精力细致工作 对需求分析的结果(分析模型和规格说明)必须严格审查 2019/4/18 liang@computer.org

Why Requirement Analysis？ 结构化分析方法应遵循的准则 必须理解和表示问题的信息域，根据这条准则应该建立数据模型(Data Model) 必须定义软件应完成的功能，这条准则要求建立功能模型(Function Model) 必须表示作为外部事件结果的软件行为，这条准则要求建立行为模型(Behavior Model) 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节 2019/4/18 liang@computer.org

3.1 需求分析的任务 3.1.1 系统的综合要求 1. 功能需求(Functional Requirements) 2. 性能需求(Performance Requirements/Non-functional Requirements) 3. 可靠性和可用性需求(Reliability & Usability) 4. 出错处理需求(Error Processing) 对外部错误如何响应；对系统内部错误如何响应 5. 接口需求(Interface) UI, Hardware/software, Communication, etc. 6. 约束(Constraints) Precision, Tools, Design, Hardware 7. 逆向需求(Reverse Requirements) 说明系统不应该做什么 8. 将来可能提出的要求(Future Requirements) 2019/4/18 liang@computer.org

3.1 需求分析的任务 3.1.2 分析系统的数据要求 3.1.3 系统的逻辑模型 3.1.4 修正系统的开发计划 任何软件系统本质上都是信息处理系统,因此需要建立数据模型（E-R图） 数据字典(Data Dictionary，DD) 层次方框图(Hierarchical Block Diagram) Warnier图 3.1.3 系统的逻辑模型 DFD、E-R图、状态转换图、DD、主要的处理算法描述 3.1.4 修正系统的开发计划 2019/4/18 liang@computer.org

需求分析的过程 (Lawrence Pfleeger & Atlee, 2006) Elicitation Analysis Specific -ation Validation SRS Collectuser’s req’ts Understand & model desired behaviour Document behaviour of proposed SW system Check our spec matches user’s req’ts 2019/4/18 liang@computer.org (Lawrence Pfleeger & Atlee, 2006)

更详细的需求分析过程 2019/4/18 liang@computer.org

3.2 与用户沟通获取需求的方法 软件需求分析总是从两方或多方之间的通信开始。用户面临的问题需要用基于计算机的方案来解决；开发者应该对用户的需求作出反应，给用户提供帮助。这样就产生了相互通信的需求。 从开始通信到真正相互理解的道路通常是充满坎坷的 良好的通信技术有助于加快理解的过程 访谈(Interview) 访谈(或称为会谈)是最早开始运用的获取（不是分析）用户需求的技术，也是迄今为止仍然广泛使用的主要的需求分析技术。 2019/4/18 liang@computer.org

访谈 访谈有两种基本形式，分别是正式的和非正式的访谈 在正式的访谈中，系统分析员将提出一些事先准备好的具体问题，例如，询问客户公司销售的商品种类、雇用的销售人员数目以及信息反馈时间应该多快等 在非正式的访谈中，将提出一些可以自由回答的开放性问题，以鼓励被访问的人员表达自己的想法，例如，询问用户为什么对目前正在使用的系统感到不满意 2019/4/18 liang@computer.org

访谈 当需要调查大量人员的意见时，向被调查的人员分发调查表(Questionnaire)是一个十分有效的做法 在对用户进行访谈的过程中使用情景分析技术往往非常有效。所谓情景分析(Scenario Analysis)就是对用户运用目标系统解决某个具体问题的方法和结果进行分析 2019/4/18 liang@computer.org

某出版社系统调查表 编号 提出问题 1 您在哪个部门工作？ 2 出版业务流程是什么？ 3 您每日都处理那些文件、数据、报表？ 4 工作中手工处理特别麻烦的事情是什么？ 5 工作中手工处理什么问题解决不了？影响效率的问题有哪些？ 6 您认为提高工作效率，节省工作时间，减轻工作强度可采取哪些办法？ 编号 提出问题 7 您的部门需要成本核算和统计的内容有哪些？ 8 您的部门采用计算机管理工作情况如何？ 9 如何改进业务流程使之更合理？ 10 哪些问题是目前传统手工方法根本无法解决的？ 11 出版社计算机管理信息系统需要解决什么问题？ 2019/4/18 liang@computer.org

3.2.2 面向数据流自顶向下求精 数据决定了系统所需要的处理和算法，是需求分析的出发点 结构化分析方法——面向数据流的自顶向下的逐步求精进行需求分析的方法 高层数据流图细化到元素级 从输出端回溯确定数据来源(DD)，定义算法(IPO图) 逐步细化不断求精 2019/4/18 liang@computer.org

3.2.3 简易的应用规格说明技术 FAST(Facilitated Application Specification Techniques) 提倡用户与开发者密切合作，共同标识问题，提出解决方案的要素，商讨不同的方法并指定基本的需求 简易的应用规格说明技术已经成为信息系统界使用的主流技术 2019/4/18 liang@computer.org

3.2.3 简易的应用规格说明技术 FAST(Facilitated Application Specification Techniques) 在中立地点(Neutral place)举行由开发者和用户双方出席的会议 制定准备会议和参加会议的规则(Rules) 提出一个议事日程(Agenda)，这个日程应该足够正式，以便能够涵盖所有要点；同时这个日程又应该足够非正式，以便鼓励自由思维 Brainstorming encouraged 由一个“协调人”(Facilitator)来主持会议 使用一种“定义机制”(Definition Mechanisms) sheets, flipcharts, wallboards, stickers, etc. 达成一个共同目标(Common Goal) 标识问题、提出解决方案要素、商讨不同的方法以及在有利于实现目标的氛围中指定初步的需求 2019/4/18 liang@computer.org

3.2.4 快速建立软件原型 构建原型的要点是，它应该实现用户看得见的目标系统的主要功能(例如屏幕显示或打印报表)，省略目标系统的“隐含”功能(例如修改文件) 快速原型应该具备的首要特性是“快速” 快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型，以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识 快速原型应该具备的第二个特性是“容易修改” 如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型的第二版，以更好地满足用户的需求 在实际开发软件产品时，“修改—试用—反馈”的过程可能重复多遍，如果修改耗时过多，势必延误软件开发时间 2019/4/18 liang@computer.org

3.2.4 快速建立软件原型 构建原型的方法和工具 第四代技术（4GL） 可重用的软件构件 形式化规格说明和原型环境 DB查询及报表生成、界面生成工具 可重用的软件构件 软件体系构件(程序)、过程构件(模块)、数据结构 形式化规格说明和原型环境 Z语言等（Chap. 4） 2019/4/18 liang@computer.org

3.3 分析建模与规格说明 3.3.1 分析建模 模型：是为了理解事物而对其做出的一种抽象，是对事物的一种无歧义的书面描述 模型=一组图形符号+组织这些符号的规则 结构化分析实质是一种创建模型的活动，通过需求分析而建立的模型必须达到下述的三个基本目标 描述用户的需求 为软件设计工作奠定基础 定义一组需求，一旦开发出软件产品之后，就可以用这组需求为标准来验收该产品 2019/4/18 liang@computer.org

3.3 分析建模与规格说明 数据 字典 功能建模 数据建模 行为建模 处 数 理 据 规 对 格 流图 象 说 描 明 述 控制规格说明 E-R图 状态转换图 处 理 规 格 控制规格说明 数 据 对 描 象 述 说 明 功能建模 数据建模 行为建模 2019/4/18 liang@computer.org

3.3.2 软件需求规格说明 软件需求规格说明(SRS)——分析阶段的最终成果 自然语言：容易书写、容易理解 形式化方法：无歧义、明确、完整（Chap. 4） 2019/4/18 liang@computer.org

SRS的框架 引言 信息描述 功能描述 行为描述 检验标准 参考书目 附录 系统参考文献、整体描述、软件项目约束 信息内容表示、信息流（数据流、控制流）表示 功能描述 功能划分、功能描述、控制描述 行为描述 系统状态、事件和响应 检验标准 性能范围、测试种类、期望的软件响应、特殊考虑 参考书目 附录 2019/4/18 liang@computer.org

3.4 实体—关系图 (Entity-Relationship Diagram) 数据模型包含三种相互关联的信息：数据对象、描述数据对象属性及数据对象彼此间相互连接的关系。 数据对象 数据对象是对软件必须理解的复合信息的表示。所谓复合信息是指具有一系列不同性质或属性的事物，因此，仅有单个值的事物(例如长度，名称)不是数据对象 数据对象可以是外部实体(产生和使用信息的事物)、事物(如报表)、角色(如教师、学生)、行为或事件(选课), 组织单位, 地点或结构 数据对象只封装了数据，没有包含作用于这些数据上的操作 2019/4/18 liang@computer.org

3.4 实体—关系图 (Entity-Relationship Diagram) 属性 属性定义了数据对象的性质和特征 为了唯一地标识数据对象的某一个实例，定义数据对象中的一个属性或几个属性为关键字，简称键 (key) 应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性 2019/4/18 liang@computer.org

3.4 实体—关系图 (Entity-Relationship Diagram) 关系：数据对象彼此之间相互连接的方式称为关系(联系) 一对一联系(1∶1) 一对多联系(1∶N) 多对多联系(M∶N) 关系本身也可能有属性 2019/4/18 liang@computer.org

ER模型表示方法 ER图中包含实体(即数据对象)、关系和属性三种基本成分 通常用矩形框代表实体，用连接相关实体的菱形框表示关系 用椭圆形或圆角矩形表示实体(或关系)的属性 并用无向边把实体(或关系)与其属性连接起来 2019/4/18 liang@computer.org

某校教学管理E-R图 2019/4/18 liang@computer.org

学生和课程之间的E-R图 学号 姓名 课号 课名 m n 专业 学生 选课 课程 学时 年级 学分 学号 姓名 课号 课名 1 n n 1 2019/4/18 liang@computer.org

ER图的其他符号表示法 X Y 一个X与一个Y相关联 X Y 一个X与一个或多个Y相关联 X Y 一个X与零个或一个Y相关联 X Y Z 一个X与一个Y或Z相关联 X Y Z 一个X与一个Y与Z相关联 2019/4/18 liang@computer.org

ER图的建立过程 对系统的数据域和功能域进行分析，确定系统中所涉及的实体 例如，在工资计算系统中，单位对职工的工作情况进行考勤，根据出勤结果、基本工资档案、奖金及扣款计算职工的实发工资 因此，工资系统中所涉及的实体就包括职工、出勤、奖励和扣款 2019/4/18 liang@computer.org

ER图的建立过程 确定系统中各实体之间的关系 确定各实体及关系的属性 如工资计算系统中，一名职工一个月只有一条出勤记录，因此职工和出勤两个实体之间是一对一的关系 一名职工在一个月中对应着多项扣款，如水电费、缺勤扣款、个人所得税等，因此职工和扣款之间是一对多的关系 同理，一名职工在一个月中可以获得多项奖励，因此职工和奖金之间也是一对多的关系 确定各实体及关系的属性 例如，工资计算系统的职工实体具有职工号、性别、职称、年龄、部门、基本工资等属性 2019/4/18 liang@computer.org

工资计算系统的E-R模型 2019/4/18 liang@computer.org

思考题 请为某仓库的管理设计一个ER模型 该仓库主要管理零件的订购和供应等事项。仓库向工程项目提供零件，并且根据需要向供应商订购零件 2019/4/18 liang@computer.org

思考题参考答案 2019/4/18 liang@computer.org

3.5 数据规范化 第一范式(1 NF) 第二范式(2 NF) 第三范式(3 NF) 每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构 第二范式(2 NF) 满足第一范式的条件，而且每个非关键字属性都由整个关键字决定（而不是由关键字的一部分来决定） 第三范式(3 NF) 符合第二范式条件，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述（即一个非关键字属性值不依赖于另一个非关键字属性值） 2019/4/18 liang@computer.org

非2 NF的示例 现假设有一个关系所具有的属性如下：学生学号、姓名、性别、出生年月、籍贯、政治面貌、课程名称、成绩 依赖关系如下： 学生学号→姓名 学生学号→性别 学生学号→出生年月 学生学号→ 籍贯 学生学号→政治面貌 学生学号、课程名称→成绩 2019/4/18 liang@computer.org

非3 NF的示例 现假设有一个关系所具有的属性如下:学生学号、姓名、性别、出生年月、籍贯、政治面貌、学生所在系、系所在地点。数据元素之间的依赖关系如下 学生学号→姓名 学生学号→性别 学生学号→出生年月 学生学号→ 籍贯 学生学号→政治面貌 学生学号→学生所在系 学生学号→系所在地点 学生所在系→系所在地点 2019/4/18 liang@computer.org

3.6 状态转换图(STD) 状态转换图(State Transition Diagram, STD)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为 状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式 在STD中用圆形框或椭圆框表示状态，通常在框内标上状态名。状态规定了系统对事件的响应方式 系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态 初态、终态、中间状态 2019/4/18 liang@computer.org

3.6 状态转换图(STD) 事件是在某个特定时刻发生的事情，它是对引起系统从一个状态转换到另一个状态的外界事件的抽象。简而言之，事件就是引起系统状态转换的控制信息 在状态图中，从一个状态到另一个状态的转换用箭头线表示，箭头表明转换方向，箭头线上标上事件名 必要时可在事件名后面加一个方括号，括号内写上状态转换的条件。也就是说，仅当方括号内所列出的条件为真时，该事件的发生才引起箭头所示的状态转换 2019/4/18 liang@computer.org

状态图中使用的主要符号 事件说明 [守卫条件] / 动作表达式 事件名 / 动作表达式 entry, exit, do 2019/4/18 liang@computer.org

号码验证 [无效号码] 号码验证 [有效号码] 电话系统的状态图 2019/4/18 liang@computer.org

思考题 复印机的工作过程大致如下：未接到复印命令时处于闲置状态，一旦接到复印命令则进入复印状态，完成一个复印命令规定的工作后又回到闲置状态，等待下一个复印命令；如果执行复印命令时发现没纸，则进入缺纸状态，发出警告，等待装纸，装满纸后进入闲置状态，准备接收复印命令；如果复印时发生卡纸故障，则进入卡纸状态，发出警告，等待维修人员来排除故障，故障排除后回到闲置状态 试用状态转换图描绘复印机的行为 2019/4/18 liang@computer.org

思考题参考答案 2019/4/18 liang@computer.org

3.7 其他图形工具 3.7.1 层次方框图(Hierarchical Block Diagram) 2019/4/18 liang@computer.org

3.7 其他图形工具 3.7.2 Warnier图(Warnier-Orr图) 1974年，法国人 J.D.Warnier 提出了一种LCP（Logical Construction of Programs，逻辑构造程序）。他利用顺序、选择、重复三种结构表示信息的层次分解，并指出可以从信息层次结构推导出程序结构 1981年Ken Orr对Warnier的工作进行了扩充，使其不仅包含了Warnier的信息层次结构，还引进了数据流和处理功能，从而发展成为一种需求分析方法：Data Structured Systems Development (DSSD) 2019/4/18 liang@computer.org

示例：报纸自动组版系统 1．首版 1）标题新闻 2）国内新闻 3）本地新闻 2．商业金融版 1）股市行情 2）商业新闻 3）广告 3．文化体育版 1）文化、体育新闻 2）散文 3）新书评论 2019/4/18 liang@computer.org

示例：报纸自动组版系统 花括号内的信息条目构成顺序关系 花括号从左至右排列表示树型层次结构 符号“⊕”表示不可兼具的选择关系 “￣”表示“非” 圆括号内的数字表示重复次数 （1,n）表示重复结构 （1）或不标次数表示顺序结构 （0,1）表示选择结构 标题新闻 国内新闻 本地新闻 股市行情(0,1) 商业新闻 广告(1,5) 文化、体育新闻 散文  新书评论 文化体育版 首 版 商业金融版 报 纸 2019/4/18 liang@computer.org

3.7 其他图形工具 IPO图(Input Process Output Diagram) IPO图是输入、处理、输出图的简称 左边框中列出有关的输入 中间框中列出主要的处理 右边框中列出产生的输出 处理的顺序暗示了执行的顺序 箭头指出数据通信的情况 2019/4/18 liang@computer.org

3.7 其他图形工具 IPO图 2019/4/18 liang@computer.org

3.8 验证软件需求 验证需求的四个方面及方法 一致性：任何一条需求不能与其他需求相互矛盾 实现性：硬件、软件技术都可以实现 用形式化语言书写，借助相关软件工具来验证 实现性：硬件、软件技术都可以实现 仿真或性能模拟技术 完整性：包含用户所需要的每一个功能或性能 使用原型系统 有效性：确实能够解决用户面对的问题 2019/4/18 liang@computer.org

3.8 验证软件需求 验证需求需要回答以下问题： 系统定义的目标是否与用户的要求一致 系统需求分析阶段提供的文档资料是否齐全 文档中的描述是否完整、清晰、准确地反映了用户的要求 被开发系统的数据流与数据结构是否正确且充足 系统主要功能是否已包含在规定的软件范围之内且被充分说明 设计的约束条件或限制条件是否符合实际 是否存在开发的技术风险 是否详细制定了检验标准、它们能否对系统定义进行确认 2019/4/18 liang@computer.org

3.8 验证软件需求 用于需求分析的软件工具 工具要求 工具举例 （1）必须有形式化的语法 （2）使用这个软件工具能够导出详细的文档 （3）必须提供分析或验证规格说明书中的不一致性和冗余性的手段 （4）使用这个软件工具之后，应该能够改进通信状况 工具举例 RSL (Requirement Statement Language) PSL/PSA (Problem Statement Language/ Problem Statement Analyzer) 2019/4/18 liang@computer.org

结构化分析实例 1 问题陈述 某校财务科长要求系统分析员研究一下用学校自己的微型计算机生成工资明细表和各种财务报表的可能性 问题定义 可行性研究 需求分析 2019/4/18 liang@computer.org

2 问题定义 预期将获得的经济效益能超过开发这个系统的成本么？ 用户面临的问题究竟是什么？ 项目预期规模 该校一直为人工计算工资和编写报表，工作量大，成本高 项目预期规模 目前计算工资所花费的成本 新系统的开发成本 运行费用 2019/4/18 liang@computer.org

2 问题定义 目前，每个月由两名会计用半个月时间计算工资和编制报表，一名会计每个月的工资和岗位津贴共约2000元，因此，每年为此项工作花费的人工费约2.4万元 绝大多数单位希望3年内收回投资，因此，投资7.2万元是投资额度的上限值 这些数字能够使用户对项目规模有一个大概的了解 2019/4/18 liang@computer.org

2 问题定义 输出：关于系统规模和目标的报告书 2019/4/18 liang@computer.org

3 可行性研究 目标：用最小的代价尽快确定问题是否能解 步骤： 澄清系统规模和目标 研究现有系统 2019/4/18 liang@computer.org

3 可行性研究 现有的工资支付系统 教师 职工 课时表 任务表 审核数据 审核后 的数据 排序 专用表格 计算 课时费 岗位津贴 工资总额 个人所得税 住房公积金 保险费 实发工资 工资表 银行 工资 明细表 编制报表 报表 更新分类表 分类帐 会计 2019/4/18 liang@computer.org 现有的工资支付系统

3 可行性研究 导出高层逻辑模型 工资支付系统的数据流图 D1 事务数据 教师 职工 1 收集 数据 2 审核 3 加工事务 D4 报表 5 更新 分类帐 D3 工资明细表 D2 工资表 会计 银行 4 分发工资 明细表 定时假设 处理 运行频率 1 每月一次 2 3 4 5 2019/4/18 liang@computer.org 工资支付系统的数据流图

3 可行性研究 进一步确定系统规模和目标 导出供选择的解法 （1）低成本方案：每两个月发一次工资； （2）中成本方案：基本上复制现有系统，以机器操作代替人工操作； （3）高成本方案：建立中央数据库，为开发完整的管理信息系统做好准备，并且把工资支付系统作为该系统的第一个子系统，成本约为12万元 2019/4/18 liang@computer.org

3 可行性研究 中等成本方案的成本/效益分析 2019/4/18 liang@computer.org

3 可行性研究 推荐最佳方案 草拟开发计划 写出可行性分析报告并提交审查 2019/4/18 liang@computer.org

4 需求分析 导出更精确的数据流图 需求分析过程： 沿数据流图回溯 写出文档初稿 定义逻辑系统 细化数据流图 2019/4/18 liang@computer.org

4 需求分析 补充后的工资支付系统数据流图 D5 年度数据 教师 职工 1 收集 数据 2 审核 3 加工事务 D6 人事数据 5 更新 分类帐 D3 工资明细表 D2 工资表 会计 银行 4 分法工资 明细表 D1 事务数据 6 人事科 D4 报表 2019/4/18 补充后的工资支付系统数据流图 liang@computer.org

4 需求分析 对“加工事务数据”的细化 D5 年度数据 D6 人事数据 D2 工资表 3.1 取数据 3.2 计算正常 工资 3.5 印表格 工资明细表 D1 事务数据 D4 报表 3.3 计算超额 课时费 3.4 更新年度 数据 对“加工事务数据”的细化 2019/4/18 liang@computer.org

4 需求分析 书写正式的需求规格说明书 技术审查和管理复审 2019/4/18 liang@computer.org

作业 P. 73：第3题 2019/4/18 liang@computer.org