★ FEATURED ARTICLE 简介这份PPT课件围绕软件工程中的需求分析与面向数据流的建模方法展开适合软件工程专业学生、课程备考者以及需要梳理需求分析流程的初级开发者使用。全包仅含1个ppt文件体积约1.41MB轻量易取可直接用于课堂讲授、复习或自学翻阅。课件以一个小型图书馆管理系统贯穿始终从借还书、增删图书、按作者或专业领域检索等具体需求出发讲解现实世界到计算机世界的映射过程抽象与概念符号模型、当前系统物理模型与逻辑模型的抽取、目标系统逻辑模型的建立及细化验证等步骤均有展开。同时区分功能性需求与非功能性需求说明需求获取的内容以及性能、环境、界面等约束并对结构化开发方法与面向对象开发方法、面向信息流向与面向信息内容两类建模思路作了对照。目前已有226人学习适合用来建立需求分析的整体框架并对照案例理解建模过程。1. 从现实世界到计算机世界面向数据流分析的知识地图面向数据流的分析方法是软件工程需求分析阶段最经典的一条路线核心动作只有两个先把现实世界抽象成模型再把模型逐层细化到能指导设计。它看起来像“画图的”实际上是一套从现场调查、物理模型、逻辑模型一路走到数据流图、数据字典和加工说明的完整流程。适合两类人正在系统学软件工程、要交需求分析建模作业的以及复习备考、需要把“需求分析五步”“功能性与非功能性需求”“结构化与面向对象方法”串成一条线的人。下面按知识地图、模块要点、易漏点、复习清单推进。2. 需求分析的五个台阶从物理模型到逻辑模型的两级跃迁需求分析最容易被误解成“找用户聊几次、记几条功能”。真正要建立的是四张模型之间的转换关系当前系统的物理模型、当前系统的逻辑模型、目标系统的逻辑模型、目标系统的物理模型。中间两步是抽象后两步是落地。课件给的教材采购例子非常典型学生交购书申请教材科汇总成购书单财务开发票学生凭领书单领书这条链路里有人、有科室、有纸质单据是物理模型把“谁在哪个办公室”“哪张单子盖什么章”剥掉只剩下“审查有效性—开发票—开领书单—发书”这几个加工和数据流就是逻辑模型。这一章把五个台阶逐级拆开再把图书馆管理系统的功能清单和约束条件挂上去。2.1 五步流程拆开看从现场调查到需求验证课件把需求分析过程写成五步顺序不能乱因为每一步的产物都是下一步的输入。第一步是通过对现实环境的调查获得当前系统的物理模型。这一步的产物必须“具体到笨拙”有哪些岗位、哪些单据、单据在谁手里流转、每一步的输入输出是什么。教材采购例子里购书申请、购书单、发票、领书单构成一条完整的单据链缺一张后面就推不出对应的数据流。第二步是去掉具体模型中的非本质因素抽取现实系统的实质抽象出当前系统的逻辑模型。“非本质”这三个字是难点办公室编号不是本质审批环节才是本质单据纸张颜色不是本质单据承载的数据项才是本质。做完这一步物理模型里的具体部门和岗位消失加工和数据存储浮出来。第三步是分析当前系统与目标系统的差别建立目标系统的逻辑模型。差别通常来自两类东西哪些人工加工要被系统替代哪些新能力是原来没有的。教材采购例子里“审查并开发票”原来由人完成目标系统里变成一个系统加工并且多出一条“无效购书单”的异常分支——异常分支往往是目标系统逻辑模型里最容易漏的部分。第四步是对目标系统的逻辑模型进行细化、改进与优化。粗粒度的加工要拆成子加工数据流要补上数据项数据存储要落到数据字典。这一步决定了模型能不能被评审而不是只能被“看懂”。第五步是需求分析的验证。验证的对象不是代码而是模型本身每一个数据流是否有来源和去向每一个数据存储是否既被写又被读每一条约束是否写成了可判定的句子。步骤主要动作产物常见错法1现场调查、收集单据与流程当前系统物理模型直接画系统界面跳过现场2剔除非本质因素当前系统逻辑模型把部门名、房间号带进逻辑模型3对比当前与目标目标系统逻辑模型只写新增功能不写被替代的人工环节4细化、改进、优化分层数据流图、数据字典、加工说明只画一张总图加工不拆5验证评审记录、问题清单只给用户看界面草图不给模型这张表建议默写一遍。考试里“简述需求分析的过程”是高频题答题时把“物理模型→逻辑模型→目标逻辑模型→细化→验证”这条链写全比只写“收集需求、分析需求”多拿不少分。2.2 模型化与抽象化物理模型和逻辑模型差在哪课件对抽象的解释写得很“实验科学”抽象源于实验科学主要要素是数据采集方法和假设的形式说明、模型的构造与预测、实验结果分析在为可能的算法、数据结构和系统结构构造模型时使用抽象抽象的结果是概念符号模型。翻译成复习语言抽象不是“省略细节”而是“保留对当前问题有解释力的那一层把其余层换成符号”。由此可以整理出四个动词它们构成需求分析的主干动作模型化把现实世界中的流程、单据、角色整理成可描述的模型。抽象化从物理模型里去掉非本质因素得到逻辑模型回答“做什么”。具体化从逻辑模型走向目标系统的物理模型回答“怎么做”落到技术选型、部署、界面。实例化用具体数据和场景去检验模型比如拿“读者借走最后一本书”去跑一遍借阅流程。对比项物理模型逻辑模型描述对象具体的人、岗位、地点、单据加工、数据流、数据存储、外部实体回答的问题现在是谁在什么地方怎么做系统应该做什么稳定性随组织调整而变随业务规则变化才变典型产物现场流程图、单据流转图数据流图、数据字典、加工说明常见误用把部署图当物理模型把界面原型当逻辑模型最容易踩的坑是把“物理模型”理解成“部署架构”。在需求分析语境里物理模型指的是带具体实现细节的现实系统描述部署架构属于设计阶段的目标系统物理模型两者不是一个东西。另一个坑是逻辑模型里残留具体角色名比如写出“管理员甲审批”这类信息一旦进模型评审时就会被追问“甲休假了流程怎么走”。2.3 图书馆案例把五步流程走一遍课件配套的案例是一个小型图书馆管理系统功能五条、用户两类、约束三条规模小但要素齐全非常适合当模板背。编号功能使用角色主要涉及数据1借书、还书图书管理员借阅记录、图书状态、读者额度2增加/删除一本书图书管理员图书目录、馆藏数量3按作者名或专业领域检索一批书两类用户图书目录、检索条件4找出被某位读者借出的一批书普通读者借阅记录、读者标识5找出最近借走某本图书的读者图书管理员借阅记录、时间戳三条约束写得比功能更值钱因为它们直接决定了系统能不能通过验收馆中所有未借出的书籍能够供读者随时借阅同一时刻一本书不能既被借出又被借阅一个读者一次借出的书籍数目不能超过预定值。前两条是状态约束第三条是数量约束第三条里的“预定值”在需求阶段必须被追成一个明确数字否则就是一句正确的废话。把约束写成可执行的形式是检验需求是否“落地”的好办法。下面这段用最朴素的方式表达三条约束重点不在代码而在“每条约束对应一个可判定的判断”。# 小型图书馆借阅约束的最小表达把三条业务约束翻译成可判定的检查 MAX_BORROW 5 # 约束 3 中的“预定值”需求阶段必须追成具体数字 def can_borrow(reader, book, loans): # 约束 2同一时刻一本书不能既被借出又被借阅 active {l[book_id] for l in loans if l[returned_at] is None} if book[id] in active: return False, 该书在借状态冲突 # 约束 1未借出的书应可随时借阅不可借状态要能说清原因 if book[status] ! available: return False, 该书不在可借状态 # 约束 3未归还数量不得超过上限 holding [l for l in loans if l[reader_id] reader[id] and l[returned_at] is None] if len(holding) MAX_BORROW: return False, 已达单次借阅上限 return True, 允许借出参数说明MAX_BORROW是需求阶段就要和用户确认的业务参数不能留到编码时拍脑袋reader至少含id和读者类型book含id与statusloans是借阅记录集合returned_at为空表示未归还返回值是“是否允许 原因”原因字段在需求文档里对应异常流评审时要能逐条对上。这段代码真正想说明的是需求分析阶段的模型必须能回答“边界情况怎么办”。读者已借满 5 本还想借第 6 本、一本书刚被借走又被另一个读者点开、图书被标记为“遗失”但仍显示在架上——这些分支在数据流图里就是异常数据流在数据字典里就是状态字段的取值范围。案例虽小五脏俱全。3. 需求获取的四类内容功能、性能、环境与人的因素需求分析的五步解决“流程怎么走”需求获取解决“问什么”。课件把需求分成功能性需求与非功能性需求技术需求两大类功能性需求定义系统做什么描述系统必须支持的功能和过程非功能性需求定义系统工作时的特性描述操作环境和性能目标。这个二分法看起来简单实际答题时最常见的失分是把权限、并发、数据格式统统塞进“功能需求”。这一章把需求获取的内容拆成四块功能、性能、环境与界面、用户与人的因素每块给出可抄的提问清单和图书馆案例里的对应答案。3.1 功能性与非功能性先分清“做什么”和“做得怎么样”功能性需求的判据是“能不能用一个动词短语说清系统替谁完成了什么事”。图书馆案例里借书、还书、增删图书、按作者或专业领域检索、查某读者借出的书、查某本书最近的借阅人六条都是功能性需求因为它们都能对应到一个明确的输入、处理和输出。非功能性需求技术需求的判据是“它约束的是做法和品质不是业务动作本身”。响应时间、吞吐量、存储容量、操作系统与数据库、接口格式、用户培训成本都属于这一类。课件列出的需求获取三问——系统做什么、系统何时做什么、系统何时及如何修改或升级——前两问主要落在功能侧第三问往往被忽略但它是可维护性需求的源头图书分类规则变了要不要支持批量调整读者类型增加一种要不要改代码这里有个高频混淆点功能 4「找出被某位读者借出的一批书」只供普通读者使用其余功能供图书管理员使用。这属于功能性需求里的角色边界不是非功能性需求。判断标准很简单它改变的是“谁能触发哪个加工”所以进功能模型如果它改变的是“这个加工必须在 2 秒内返回”才进非功能清单。判断维度功能性需求非功能性需求技术需求提问方式系统要替谁完成什么系统要在什么条件下、达到什么水平典型表述读者可按作者名检索图书检索响应时间不超过 2 秒验收方式场景走通指标可测量图书馆案例借书、还书、增删书、两类检索并发借阅下的状态一致性、响应时间写需求文档时建议强制分成两张表一张功能清单、一张质量与技术约束清单。混在一张表里后面做数据流图时就会把“响应时间 2 秒”画成一条数据流这种图评审时基本一眼被挑出来。3.2 性能、环境、界面三个最常被一句“性能良好”糊弄过去的角落课件把非功能性需求拆得很细这几组指标值得原样抄进笔记。性能需求关注存储容量限制、执行速度、响应时间、吞吐量。图书馆案例里可以具体化为馆藏图书条目上限、借还操作的平均响应时间、开馆高峰时段并发借还的笔数。注意“响应时间”和“吞吐量”是两个方向前者看单次体验后者看单位时间处理能力需求里必须分开写。环境需求分硬件和软件两路。硬件设备包括机型、外设、接口、地点、分布、温度、湿度、磁场干扰等软件包括操作系统、网络、数据库等。这些词看着像机房验收清单实际是需求约束如果借阅台用的是固定式扫码外设那“还书”这个加工的输入方式就被限定了如果部署在多个馆区那“同一时刻一本书不能既被借出又被借阅”就变成跨节点的状态一致性问题而不是单机判断。界面需求问四件事有来自其它系统的输入吗有到其它系统的输出吗对数据格式有规定吗对数据存储介质有规定吗图书馆案例里读者信息可能来自学校的身份系统图书编目数据可能来自采购系统这两个接口的格式要求必须在需求阶段写清否则设计阶段只能返工。需求类别课件给出的问法图书馆案例里的落地答案性能需求容量、速度、响应时间、吞吐量馆藏上限、借还响应时间、高峰期并发笔数环境需求硬件机型、外设、接口、地点、分布、温湿度、磁场借阅台扫码设备、多馆区部署、网络条件环境需求软件操作系统、网络、数据库数据库类型、是否需要与身份系统对接界面需求外部输入输出、数据格式、存储介质读者信息接口格式、编目数据导入格式这一块复习时的自检方法是随便挑一条功能问自己“它在什么设备上、什么网络下、和谁交换数据、数据长什么样”。四个问题答不上来说明非功能需求还没写。3.3 用户与人两类用户带来的权限与容错需求课件把“用户或人的因素”单列一类问的是用户类型有哪些各种用户的熟练程度如何需受何种训练用户理解、使用系统的难度如何用户错误操作系统的可能性有多大这几问在图书馆案例里有非常具体的落点。用户类型直接决定了权限模型。普通读者只能查自己的借阅记录功能 4和检索图书功能 3图书管理员才能执行借还、增删图书、查某本书的借阅人功能 1、2、5。这意味着同一个“检索”加工在两类用户下的可见字段不同读者看到的借阅信息只涉及自己管理员看到的是全量。需求阶段把这条写清设计阶段才不会出现“读者接口能查到别人借了什么”这种翻车。熟练程度和训练成本决定交互设计约束。管理员每天高频操作借还需要快捷键和连续扫码读者可能一学期用两次需要更明确的引导和错误提示。课件里“用户错误操作系统的可能性”这一问在图书馆案例里至少有三个典型场景管理员误删图书、读者重复点击借书、条码扫错导致借还错位。每一条都应该在需求里对应一个防护措施比如删除前二次确认、借书操作幂等、借还以图书编号而非书名定位。用户类型可用功能交互侧重典型误操作与防护普通读者检索图书、查自己的借阅引导明确、提示充分重复提交借阅请求需幂等处理图书管理员借还、增删图书、查借阅人高频、可批量、快捷键误删图书、扫错条码需二次确认与编号定位把这张表放在需求文档的“用户与权限”一节评审时能省掉大量口头解释。很多人写需求只写“系统应支持权限管理”这句话既不能测试也不能设计等于没写。4. 面向数据流的建模数据流图、数据字典与加工说明三件套课件把需求分析建模方法按信息流向、结构、内容划分面向信息流向的是结构化分析方法面向信息内容的是面向对象分析方法描述系统需求时可以从功能、行为和信息三个方面入手侧重点可以不同。面向数据流的分析方法就落在“面向信息流向”这一支配套的开发方法是结构化开发方法SA/SD、SP对面是面向对象开发方法OOA/OOD/OOP。这一章把这条路线上的三个核心产物讲透数据流图负责“流”数据字典负责“定义”加工说明负责“规则”。4.1 为什么叫“面向数据流”与面向对象的分工“面向数据流”这个名字容易让人以为是“分析数据在网络里怎么传”。它分析的是业务数据在加工之间的流动路径数据从哪个外部实体进来经过哪些加工被变换落到哪个数据存储最后从哪个出口出去。结构化分析方法的核心就是把系统看成一组加工的集合加工之间靠数据流连接数据存储是加工的落脚点。面向对象分析方法则把系统看成一组对象的协作强调封装、继承、消息传递关注的是“信息内容”而不是“信息流向”。两者不是替代关系是切入角度不同数据结构稳定、流程清晰的业务系统面向数据流的分析更直接实体类型多、状态复杂的系统面向对象的分析更自然。考试里常考“结构化方法与面向对象方法的区别”答题要点可以按下面这张表组织。对比项结构化开发方法SA/SD、SP面向对象开发方法OOA/OOD/OOP建模主线数据流、加工、数据存储对象、类、属性、操作划分依据按信息流向按信息内容核心产物数据流图、数据字典、加工说明用例图、类图、交互图变更影响流程变动影响面较大局部封装影响面较小图书馆案例用结构化方法分析很顺借书是一条从读者到借阅记录的数据流还书是反向更新检索是从图书目录读数据查借阅人是按读者标识过滤借阅记录。换成面向对象会先识别读者、图书、借阅记录、管理员几类对象再定义它们之间的关联。两种建模方式都能描述同一个系统差别在于你先看到“流”还是先看到“物”。4.2 数据流图的四要素与分层画法数据流图有四种基本元素外部实体、加工、数据流、数据存储。外部实体是系统边界之外的输入来源或输出去向图书馆案例里是读者和图书管理员加工是对数据做变换的处理单元比如“办理借书”数据流是带着数据内容的箭头必须有名字数据存储是数据的静态落脚点比如图书目录和借阅记录。分层画法是结构化分析的关键动作。顶层图只画一个加工表示整个系统标出与外部实体的输入输出0 层图把系统拆成主要加工1 层图再把每个主要加工拆成子加工。分层必须满足父子平衡子图的输入输出数据流要和父图中对应加工的输入输出一致不能多也不能少。这一条是评审时的硬指标也是最容易失分的地方。图层次画什么图书馆案例对应顶层图一个加工代表整个系统标外部实体读者、管理员与图书馆系统之间的借阅、检索、维护数据流0 层图主要加工分解借还处理、图书维护、检索服务、借阅查询1 层图单个主要加工再分解借还处理拆为校验读者、校验图书状态、写借阅记录除了父子平衡还有几条画图规范值得背下来数据流不能是控制流不能画“先判断再走哪条路”的箭头判断逻辑要放进加工说明加工不能只有输入没有输出也不能只有输出没有输入数据存储必须既有写入流也有读取流只写不读或只读不写通常意味着模型有冗余外部实体之间不能直接有数据流必须经过加工。图书馆案例里有一条容易画错的地方借书和还书都是对借阅记录的写操作但方向相反。有些人会画一条“借阅记录”到“还书”的数据流再画回去造成同一存储双向流看着别扭评审也会问“到底谁写谁读”。更清晰的画法是借书加工写借阅记录、更新图书状态还书加工读借阅记录、更新图书状态两条流各自有明确的名字比如“借阅记录新增”“借阅记录归还”。4.3 数据字典与加工说明让图能被验证的另一半只有数据流图模型是不可验证的图上写着“借阅记录”谁也不知道它包含哪些数据项。数据字典就是给每条数据流、每个数据存储、每个数据项下定义的地方。常用记号有几种表示定义为表示顺序连接[ | ]表示从中选一{ }表示重复( )表示可选。这几组符号必须会写会读。以图书馆案例为例可以用字典记号把核心数据写出来记号含义图书馆案例示例定义为借阅记录 借书证号 图书编号 借出日期 归还日期顺序连接读者信息 借书证号 姓名 读者类型[ | ]从中选一读者类型 [ 教师 | 学生 | 管理员 ]{ }重复图书 图书编号 书名 作者 { 专业领域 } 状态( )可选借阅记录 借书证号 图书编号 借出日期 ( 归还日期 )加工说明小说明负责描述每个加工内部的处理规则常用三种表达结构化语言、判定表、判定树。当加工内部有多个条件组合时判定表最不容易漏分支。下面用判定表把“办理借书”这个加工写清楚三种条件、两种结果组合数量一目了然。-- 借阅记录表把“一书不可同时被两人持有”的约束落到数据层 CREATE TABLE loan ( loan_id INTEGER PRIMARY KEY, book_id INTEGER NOT NULL, reader_id INTEGER NOT NULL, borrowed_at TEXT NOT NULL, returned_at TEXT -- 为空表示尚未归还 ); -- 部分唯一索引只对未归还记录生效保证同一本书只有一条在借记录 CREATE UNIQUE INDEX ux_loan_active_book ON loan (book_id) WHERE returned_at IS NULL;这段 SQL 不是让需求阶段去建表而是用建表语句反过来检验需求是否自洽。参数说明book_id与reader_id是借阅关系的两个主体returned_at为空代表在借普通唯一索引会把历史归还记录也算进去导致同一本书只能被借一次所以必须用带WHERE returned_at IS NULL的部分唯一索引。写到这里“同一时刻一本书不能既被借出又被借阅”这条约束就从一个句子变成了一个可以被验证的结构。判定表的形式可以这样组织条件包括“图书状态是否可借”“读者是否已达借阅上限”“该书是否在借”动作包括“允许借出”“提示已达上限”“提示状态冲突”。三条件两两组合共八列逐列填动作填完会发现有些列根本不可能出现比如“该书在借”同时“状态可借”这些不可能列恰恰是需求里需要澄清的地方——图书状态字段的取值集合到底怎么定义必须在这一步定死。5. 易漏点排查结构化分析里最容易翻车的五处结构化分析的模型看着规整实际批改和评审里出错的地方高度集中。下面五条是按“出错频率 × 返工成本”排出来的每条按“易漏点—为什么漏—怎么补”写建议对着自己的图逐条核。5.1 易漏点一把物理模型当逻辑模型交上去为什么漏现场调查拿到的材料天然是物理形态单据、岗位、办公室、纸质流程直接誊到图上最省事看起来还很“详实”。很多人以为细节越多越专业结果逻辑模型里全是“某科室审核”这类实现细节。怎么补交图前做一次“去人名去地点”的替换实验把模型里所有具体岗位、地点、纸张单据替换成加工和数据存储如果替换后模型还能讲通业务说明抽象到位如果替换后讲不通说明你把本质环节和非本质因素一起删了需要回到现场补调查。5.2 易漏点二数据流图画成了流程图为什么漏日常表达的惯性是把事情讲成“先这样然后那样如果……就……”于是图上出现判断菱形、出现带条件的箭头、出现“若不满足则返回”的控制流。数据流图描述的是数据变换不是执行顺序。为什么这很致命一旦画成流程图加工说明就没地方放了因为判断逻辑被画进了图里父子平衡检查也做不了因为控制流没有对应的输入输出。怎么补把所有判断、循环、异常分支从图上摘出来写进加工说明的判定表或结构化语言图上只保留“什么数据进、经过什么加工、什么数据出”。5.3 易漏点三约束与并发条件写成形容词为什么漏需求讨论时大家说的是“借书要快”“不能重复借”“数量要控制”这些词在会议里能达成共识写进文档就完全不可判定。图书馆案例的三条约束里“一个读者一次借出的书籍数目不能超过预定值”如果不把预定值追成数字开发和测试都无从下手。怎么补建立一条硬规则凡是出现“快速、合理、尽量、适当、不能太多”这类词必须换成数量、时间、状态集合三选一的表述。数量类追成上限值时间类追成响应时间或超时时间状态类追成状态机与非法转移列表。然后把每条约束挂到具体的加工上看它在哪个加工里被检查、检查失败走哪条异常流。5.4 易漏点四数据字典和 DFD 对不上为什么漏图先画完字典后补补的时候凭印象写两边各写各的。典型症状是图上有一条叫“借阅信息”的数据流字典里定义的是“借阅记录”名字不一致或者字典里定义了“专业领域”这个数据项图上根本没有对应的数据流。怎么补用双向核对法。正向从图出发每条数据流、每个数据存储、每个外部实体在字典里都必须有条目反向从字典出发每个数据项至少要出现在一条数据流或一个数据存储里否则就是冗余定义。核对时顺手把命名统一同一概念全篇只用一个词别在图上叫“读者”、字典里叫“用户”、说明里叫“借阅人”。5.5 易漏点五非功能需求没有度量值为什么漏功能性需求有明确的功能点可以数非功能需求写起来像表态“系统应具备良好的性能与可靠性”这种句子写起来毫无压力评审时也不好意思挑刺。结果到了设计阶段架构选型没有任何约束依据。怎么补按课件给的四组问法逐条逼出度量值。性能问容量、速度、响应时间、吞吐量环境问硬件机型外设接口地点分布与温湿度磁场、软件操作系统网络数据库界面问外部输入输出、数据格式、存储介质人的因素问用户类型、熟练程度、训练成本、误操作可能性。四组问完还不能量化的就明确标注“待确认”并写清确认人和时间点别用形容词糊过去。6. 复习清单把需求分析压成一张可勾选的自查表复习到这一章最有效的方式不是再读一遍而是拿一张表逐项勾。下面这张清单按“模型链—需求内容—建模产物—易错项”四段组织每一项都能在课件里找到对应出处勾不上的就是漏洞。段落自查项勾选标准模型链能否说出需求分析五步的顺序与产物从物理模型到验证一步不落模型链能否区分当前系统与目标系统的物理/逻辑模型四个格子各举一例模型链能否解释抽象的结果是概念符号模型能说出“保留哪层、替换哪层”需求内容功能性与非功能性需求的判据各举三条图书馆案例内举例需求内容需求获取三问做什么、何时做、何时及如何改需求内容性能/环境/界面/人的因素四组问法每组至少三个具体指标建模产物数据流图四要素与分层规则能画出顶层图与 0 层图并说明平衡建模产物数据字典五种记号能默写 [ | ] { } ( ) 并各举一例建模产物加工说明三种表达结构化语言、判定表、判定树各写一小段易错项物理模型当逻辑模型做过“去人名去地点”替换实验易错项数据流图画成流程图图上无判断菱形、无控制流箭头易错项约束写成形容词每条约束有数字、时间或状态集合易错项字典与图对不上做过双向核对易错项非功能需求无度量四组问法逐条有度量值或待确认标注勾完表还有两个动作值得做。一是拿图书馆案例的六条功能每条各写一句“异常流”借书时读者已达上限怎么办、还书时记录不存在怎么办、删除图书时该书仍在借怎么办、检索无结果怎么提示、查借阅人时图书不存在怎么办。异常流写得出来说明加工说明真的写细了而不是只画了主干数据流。二是把三条约束各自翻译成一句可验证的话再翻译成一句可测试的话。比如“同一时刻一本书不能既被借出又被借阅”可验证的表述是“未归还借阅记录中同一图书编号至多出现一次”可测试的表述是“两个会话同时借同一本书只有一个成功另一个收到状态冲突提示”。能一路翻译到测试语句这条约束才算真正进了需求模型。我当时复习这块栽过一个跟头图背得滚瓜烂熟数据字典的重复记号{ }和可选记号( )一直混着用直到做案例才发现把一个“可空”的归还日期写成重复项模型含义完全变了。从那以后我每次画完图都强制走一遍“图—字典—加工说明”的三向核对图上每条流去字典里找定义字典里每个数据项回图里找出处加工说明里的每个判断回到图上找对应的输入输出。三遍走下来模型基本没有对不上的地方。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
