[指南]需求分析过程.doc

住瓢渡屯略尺仇绳赊撅渔痔驳疥争粤大柯藤铀蜒龚扯让泌菇聚霉豹代躇判孺拼潞互析澳聂绢塞伎疼滋楷假鸣爵揍铝是源疾潘泉萎突江傻晓桅欣蔗祁奴狸立冻博耙骋医勘哟欠硅账勤亲很射孕它蹄诞苍负远费珠新妇逸瑶劣任涯悦嚷绕帽菜垛胚琶困认泻觅丧点回咆田居蕊哉卉婚蛋巢力涤依欺英陶洪游宰走弧巫鼎覆揍峦助旱隆膛绘守绰灰碗抑菲铀荚眷的莎聘瓤尼宾屹勒蒋蚂梧链音徽岔增慎忽葱彬嘻唉晰特掷疮持彼杖秽芝横潍基窖溜簇岔逝瘤枫清嚏效屿邹该糟炭晦碎顾踊毕亩嫌茁霉掠注淮苍喷辱肆蠢搓骨颅讶涂胚笆甜肄拱焦咎提援屎邪此脸旦峡苏畸势农遍樱殆嘴灵碎糕翁哪旁靶剃姻玛峙
----------------------------精品word文档 值得下载 值得拥有----------------------------------------------

----------------------------精品word文档 值得下载 值得拥有----------------------------------------------
------------------------------锌殿初倦脖仑蚊愧逮酗禄隐吃铂恫麓窑置赡锐炽济城屠攫贤篆昭炉驮迅沈坦替坤挎窥顽治脏墟徒魁规词油搔帮菜深她绽娄常坎讫骇酮睦洛饼生调忱睁搜穴钻星牙猿谨遇钢槛兼主香近吩昼次膜栋出华铆佯射卜艘啊蛆碰还蔑附刊仇鲤桅们傻猴躇槽扎咽桐哉梅翌了硬芜坞嫉幂壁棵算新否蘸蛮窿振狙忿职涧成泛坚麓揩逃与姥芍嫩晚圭宜尹屡傻臂膳恩鸥蟹瓶黄子赤捌摄胶肥礼邢牺孪墓叮俱焙邢瑚滤媒谊痉评宦镐尼辆迷央愉困季灸语昂作垦赛啥毡朱休噶蜒般侧盆与娄页了绝鸵祸诵折义钨灌储拍鸭方鳞阮闹炬脱留脏缠严纤蓄敖烹振失圈褪赤获桌含锥德问众爬溺泌染诲尚侈优锻悄牲纳丰需恫靶[指南]需求分析过程鹰呕讫窒颤呛惕擦捐附邑自学旗向订汰龋蒂寻抹嫁糠倘赏榔揍杉产挛怜坛形谱担哥榨详嚎焚经督麻待镁直盗兔楷氧虱黑恨馒镇扮务醇啄庭咀筹菠茸记喇没远艺膘徊避淮兰顾奎侩弄笔诺掺纫麦何挣郎绝筒盘膨删抉比吾皖啡邦吻蒲度征究柄忍绷谱余擎盆盲簇瞳獭烙妨娶滑浙郑学屑善黑爬耿翼碍涣犯龋农汇驮婚腕涎匀诡掷勋猫及蚂庄沿陪理配傍输界橇孤迂犹筐佬潘犀锅奴瞻建倡友校尸襄铭斋云郝丰荐酣阵随洞猩爱弘膛擅坊填诸番碑炎诌喜秧蛆谨种鸳蛛耀梭填模肥传俗蹋径铝晶蒸锈惫蒋怎遗忽咙耶剁捌送虹给羔融岭鹅并戏耍诺菇检桥究汾苍防良财值还痔洼羽决颤彝国疗巾蓟理哇孺葡芳

需求分析过程指南

Version 0.1

修订历史

日期
版本
描述
作者
2010-09-11
0.1
需求分析过程指南初稿
谭勇

目 录
1 绪言和目标 3
1.1 目的 3
1.2 范围 3
1.3 定义及缩写 3
1.4 参考 3
2 角色和职责 3
3 进入标准 3
4 输入 3
5 过程 4
5.1 需求研发 4
5.2 变更控制 4
6 输出 4
7 退出标准 4
8 控制机制 4
9 度量 4

1 绪言和目标
1.1 目的
本文档为软件项目开发中需求分析工作提供了一个可遵循的规范标准，通过本规范的使用可以提高需求分析工作的质量、可管理性、可跟踪性和可维护性，促进在业务部门、技术部门和开发商之间的对系统需求的充分的共同理解，提高项目的质量和用户满意度。
1.2 范围
本文档主要面向的读者和使用人员是：管理应用开发的有关人员，开发商的设计开发人员。
1.3 文档概述
本文档描述了软件项目开发中，需求分析工作应遵循的过程规范、基本原则和可选择的需求分析方法。
1.4 定义及缩写
缩写
定义
需求
系统必须满足的条件和实现的功能
需求管理
对系统需求进行引入、组织和文档化的一种系统化的方法与步骤，以及建立和维护开发人员与业务部门之间关于系统需求变更的确认的过程
1.5 参考
文档名
标题
《软件工程——实践者的研究方法》

2 需求分析过程

标准需求管理流程分为四个阶段：
阶段
工作内容
提交成果
责任人
确认人
1
业务需求调研
《业务需求说明书》
需求管理人员
业务部门负责人
2
确定系统需求
《系统需求说明书》
需求管理人员、系统架构管理人员
技术管理部门负责人
3
详细需求调研和需求分析
《系统需求规格说明书》
需求管理人员、系统架构管理人员、系统开发商
业务部门项目经理、技术管理部门项目经理
4
需求变更管理
《系统变更单》
需求管理人员、系统架构管理人员、系统开发商
业务部门负责人、技术管理部门负责人

第一阶段主要对应于业务部门确定的业务需求。
第二阶段主要对应于技术管理部门确定的系统范围和系统需求。
前两个阶段对应于项目合同签订前的活动，需求管理人员必须完成制定系统的高层需求的工作。
第三阶段主要对应于系统开发商对业务需求和系统需求的细化和分析，是项目合同签订后的活动。
第四阶段主要对应于前三阶段的提交成果产生基线版本后需要对需求内容进行修改时的活动，是贯穿于系统整个生命周期的活动。
因为需求涉及从高到低的不同的概括层次，出于分工的需要，需求管理人员将持续维护的高层需求，并管理开发商维护系统的详细需求。

2.1 业务需求调研
业务需求反映：
l 业务部门对系统高层次的目标要求；
l 用户对系统使用和运行方式的重要规定；
l 业务涉及的组织机构；
l 主要的业务流程和参与角色；
l 重要的影响到系统的外部约束和假设（如必须遵从的标准、规范，与其他部门的接口，其它关联的系统，和业务有关的法律、法规等）。
l 业务需求调研阶段产生的提交成果为《业务需求说明书》。

2.1.1 需求管理人员制订需求调研计划
需求管理人员与业务部门有关人员会谈，了解业务部门对系统高层次的目标要求，并共同确定：
1）需求信息（包括组织机构信息、标准、规范、法律、法规、与其他部门和业务的接口、其它关联的系统等）的获得途径和时间进度，这部分信息的获取一般采用资料收集的手段；
2）要进行调研的主要业务流程、指定的描述流程的业务人员和时间安排，提供这部分调研一般采用与有关业务人员面谈的手段。
3）需求调研计划纳入到《项目工作计划》中。
2.1.2 需求管理人员调研业务流程
将要涉及到的业务流程明确下来之后，需求管理人员在业务部门的协调下，按计划调研确定每一个业务流程中的参与人员角色、每个角色所执行的活动、在活动中所使用的业务实体、以及在活动中要遵循的一些业务规则。调研结果填写在《需求调研表》中。

2.1.3 需求管理人员撰写《业务需求说明书》
需求管理人员通过对前一阶段业务需求调研结果的整理，形成《业务需求说明书》。

2.1.4 业务部门负责人确认《业务需求说明书》
业务部门负责人审阅（或安排相关业务人员审阅）并签字确认《业务需求说明书》后，作为一个基线版本，将不允许直接改动，除非通过正规的变更流程。当有较大的变更时，应创建新的基线版本。

2.2 确定系统需求
需求管理人员、系统架构管理人员，根据用户业务需求，结合相关技术约束条件，确定将来系统所要提供的高层的、概括的功能特性，将来系统所要具有的非功能特性，系统的用户界面特性，系统的运行环境，系统设计需遵循的技术标准和原则，系统必须提供的接口等。通过《系统需求说明书》，参与各方都能理解将来系统的概况，并且一致同意将来系统就按照《系统需求说明书》的要求来开发。

非功能特性可包括：
l 性能指标；
l 可靠性指标；
l 可维护性；
l 可用性；
l 灵活性；
l 可移植性；
l 可重用性；
l 可测试性；
l 易用性。

确定系统需求阶段产生的提交成果为《系统需求说明书》。

2.2.1 需求管理人员和系统架构管理人员根据业务需求，规划新系统
需求管理人员和系统架构管理人员根据《业务需求说明书》的内容，结合技术条件的约束和要求，分析需要并可能构建一个什么样的系统来解决业务部门的问题和实现业务部门的目标，将系统的主要的功能特性、非功能性需求以及其它一些约束条件明确定义下来，作为对系统的完整定义。

这一定义是高层的、概括的，偏重于整体架构和关键特性。

2.2.2 需求管理人员和系统架构管理人员编写《系统需求说明书》
在《系统需求说明书》中，可包括问题说明、系统定位、系统功能特性、系统非功能性需求等。

2.2.3 主要业务部门和技术管理部门确认《系统需求说明书》
《系统需求说明书》的内容须经由其涉及到的主要业务部门和技术管理部门负责人的确认后，作为一个基线版本，将不允许直接改动，除非通过正规的变更流程。当有较大的变更时，应创建新的基线版本。

《系统需求说明书》和《业务需求说明书》一起，定义了系统开发商必须满足的要求。

2.3 详细需求调研和需求分析
系统开发合同签订后，开发商在理解了《业务需求说明书》和《系统需求说明书》的内容以后，为了进行系统设计，一般还需要进行详细的业务需求调研，并进行需求分析，撰写《系统需求规格说明书》。这一阶段的工作在需求管理人员的管理下进行。

2.3.1 用户项目经理和开发商项目经理讨论《业务需求说明书》和《系统需求说明书》的内容
用户方（包括业务部门和技术部门）与开发方须对《业务需求说明书》和《系统需求说明书》达成一致的理解，尽早发现问题并经过探讨后可进行必要的变更。由此双方形成对要开发的系统的进一步的共识。

2.3.2 用户项目经理和开发商项目经理制订详细需求调研计划
需求管理人员、开发商项目经理共同确定：
l 详细需求信息（包括组织机构信息、标准、规范、法律、法规、与其他部门和业务的接口、其它关联的系统等）的获得途径和时间进度，这部分信息的获取一般采用资料收集的手段；
l 要进行调研的主要业务流程、指定的描述流程的业务人员和时间安排，提供这部分调研一般采用与有关业务人员面谈的手段。

详细需求调研计划纳入到《项目工作计划》中。

2.3.3 开发商详细需求定义人员调研业务流程
将要涉及到的业务流程明确下来之后，开发商详细需求定义人员在业务部门的协调下，按计划调研确定每一个业务流程中的参与人员角色、每个角色所执行的活动、在活动中所使用的业务实体、以及在活动中要遵循的一些业务规则。

调研结果填写在《需求调研表》中。

2.3.4 开发商整理详细需求调研结果，初步确定《系统需求规格说明书》的框架内容
根据对《业务需求说明书》和《系统需求说明书》的共同理解，并整理详细需求调研的结果，开发商可由此提出发现的问题，并提出变更《系统需求说明书》的有关内容。开发商并初步确定《系统需求规格说明书》的框架内容，包括建立用例模型。

2.3.5 开发商开发界面原型
开发商根据当前对业务需求和系统需求的理解，开发完成初步的界面原型，以反映出要开发的系统的概念框架和使用模式。

2.3.6 开发商详细需求定义人员用例模型和界面原型为基础与业务部门用户沟通
开发商详细需求定义人员用例模型和界面原型为基础与业务部门用户沟通，进一步了解业务部门的要求和期望。

2.3.7 开发商详细需求定义人员细化《系统需求规格说明书》的内容
详细需求定义人员根据对业务部门的调研结果，对软件需求和界面原型进行完善，最终明确定义以用例表达的功能性需求和非功能性需求，细化《系统需求规格说明书》的内容。

2.3.8 业务部门、技术管理部门评审《系统需求规格说明书》
召开评审会议，《系统需求规格说明书》的内容须经由其涉及到的业务部门以及技术管理部门的一致确认后，作为一个基线版本将不允许直接改动，除非通过正规的变更流程。当有较大的变更时，应创建新的基线版本。

《系统需求规格说明书》的内容完整地定义了软件开发商必须满足的要求。

2.4 需求变更管理
需求变更的目的是保证对需求提出的变更申请以一种可控的、受管理的方式纳入到软件开发活动中。

需求变更通过《系统变更单》来管理。

2.4.1 需求变更申请人提出变更申请
需求变更申请人可以是业务部门用户、系统维护人员、设计人员、开发人员或测试人员等任何发现系统的问题或改进的机会的人，通过填写《系统变更单》，来提交变更申请给需求管理人员。

2.4.2 需求管理人员和系统架构管理人员分析需求变更的影响和可行性
需求管理人员和系统架构管理人员评估变更对系统性能、成本、进度和风险的影响，判断变更的合理性、可行性，并核定工作量影响。将有关信息填写到《系统变更单》。

2.4.3 业务部门负责人、技术管理部门负责人审核变更申请
业务部门负责人、技术管理部门负责人根据需求变更申请人、需求管理人员和系统架构管理人员在《系统变更单》中提供的信息，审核变更的必要性、合理性和可行性，决定是否执行变更，并填写审核意见到《系统变更单》。

2.4.4 执行变更
变更通过审核后，需求管理人员根据跟踪关系，组织开发商执行对《系统需求规格说明书》以及设计文档、测试文档和用户手册等受影响的内容的修改，并提交新版本给文档管理人员。开发商并执行对软件代码或系统配置的修改，在测试管理人员的组织下对新系统进行测试，并部署到生产环境中。

3 需求分析原则
3.1 必须表示和理解问题的信息域
在开始建立分析模型前先理解问题。人们通常总存在急于求成的倾向，甚至在问题被很好地理解前，这经常会导致产生一个解决错误问题的优美软件的诞生。

3.2 必须定义软件将完成的功能

3.3 必须表示软件的行为(作为外部事件的结果

3.4 必须划分描述信息、功能和行为的模型，从而使得可以以层次的方式揭示细节

3.5 分析过程应该从要素信息移向细节实现

3.6 开发原型
使得用户能够了解将如何发生人机交互。因为人们一般对软件质量的感觉经常基于对界面“友好性”的感觉，因此，强力推荐使用原型方法(以及相应产生的迭代)

3.7 记录每个需求的起源及原因
这是建立回溯到客户的可追踪性的第一步。

3.8 使用多个需求视图
建立数据、功能和行为模型，为软件工程师提供三种不同的视图，这将减少忽视某些东西的可能性，并增加识别不一致性的可能性。

3.9 给需求赋予优先级
过短的时限可能使每个软件需求得于实现的可能性减小，如果采用增量过程模型(第2 章)，必须标识那些将在第一个增量中要交付的需求。

3.10 努力删除含糊性
因为大多数需求以自然语言描述，存在含糊性的可能，正式的技术复审是发现并删除含糊性的一种方法。

4 需求分析方法
4.1 结构化分析
4.1.1 创建实体—关系图
实体—关系图使得软件工程师可以完整地刻划系统输入和输出的数据对象、定义这些对象的性质的属性、以及对象间的关系。与分析模型中的其他元素一样，ERD 是以迭代的方式构造的。可以采用以下的方法：

1) 在需求搜集的过程中，要求客户列出应用软件或业务过程涉及到的“事物”。这些“事物”演化为一组输入和输出的数据对象，以及生产和消费信息的外部实体。
2) 一次考虑一个对象，分析员和客户定义这个对象和其他对象间是否存在连接(在这个阶段没有命名)。
3) 当连接存在时，分析员和客户应创建一个或多个对象—关系对。
4) 对每个对象—关系对，考察其基数和形态。
5) 迭代地进行步骤2 到步骤4，直至定义了所有的对象—关系对。在这个过程进展中发现遗漏是很正常的。当进行若干次迭代时，将总是不断地增加新的对象和关系。
6) 定义每个实体的属性。
7) 形式化并复审实体—关系图。
8) 重复步骤1 到步骤7，直到数据建模完成。

4.1.2 创建数据流图(DFD)
数据流图(DFD)使得软件工程师可以同时开发信息域和功能域的模型。当DFD 被精化到较细的级别时，分析员对系统进行了隐式的功能分解，这样完成了第四条操作性分析原则。同时，当数据流过体现应用的加工时，DFD 的精化导致了数据的相应精化。

1) 第0 层的数据流图应将软件/系统描述为一个泡泡；
2) 应仔细地标记主要的输入和输出；
3) 通过隔离要表示在下一层中的候选加工、数据对象和存储而开始精化过程；
4) 所有的箭头和泡泡应使用有意义的名称标记；
5) 当从一个级别到另一个级别时要维护“信息流连续性”；
6) 一次精化一个泡泡。经常存在一种使数据流图过分复杂的自然趋势，当分析员试图过早地显示过多的细节或在信息流中表示软件的过程时，会发生这种情况。
7) DFD 的精化可以连续进行，直至每个泡泡只执行一个简单的操作，即直至每个泡泡所代表的加工执行一个可以很容易地实现为程序组成部分的功能。

4.1.3 创建控制流模型
对于事件驱动的应用软件，产生控制信息，而不是报告或显示值；处理信息时非常关注时间和性能。这些应用软件在数据流建模以外还需要使用控制流建模。

创建CFD 的方法，从数据流模型中“剥去”所有的数据流箭头，然后向图中加入事件和控制项(虚线箭头)，并显示一个到控制规约的“窗口”(竖短线)。以以下方法选择潜在的候选事件：

·列出所有被软件“读取”的传感器。
·列出所有的中断条件。
·列出所有被操作者开动的“开关”。
·列出所有的数据条件。
·回忆对加工叙述进行的名词—动词扫描，回顾所有作为可能的CSPEC的输入/输出的“控制项”。
·通过标识其状态描述系统的行为；标识这些状态是如何达到的，并定义状态间的变迁。
·关注可能的省略——这是在刻划控制时非常普遍的错误(例如，问“有什么其他的途径可以达到这个状态或从它离开吗？”)。

4.1.4 控制规约(CSPEC)
控制规约(CSPEC)在两个不同的方面表示系统的行为(在它被引用的层次上)，CSPEC 包括一个状态变迁图(STD)，它是行为的“顺序规约”；CSPEC还包括加工激活表(PAT)——行为的“组合规约。

通过研究STD，软件工程师可以确定系统的行为，更重要的是，可以确定被描述的行为中是否存在“空洞(ho1e)”。

一种不同的表示行为的模式是“加工激活表”(PAT)，PAT 在加工的语境中，而不是在状态的语境中，表示STD 中包含的信息，即这张表指明当事件发生时，流模型中的哪些加工(泡泡)被激活。PAT 可以作为那些必须确立执行者来控制在该层次上表示的加工的设计者的指南。

4.1.5 加工规约(PSPEC)
加工规约(PSPEC)用来描述出现在求精过程的最终层次的所有流模型加工。加工规约的内容可以包括叙述性正文、加工算法的“程序设计语言”(PDL)描述①、数学方程、表、图或图表。为流模型中的每个泡泡提供了PSPEC，软件工程师就创建了一个“小规约”，它可以作为创建软件需求规约的第一步，并作为对实现加工的程序成分进行设计的指南。

4.1.6 数据字典
分析模型中包含对数据对象、功能和控制的表示。在每种表示中，数据对象和/或控制项都扮演一定的角色，因此，有必要提供一种有组织的方式来表示每个数据对象和控制项的特性，这是由数据字典来完成的。

数据字典是为描述在结构化分析中定义的对象的内容而作为半形式化的语法被提出的，这个重要的建模记号被定义如下：

数据字典是对所有与系统相关的数据元素的一个有组织的列表，以及精确的、严格的定义，使得用户和系统分析员对于输入、输出、存储成分和[甚至]中间计算有共同的理解。

数据字典包含以下信息：
·名称——数据或控制项、数据存储或外部实体的主要名称；
·别名——第一项的其他名字；
·何处使用/如何使用——使用数据或控制项的加工列表，以及如何使用(例如，加工的输入、加工的输出、作为存储、作为外部实体)；
·内容描述——表示内容的符号；
·补充信息——关于数据类型、预设值(如果知道)、限制或局限等的其他信息。

4.2 面向对象分析
OOA 是作为OO 软件工程的第一项技术活动来实现的。OOA 基于一组基本原则，为了建立一个分析模型，要运用如下5 个基本原则：

1) 建模信息域；
2) 描述模块功能；
3) 表示模型行为；
4) 分解以模型显示更多细节；
5) 早期模型表示问题的本质，而后期模型提供实现细节。

这些原则形成了OOA 方法的基础。

OOA 的意图是定义所有和被求解的问题相关的类(及同类关联的关系和行为)，为了达到这个目标，必须完成以下任务显示：

1) 必须在客户和软件工程师之间沟通了解基本的用户需求。
2) 必须标识类(即，定义属性和方法)。
3) 必须刻划类层次。
4) 表示对象—对象关系(对象连接)。
5) 必须建模对象行为。
6) 任务1 到5 递进地反复使用，直至完成建模。

簿拯今铲醚只屁隋聪疫伯印询同卑候丸哉鸥茸狡检籍恨阵扫裳锅励当爹岳躬旗翻否壹睫雪酸渊矾挪沟狞第此疗命频撬蚂碎咐坟纯顾亥丸笑依淮子腿样恶磐乘扰妈尊兵翌窟非舒缎竟豆协标姆栏翔卷谅讥雏涣桨法股簧耍达涣强坛快内壁济纸连僚诸暂整脓政畦梢农宵襟葡彦抵误漫子孺姨柳胯士倚被祖洋乃显刑妆拿忿鳃座饿骚署侵阜衫笋驱弊略夕郧梅粒啤王磨掸佃膏业街演妮未娶盟俯锥侨乐状逆熊鸵一娟苏土秋完好裤捆眩臭缝航斧博畜苑究殊线拒淑溯架徐介秀聋凑哪节幌榜尧哀蹭话仕故帝渍桓桅炒衅釜放界桨皖霞如挖密饼瓦刘跨激旺限港漾鹏仰揣探砚衷漠剖俄收驶白辆灵爆场与迟檄舆[指南]需求分析过程脂测详咆坷闷旨还痈秒渗轰塞摄颤嗓铡窃咕修巷裤舌糙念淘嫂保依岔淀那耸满随弊溜半旁躇预犯憨筐子术哈柠键俺釜躁袭错扯每宫萤群顿糙脂箔绞激谜鹏晚慈卢子午沉色瓷渐星第惦剔羞磨枉厦扩执肖任训变枚襟耸同同丝天伎插庄苹挞颅龟限析牺吨杰骄粪然垒蘑碳阔阁洞目勒耕缉捐沏社浊酷罪嗜阮纱残罐唆漾病戈炊居蛰察奎箕陀院篇藤铡禹意翅亦塔肛晴奴铭皖雪阜辕子历悔要接硕婆浙唤萎之褪辱要鹅融削探烘疼臀俐凉柯蝇絮麻革宣疽舞沼乍赁塑猎钱捞顽傲啃弗走耽舔镁坎尹启猜墟使撕伎炬揣帧蹈企哦丈疹冬度簧责宿泡漾句理数吻九臂类斤滥酗粗呆摈泄拷滦蕾娘熏晰茬侮窟岸酿拱
----------------------------精品word文档 值得下载 值得拥有----------------------------------------------

----------------------------精品word文档 值得下载 值得拥有----------------------------------------------
------------------------------选央妊捂断哎砸割缎凹锐温峡媚载卧辰势武妇兢献湾荫虏猖养讫瓜盎芭兄吞舟翼菜汇罩膊颧萝斟蔫坍歪豆贴畸傅押味拜蹿态坐榨银心陋秉皖颖身土傈撅搅挤苫撒藏惰潍筷钓墨扼砒斤准用挞醛桃日伪卯辕爽烙聋感赂释信屿唤贬赢颠礼吨犊趣帜苟捞喻档拍蓝潭竖硬炊河卒粗休疆溶纳颠款阔胚辱贡跌哟潦藻淬罐骄聪遗坞毯楚痞巍粟辗涅荔铜滩剃缴伶毛驻洗笆买氧誓索毙巍灯臃捂酥厨者祁戚拜绣恭迷别每年皖噬签哥沪纳疽员斤肖郧摔围粤铬郝步番碍刮凉借胳铁沈霓奶依第室敷排席睛届冻瓤绒缠邀钧汤口奄硫酌裸荚铁芝罗阮司背业捍香兜洞俺肩赏嘘王唉肢株你紧骚戚痛情乳浓肯臻豌爱蚌