需求分析中需求规格SRS的非功能性需求的考虑因素
2025年软件资格考试软件过程能力评估师(中级)(基础知识、应用技术)合卷试题及答案指导
2025年软件资格考试软件过程能力评估师(基础知识、应用技术)合卷(中级)自测试题(答案在后面)一、基础知识（客观选择题，75题，每题1分，共75分）1、软件过程能力评估师在进行软件过程评估时，通常会使用哪种方法来识别和量化软件过程中的关键过程域（KPA）？A、专家评审法B、统计分析法C、模型分析法D、过程审计法2、在软件能力成熟度模型集成（CMMI）中，哪个级别是组织软件过程能力成熟度的基础？A、初始级B、已管理级C、已定义级D、已量化级3、题干：在软件开发生命周期中，以下哪个阶段主要负责软件需求的收集和分析？A. 需求分析阶段B. 设计阶段C. 编码阶段D. 测试阶段4、题干：以下哪个不是软件质量保证（SQA）的常用方法？A. 流程分析B. 审计C. 验收测试D. 软件审计5、题目：在软件过程能力成熟度模型（CMM）中，哪一级别代表了组织已经建立了一套持续改进的机制，并且能够对过程进行监控和评估？A、初始级B、可重复级C、已定义级D、管理级6、题目：在软件开发生命周期中，以下哪个阶段通常负责确定项目是否应该继续进行？A、需求分析B、设计C、编码D、验收测试7、软件过程能力成熟度模型（CMM）的五个级别中，哪个级别强调对软件过程进行定量分析和度量？8、在软件项目管理中，以下哪个不是敏捷开发方法的特点？9、题干：在软件工程中，以下哪个活动通常被称为“软件需求工程”？A. 软件设计B. 软件测试C. 软件需求工程D. 软件维护 10、题干：在软件过程能力成熟度模型（CMM）中，以下哪个级别表示组织已经建立了有效的软件过程管理和改进机制？A. 初级（Initial）B. 管理级（Managed）C. 定义级（Defined）D. 精益级（Optimizing）11、题干：在软件过程中，以下哪个阶段不是软件生命周期的标准阶段？A. 需求分析B. 设计C. 编码D. 测试E. 维护12、题干：以下哪种软件工程原则旨在减少系统复杂性，提高软件的可维护性？A. 单一职责原则B. 开放封闭原则C. Liskov替换原则D. 迪米特法则13、在软件过程能力成熟度模型CMM（Capability Maturity Model）中，成熟度级别1的特点是什么？14、敏捷开发方法中，哪个原则强调“尽早地、持续地对软件进行测试，以便及时发现问题并修复？”15、软件过程能力评估模型（CMMI）的成熟度等级分为几个级别？16、在软件项目管理中，下列哪个工具用于跟踪项目进度和资源消耗？17、在软件生命周期模型中，哪一个模型强调了需求获取与定义的重要性，并且在这个阶段收集所有必要的信息来确保后续设计和开发工作的正确性？A. 瀑布模型B. 增量模型C. 螺旋模型D. 敏捷模型18、下列哪一项质量管理原则强调在整个组织内各级人员的积极参与是组织之本？A. 过程方法B. 领导作用C. 全员参与D. 持续改进19、在软件过程能力成熟度模型（CMM）中，以下哪个级别标志着组织已经建立了一套稳定的软件开发过程？A. CMM Level 1：初始级B. CMM Level 2：可重复级C. CMM Level 3：已定义级D. CMM Level 4：管理级 20、在软件项目管理中，以下哪个工具或技术用于评估项目风险的概率和影响？A. 风险矩阵B. Gantt图C.PERT图D.PERT分析21、在软件生命周期模型中，螺旋模型是一种结合了瀑布模型与哪种其他模型的特点，并且包含风险分析的模型？A、增量模型B、快速原型模型C、喷泉模型D、敏捷模型22、在软件工程中，需求分析阶段的主要任务是什么？A、确定软件的功能需求和非功能需求B、设计软件的具体实现细节C、编写程序代码D、测试软件是否满足需求规格说明书的要求23、在软件过程能力成熟度模型（CMM）中，CMM模型将软件过程成熟度分为几个等级？24、敏捷开发方法中，哪一种实践不强调团队间的协作和沟通？25、在软件生命周期中的哪一个阶段，需求分析被归类为一项关键活动？A. 概念定义阶段B. 软件开发阶段C. 需求获取阶段D. 系统维护阶段26、下列哪一项质量管理原则强调了持续改进的重要性？A. 以客户为中心B. 过程方法C. 基于事实的决策方法D. 持续改进的方法27、在软件过程能力成熟度模型（CMM）中，哪个级别代表组织具有持续改进的过程？28、软件需求工程中，以下哪项不是软件需求规格说明书（SRS）的主要目的？29、关于软件生命周期模型的说法，下列哪一项是正确的？A. 增量模型允许在早期阶段实现核心产品。
软件需求工程实验六
实验六需求风险评估与跟踪矩阵
目的：
1、了解软件需求风险评估和跟踪的重要意义和作用；
2、理解软件需求风险评估和需求跟踪的常见模式和流程；
2、掌握软件需求风险和跟踪文档的编写和步骤；
要求：
1、掌握需求风险评估和跟踪意义和作用；
2、对需求规格文档SRS进行风险评估和高风险需求进行实时跟踪处理进展，编写跟踪矩阵文档，以及跟踪文档设定操作；
实验内容：
利用理论知识内容完成SRS的风险评估和跟踪矩阵的输出。
一、评估需求风险需要注意以下几点：
1、需求获取阶段
1)如涉及到非功能需求，需要明确
2)对需求基线的合理建立进行评估
3)是否给出期望的解决办法，如没有需要重点跟进
4)
2、需求分析阶段
1)划分需求优先级，优先级高的重点考虑
2)关注可能带来技术困难的特性
3)对不熟悉的技术、方法、语言、工具或硬件平台进行风险评估
4)
3、需求规格说明
1)对需求的描述和定义不能太过抽象，简单直接明了为上。
2)对具有二义性的术语和用户特有的专业术语解释说明是否到位。
3)
4、需求管理
1)需求变更的处理流程和机制是否双方达成一致
二、需求跟踪矩阵
1、需求跟踪提供了一个与合同或说明文档相一致的方法。
2、需求跟踪通过持续跟进需求任务的进展，不限于需求分析阶段，还包括包括设计、开发、测试等阶段，及时发现问题，达到可以改善软件开发质量，降低维护成本
作业布置：参
考教材和实验指导内容，完成任务
1、需求风险评估时你认为还需要考虑哪些方面？请简述。
2、如果让你对已经完成的需求跟踪矩阵进行管理和跟踪，你将准备如何去跟踪？。
需求分析文档
需求规格说明书软件需求规格说明书（System Requirement Specification，SRS）也叫软件需求分析说明书，它是软件的重要文档之一，软件需求分析说明书对所开发的软件功能、性能、运行环境等做出详细的说明。
它是软件分析设计的最主要依据，验证核实产品能否满足用户要求的唯一标准，它是用户与开发人员双方对软件需求取得共同理解的基础。
下面给出一个简略版的需求规划说明书，以供分析理解。
由于篇幅有限，本说明书部分内容予以省略。
1引言本规格说明详细阐述了宿舍电费管理系统的软件功能、系统特性、非功能性需求以及其它需求。
编写目的详细、准确、全面的定义宿舍电费管理系统的软件需求，指导软件系统的后期开发工作；本文档所描述的软件需求将作为该项目的最终验收的标准与依据。
读者对象本软件需求规格说明书的读者包括：学生用户、系统管理员、收费员、抄表员产品的范围制作本软件的目的是，借助网络向学生提供服务，实现服务向消费者方向的转移，把软件与业务策略相联系。
2.综合描述这部分概述了项目的背景情况、主要功能、运行产品的环境，以及使用该产品的用户等。
2.1产品背景以及目前存在的问题传统的电费管理都是由工作人员查表、抄表完成的，其中要，完成用户电费的收取，每月的抄度，用户购电情况查询，以及列出欠费用户的信息名单之类的信息，其工作强度大，工作流程繁琐，倘若工作人员不细心，将会造成电费收支的错误也是会常有发生的，鉴于以上原因我们有必要开发一种帮助电费管理人员的软件系统，可以完成检查用户用电情况，每月抄度，信息录入以及基本数据维护的各项功能。
随着计算机技术日渐成熟，其强大的功能已为人们所接受，并已进入人类社会的各个领域发挥着越来越重要的作用。
因此，我们设计一种将电费管理与计算机操作相结合的系统。
学生在学校的用电需求日益壮大，往往会超出学校规定的用电范围，超出学校规定的用电，学生需要另外支付费用。
在学校中，宿舍用电的管理工作不仅工作量大，而且时效性强。
srs技术文档说明
本文的目的是描述SRS技术文档，包括对SRS的解释说明、SRS描述规范以及规范的一个范例。
软件需求规格说明书（SRS，Software Requirement Specification）是为了软件开发系统而编写的，主要用来描述待开发系统的功能性需求和非功能性需求，以及系统所要实现的功能和目标，为项目开发人员提供基本思路，明确开发方向，节约时间提高开发效率，降低软件开发风险，节约成本。
SRS主要面向系统分析员，程序员，测试员，实施员和最终用户。
SRS是整个软件开发的依据，它对以后阶段的工作起指导作用，同时也是项目完成后系统验收的依据，还是《用户手册》和《测试计划》的编写依据。
以下是SRS的描述规范：1.功能需求按模块为单位描述功能需求，重复以下几点描述每一模块的功能需求。
1.1 模块1第一个模块。
每个模块用一个用例图表示，在写SRS时，名字使用能够表达模块功能的短语表示，而不用模块1表示。
1.1.1 用例图描述此模块的用例图。
一个用例图中有若干个Actor、用例及其关系，描述包括涉及到的所有Actor、用例及其关系。
其中，Actor是参与者；一个用例描述的是一个功能需求；关系是用例和用例之间的关系。
用例的名字使用能够表达用例目标的动词短语。
1.1.2 业务流程图用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。
一个业务流程图是用来描述1.1.1用例图中的一个用例事件的业务流程操作。
下面是对业务流程图对应的这个用例的描述说明：以下是SRS描述规范的一个范例：1.功能需求1.1业务区管理1.1.1 用例图1.1.2 业务流程图业务区创建范例说明：以上范例是直放站统一通讯管理系统的SRS中的第三章节，是用来描述系统的功能需求的，其中，1.1小节描述了其中一个模块——业务区管理的功能需求。
其中包括了业务区管理这一模块的用例图，以及对这一用例图中由Actor带动的三个用例：业务区创建、业务区管理、业务区删除的业务流程图描述，列出了其中一个用例——业务区创建的业务流程图，以及对这个用例的简要说明、前置条件、后置条件、角色、触发条件、基本事件流、备选事件流、特殊需求等的描述。
需求规格说明书
需求规格说明书随着科技和信息时代的发展，软件行业也越来越重要，其影响范围越来越广泛。
在软件开发过程中，需求规格说明书是一个非常重要的文档。
它定义了软件开发项目中的需求，包括功能、性能、安全、可用性等。
本文将详细介绍需求规格说明书的定义和重要性以及编写需求规格说明书的一些问题。
一、什么是需求规格说明书？需求规格说明书（Software Requirements Specification，简称SRS）是一份详细的软件开发文档，记录了一个软件系统需要满足的功能和性能要求。
它是一个软件开发项目的重要组成部分，决定了开发团队将开发的软件系统的范围和特征。
同时，它也是开发人员、测试人员、业务人员、客户和管理者之间交流的重要媒介。
二、需求规格说明书的重要性1. 确定方向，避免偏差需求规格说明书定义了软件开发项目的范围和要求。
在软件开发的过程中，可能会面临许多决策，如果没有清晰的目标依据，可能会迷失方向，甚至出现开发偏差。
通过编写需求规格说明书，团队成员可以确保对整个软件项目有一个共同的理解，并避免对产品范围的混淆。
同时，它也为项目负责人提供了一个确定开发进程的准确方法。
2. 保持一致性需求规格说明书为所有软件开发项目参与者提供了一致性的参考点。
这将确保所有的团队成员，包括开发人员、测试人员和业务人员，都了解软件项目的目标。
这将确保开发团队按照相同的标准进行开发和测试，而不会出现任何混乱，导致项目时间表的延迟和麻烦。
3. 提高效率，控制开发成本在编写需求规格说明书的过程中，团队成员能够更仔细地审核项目需求。
这样可以避免在开发过程中对问题进行不必要的更改，从而提高团队的工作效率，缩短项目发布时间，同时减少软件开发过程中的成本。
三、如何发挥需求规格说明书的作用为了使需求规格说明书发挥它的作用并达到预期的效果，编写它时需要遵循以下原则：1. 明确而详细地概述需求规格说明书需要提供足够的细节和定义，以便团队成员在理解细节时可以有一个相同的基线。
软件需求规格说明书编写指南
软件需求规格说明书编写指南引言软件需求规格说明书（SRS）是软件开发过程中至关重要的一份文档，是开发团队和客户之间的桥梁，用于明确软件系统的功能和性能需求。
本文旨在为编写RAS提供一个指南，以确保SRS文档的完整性和准确性。
一、背景介绍在这个部分，我们可以简要介绍软件开发的背景和目标。
例如，我们可以提到该软件项目是为了满足特定行业的需求，或者解决某个问题而开发的。
同时，还可以介绍项目的范围和预期用户群体。
二、需求概述在此部分，我们需要对整个软件的基本要求进行总结和概述。
这意味着我们需要列出所有的功能需求、性能需求和其他适用的需求，以便开发团队和客户能够对整个项目的规模和目标有一个清晰的认识。
三、详细需求说明在这个部分，我们需要详细地描述每个功能和性能需求。
可以将这些需求分组，以便于阅读和理解。
我们可以采用以下格式进行描述：功能需求在此部分，我们可以列举每个功能需求，并说明其详细描述、优先级和相关限制。
例如，对于一个在线购物网站的需求，我们可以列举用户注册、商品浏览、购物车管理等功能需求，并详述每个功能的具体要求。
性能需求在这个部分，我们可以列举每个性能需求，并说明其详细描述、优先级和相关限制。
例如，对于一个社交媒体平台的需求，我们可以列举用户同时在线人数、响应时间等性能需求，并说明针对这些需求的具体要求。
四、界面设计在这个部分，我们可以以图表或示意图等形式，展示软件系统的界面设计。
可以包括主页、菜单、按钮和输入框等元素的布局和交互逻辑。
同时，还可以说明每个界面元素的功能和约束。
五、数据模型在此部分，我们可以介绍软件系统的数据模型。
可以使用图表或表格等形式，展示各个实体（如用户、订单）之间的关系和属性。
可以详细说明每个实体的属性和类型，并说明其约束和关联关系。
六、系统规则在这个部分，我们可以概述软件系统中的各种规则和限制。
这些规则可以包括逻辑判断、数据验证和用户权限等方面。
通过详细描述系统规则，可以帮助开发团队更好地理解系统的运作机制。
SRS规范简介
本文的目的是描述SRS技术文档，包括对SRS的解释说明、SRS描述规范以及规范的一个范例。
软件需求规格说明书（SRS，Software Requirement Specification）是为了软件开发系统而编写的，主要用来描述待开发系统的功能性需求和非功能性需求，以及系统所要实现的功能和目标，为项目开发人员提供基本思路，明确开发方向，节约时间提高开发效率，降低软件开发风险，节约成本。
SRS主要面向系统分析员，程序员，测试员，实施员和最终用户。
SRS是整个软件开发的依据，它对以后阶段的工作起指导作用，同时也是项目完成后系统验收的依据，还是《用户手册》和《测试计划》的编写依据。
以下是SRS的描述规范：1.功能需求按模块为单位描述功能需求，重复以下几点描述每一模块的功能需求。
模块1第一个模块。
每个模块用一个用例图表示，在写SRS时，名字使用能够表达模块功能的短语表示，而不用模块1表示。
1.1.1 用例图描述此模块的用例图。
一个用例图中有若干个Actor、用例及其关系，描述包括涉及到的所有Actor、用例及其关系。
其中，Actor是参与者；一个用例描述的是一个功能需求；关系是用例和用例之间的关系。
用例的名字使用能够表达用例目标的动词短语。
业务流程图用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。
一个业务流程图是用来描述用例图中的一个用例事件的业务流程操作。
下面是对业务流程图对应的这个用例的描述说明：以下是SRS描述规范的一个范例：1.功能需求业务区管理1.1.1 用例图1.1.2 业务流程图业务区创建业务区创建简要说明创建给定信息的业务区前置条件输入业务区名称，代码，及其他信息后置条件成功后置条件输出显示到页面上失败后置条件输出不显示到页面上角色系统管理员触发条件将这些信息加入到数据库中的业务区表基本事件流描述、步骤1. 输入业务区名称，代码，及其他信息;2.将这些信息加入到数据库中的业务区表;3.输出显示到页面上备选事件流、步骤无特殊需求无范例说明：以上范例是直放站统一通讯管理系统的SRS中的第三章节，是用来描述系统的功能需求的，其中，小节描述了其中一个模块——业务区管理的功能需求。
需求分析大作业(SRS)文档编制说明[1] (1)
![需求分析大作业(SRS)文档编制说明[1] (1)](https://img.taocdn.com/s3/m/35789a06bb68a98271fefa94.png)
背景
（三）用户对系统提出的功能性需求 本项目拟在本部和B厂（机加工工序）先实施， 二期再推广到异地的三个分厂。 系统功能包括B厂生产过程管理、产品销售管理、 售后服务管理（包含服务的记录和查询）、半成品和 成品仓库管理等等。同时利用这些信息，加强公司对 产品在线的过程监控、质量的监控、生产线（含质量 检验）员工的责任认定和绩效的考核。
主要用户 生产操作者 其他涉众 企业管理者
售后服务人员
分销商
质量检验人员
仓库管理人员
作业要求
参考上述背景，编制 “某机械物联网应用系统” 的SRS。 编写的文件参照模板“需求文档模板一.doc” ， 特别要进行“用例模型”分析。 网上寻找和阅读有关RFID及其应用的文档，文档 中要包含系统的物理架构、软件架构和开发环境 （.NET或J2EE等等）。 文档中包含系统物理设备和配件（主要是RFID电 子标签、RFID读写器、通讯设备、后台服务器） 的选型，选型应尽量降低成本（通过上网找资 料）。
2.产品销售管理方面的需求描述 产品分按订单销售和按库存销售两种方式，需 要系统对各产品的销售情况、销售去向进行准确 地统计，对每个产品的产品情况进行快速地查询 和获取，对经销商的产品销售情况进行记录。 目前依赖人工进行产品销售情况的统计，无 法快速查询单个产品的情况。
3.售后服务管理方面的需求描述
需求获取的部分照片该集团生产的半成品需求获取的部分照片车桥产成品某道工序的加工现场需求获取的部分照片生产过程中的质量跟踪卡需求获取的部分照片生产过程中需返工的产品需求获取的部分照片质量跟踪卡需求获取的部分照片产品保修卡涉众分析涉众stakeholder在软件开发项目中主要是指和这个项目有密切相关利益的人
背景
集团主要产品有5~6大类，规格有180多种。包括 汽车、工程机（装载机、压路机、叉车等）车桥、箱 件等等。 生产过程分铸造和机加工两类大工序。其中产品 铸造先由异地A工厂铸造，再由与总部相邻的B厂进行 机加工。 机加工约十几道工序、不同产品，其加工工 艺都有区别。 目前B厂有两车间，8条生产线，年产 20~30万件。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求分析中需求规格SRS的非功能性需求的考虑因素
* 功能性质量因素：正确性，健壮性，可靠性
* 非功能性质量因素：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性正确性
* 正确性是指软件按照需求正确执行任务的能力。
“正确性”的语义涵盖了“精确性”。
* 正确性无疑是第一重要的软件质量属性。
* 技术评审和测试的第一关都是检查工作成果的正确性。
* 机器不会主动欺骗人，软件运行出错通常都是人造成的，所以不要找借口埋怨机器有毛病。
健壮性
* 健壮性是指在异常情况下，软件能够正常运行的能力。
* 正确性描述软件在需求范围之内的行为，而健壮性描述软件在需求范围之外的行为。
* 开发者往往把异常情况错当成正常情况而不作处理，结果降低了健壮性。
* 用户才不管正确性与健壮性的区别，反正软件出了差错都是开发方的错。
所以提高软件的健壮性也是开发者的义务。
* 健壮性有两层含义：一是容错能力，二是恢复能力。
可靠性
* 可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。
* 可靠性本来是硬件领域的术语。
比如某个电子设备在刚开始工作时挺好的，但由于器件在工作中其物理性质会发生变化（如发热），慢慢地系统的功能或性能就会失常。
所以一个从设计到生产完全正确的硬件系统，在工作中未必就是可靠的。
* 软件在运行时不会发生物理性质的变化，人们常以为如果软件的某个功能是正确的，那么它一辈子都是正确的。
可是我们无法对软件进行彻底地测试，无法根除软件中潜在的错误。
平时软件运行得好好的，说不准哪一天就不正常了，如有千年等一回的“千年虫”问题，司空见惯的“内存泄露”问题、“误差累积”问题等等。
* 时隐时现的错误一般都属于可靠性问题，纠错的代价很高。
性能
* 性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。
人们总希望软件的运行速度高些，并且占用资源少些。
* 性能优化的关键工作是找出限制性能的“瓶颈”
* 可以通过优化数据结构、算法和代码来提高软件的性能。
易用性
* 易用性是指用户使用软件的容易程度。
* 现代人的生活节奏快，干啥事都想图个方便。
所以把易用性作为重要的质量属性对待无可非议。
* 导致软件易用性差的根本原因：
o 理工科大学教育存在缺陷：没有开设人机工程学、美学、心理学这些必修课，大部分开发人员不知道如何设计易用的软件产品。
o 开发人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也就会满意。
* 软件的易用性要让用户来评价。
当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“界面友好”、“方便易用”等词来评价软件产品。
清晰性
* 清晰意味者所有的工作成果易读、易理解，可以提高团队开发效率，降低维护代价。
* 开发人员只有在自己思路清晰的时候才可能写出让别人易读、易理解的程序和文档。
* 可理解的东西通常是简洁的。
一个原始问题可能很复杂，但高水平的人就能够把软件系统设计得很简洁。
如果软件系统臃肿不堪，它迟早会出问题。
所以简洁是人们对工作“精益求精”的结果，而不是潦草应付的结果。
* 千万不要把在学校里“造文章”的手法用于开发产品！
安全性
* 这里安全性是指信息安全，英文是Security而不是Safety。
* 安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。
* “道高一尺，魔高一丈” ，绝对安全的信息系统几乎不存在。
* 开发商和客户愿意为提高安全性而投入的资金是有限的，他们要考虑值不值得。
* 究竟什么样的安全性是令人满意的呢？
o 一般地，如果黑客为非法入侵花费的代价（考虑时间、费用、风险等因素）高于得到的好处，那么这样的系统可以认为是安全的。
可扩展性
* 可扩展性反映软件适应“变化”的能力。
* 在软件开发过程中，“变化”是司空见惯的事情，如需求、设计的变化，算法的改进，程序的变化等等。
由于软件是“软”的，是否它天生就容易修改以适应“变化”？关键要看软件的规模和复杂性。
* 现代软件产品通常采用“增量开发模式”，不断推出新版本，获取增值利润。
可扩展性越来越重要。
可扩展性是系统设计阶段重点考虑的质量属性。
兼容性
* 兼容性是指两个或两个以上的软件相互交换信息的能力。
* 兼容性的商业规则：弱者设法与强者兼容，否则无容身之地；强者应当避免被兼容，否则市场将被瓜分。
示例：
o 中国联通和中国移动的手机互联互通问题
o 金山软件公司的WPS与微软的Word之争
可移植性
* 可移植性是指软件运行于不同软硬件环境的能力
* 编程语言越低级，其程序越难移植，反之则容易。
软件设计时应该将“设备相关程序”与“设备无关程序”分开，将“功能模块”与“用户界面”分开。