软件需求分析审查准则.docx

软件需求分析阐明书审查规范文献编号受控编号版本1.0编制日期生效日期密级编制审核同意文献修改控制修改记录编号修改状态修改位置及内容修改人审核人同意人修改日期1.2.3.4.5.6.7.8.目录软件需求分析阐明书审查规范错误!未定义书签。目录错误!未定义书签。1 .引言错误!未定义书签。1.1. 目的错误!未定义书签。1.2. 合用范围错误!未定义书签。1.3. 用阐明错误!未定义书签。2 .参照资料错误!未定义书签。3 .术语定义错误!未定义书签。4 .质量规定错误!未定义书签。4.1. 完整性错误!未定义书签。4.1.1. 整体内容完整性错误!未定义书签。4.1.2. 需求项信息完整性错误!未定义书签。4.2. 对的性错误!未定义书签。4.3. 一致性错误!未定义书签。4.4. 可验证性错误!未定义书签。4.5. 划分优先级错误!未定义书签。4.6. 可用性错误!未定义书签。5 .附件错误!未定义书签。5.1. 某些编写提议错误!未定义书签。5.2. 部分参照实例错误!未定义书签。5.2.1. 需求项表格错误!未定义书签。5.2.2. 表格需求项实例错误!未定义书签。5.2.3. 优先级划分措施实例错误!未定义书签。5.2.4. 软件需求分析阐明书模板错误!未定义书签。.引言1.L目的软件需求分析阐明书在软件开发、测试、质量保证、项目管理以及有关项目功能中起着重要作用。为了保证软件阐明书对质量，木文档详细描述了软件需求分析阐明书所要包括口勺内容及其编制所要抵达的质量规定。1.2. 合用范围作为软件需求分析阐明书与否可以进入正式评审的审查原则，符合该规范时可以提交正式需求评审；作为测试人员编制软件需求分析阐明书审查列表日勺根据；作为开发人员编制软件需求分析阐明书H勺指导原则；1.3. 使用阐明本文重点对需求分析阐明书的内容进行规定，对体现方式、措施未明确提出规定对视为不作规定;本文中的“应”、“必须”含义等同：本文中H勺“既有H勺技术水平”指与该需求有关的行业中，可获得的、已知的、可实际运用于生产H勺、可信的、通过验证H勺所有技术；本文中H勺需求可行性以通过审核公布的项目可行性研究汇报为根据；2 .参照资料GB8566计算机软件开发规范受控编号？GB8567计算机软件产品开发文献编制指南受控编号？GB/T11457软件工程术语受控编号？SystematicSoftwareTestingRickD.Craig,StefanP.JaskielArtechHousePublishers2023-05-1统一软件开发过程RUP2023手册IBM企业2023年3 .术语定义GB/T11457所列术语和下列定义合用于本文需求系统必须符合的I条件或具有的）功能软件需求分析软件需求分析的基本任务是精确地定义未来系统的目日勺，确定为了满足顾客的需求，系统必须做什么。需求分析包括需求获取和需求规约：需求获取是系统分析员通过学习以及同顾客的交往，熟悉顾客领域的知识，并获得对未来系统的I需求；需求规约是系统分析员在获得了顾客的初步需求后，必须进行i致性分析和检查，通过和顾客协商处理其中存在的二义性和不一致性，并以种规范的形式精确地体现顾客H勺需求，形成软件需求分析阐明书。软件需求分析阐明书(SoftwareRequirementsSpecifications,简称SRS)：软件需求分析阐明书(也称软件需求规格阐明书、软件需求分析汇报)是软件需求分析阶段得到的最终文档，它以形式化的术语和体现对软件rJ功能和性能进行详细而详细的描述。它是顾客和开发者之间的技术协议，是软件设计、编码阶段的)基础,也是软件测试和验收的根据。IEEE软件工程原则词汇表(1997年)中定义为：(1)顾客处理问题或抵达目的所需口勺条件或权能(CaPability)。(2)系统或系统部件要满足协议、原则、规范或其他正式规定文档所需具有H勺条件或权能。(3) 一种反应上面(1)或(2)所描述的条件或权能的文档阐明。软件质量IEEE610.12-1990中定义：一种系统、组件或过程满足客户或顾客的需求的程度，或满足期望值的程度。(“Thedegreetowhichasystem,component,orprocessmeetscustomeroruserneedsorexpectations.,ISOIEC9126中定义：与软件产品满足规定的和隐含日勺需求的能力有关的特性或特性的全体。(Thetotalityoffeaturesandcharacteristicsofasoftwareproductthatbearonitsabilitytosatisfystatedorimpliedneeds.)软件质量保证软件质量保证，是为保证产品和服务充足满足消费者规定的质量而进行的J有计划、有组织的活动。软件质量保证是面向消费者的活动，是为了使产品实现顾客规定的功能，站在顾客立场上来掌握产品质量的I。软件的质量保证就是向顾客及社会提供满意的高质量的软件产品。可跟踪性指假如每一种需求的来源、变更历史是清晰的，在深入产生和变化文献编制时，可以以便地引证每一种需求，则该软件需求分析阐明书就是可追踪H勺。可修改性指假如一种软件需求分析阐明书的构造和风格在需求有必要变化时是易于实现的、且变化后仍然完整、一致於J,那么这个软件需求分析阐明书就是可修改的。可行性指在规定的时间限制和开销下、在特定的环境制约下、运用既有的技术、工具、资源和人力下，需求必须是可以实现的。详细包括：技术可行，既有H勺技术水平可以实现所有的需求；财政可行，有足够的资金来实现所有的需求，且实现H勺成本在可接受的范围内；时间可行，在指定的时间范围内可以实现所有的需求;资源可行，有足够的人力、物力来实现所有的需求;验证原则用以判断需求被实现后，实现日勺成果与否对的的根据。如I：对于性能需求，其验证原则是详细的性能指标；对于功能需求，其验证原则是详细的功能效果描述。软件测试软件测试是为了度量和提高被测软件的质量，对测试件进行工程设计、实行和维护时整个生命周期过程。(SystematicSoftwareTesting)统一建模语言(UML)UML(UnifiedModelingLangUage)是一种构建软件系统和文档的通用可视化建模语言。UML能与所有的I开发措施一同使用，可用于软件开发的整个生命周期。UML能体现系统的静态构造和动态信息，并能管理复杂的系统模型，便于软件团体之间的合作开发。UML不是编程语言，但支持UML语言的工具可以提供从UML到多种编程语言的代码生成，也可以提供从既有程序逆向构建UML模型。统一软件开发过程(RUP)RUP是一种通用软件过程框架，可以应付种类广泛的软件系统、不同样的应用领域、不同样H勺组织类型、不同样的性能水平和不同样的项目规模。“统一过程”是基于构件的，这意味着运用它开发H勺软件系统是由构件构成的，构件之间通过定义良好的接口互相联络。在准备软件系统H勺所有蓝图的时候，“统过程”使用的是“统建模语言(UnifiedMOdeIing1.anguage)”。实际上，UML是“统一过程”的有机构成部分一一它们是被同步开发的。然而，真正使“统一过程”与众不同样的方面可以用三个句话来体现：它是用例驱动H勺、以基本架构为中心的、迭代式和增量性的。4 .质量规定合格的软件需求分析阐明书要满足如下质量规定：1 .完整性2 .对的性3 .一致性4 .可验证性5 .划分优先级6 .可用性下面我们分别对每个质量规定进行阐明，同步给出怎样满足各质量规定的!指导原则。4.1. 完整性完整性是指软件需求分析阐明书包括了所有应当具有的内容，由于不同样的产品、项目对软件需求分析阐明书所应当具有的内容口勺不完全相似，因此为了便于指导和规范文档的实际编制本规范将完整性划分为整体内容完整性、需求项信息完整性，并针对不同样的内容提出不同样日勺规定，包括：必须和可选，详细如下：4.1.1. 整体内容完整性整体内容完整性用以确定整个软件需求分析阐明书中详细应当包括日勺内容和不应当包括的内容，详细如下：一.需求没有遗漏：确定在需求分析阐明书编制的过程中，没有遗漏需求获取阶段所确定的需求。其根据为包括但不仅限于通过正式审核的下列文档：1 .市场调研汇报；2 .顾客需求调查汇报；3 .需求分析讨论会议记录；二.需求没有冗余：即同一需求不能在软件需求分析阐明书中出现多次；三.不存在超过产品/项目范围H勺需求；四.除设计上的特殊限制之外，软件需求分析阐明书中不描述任何设计、验证或项目管理细节的内容；五 .软件需求分析阐明书必须包括下列信息：1 .目的：阐明编写这份软件需求阐明书的目的，指出预期的读者2 .概述：阐明产品或项目的背景、总体描述、功能、顾客特点、一般日勺设计约束。只描述影响产品及其需求的一般原因，不阐明详细的需求，概述的目的仅近使需求更易于理解3 .参照资料：列出软件需求分析阐明书中所有用得到的所有参照资料，详细阐明参照资料的来源。内容包括但不仅限于：1）木产品或项目的通过核准的I计划任务书或协议、上级机关的批文；2）本项目的其他已通过审核Fl勺正式文档；3）企业内部制定公布的正式管理文献;4）各处引用的资料，如出版物、网络资讯;5）所要用到的软件开发原则。且每条参照资料记录中包括的内容及格式应满足下列规定（按类型划分）：1）专著出版物：重要作者，其他作者，书名，版本，出版地：出版者，出版年；2）持续期刊出版物：文献作者，文献其他作者，题名，刊物名，版本：在原文献中的位置；3）原则：原则编，号原则名，企业受控编号；4）文献：文献编号，文献名，文献版本5）网络资讯：作者，题名，公布网址，公布时间4 .术语定义：提供软件需求分析阐明书中用到日勺专门术语、缩写词、缩略语的定义,这部分信息可以在软件需求分析阐明书中用一种单独章节提供或者在附录中提供，也可以参照其他的文献；5 .详细需求：指产品或项目必须符合的条件或具有的功能，它包括软件开发者在建立设计时需要的所有细节。由于不同样於J产品项目其需求都不同样，同样的需求可以使用不同样的!分类措施进行划分,因此这里只列举一种比较常见的划分方式,并分别加以阐明：1）功能需求：规定了在不考虑物理约束的状况下必须可以执行的动作，也就是一般所说的系统可以做什么；2）性能需求：是指软件功能在执行过程中需要满足Fl勺强加条件，如速度、效率、可使用性、响应时间、多种软件功能口勺恢复时间、吞吐能力、精度、频率、资源用途等等3）属性需求：可扩展性、可移植性、稳定性、可靠性、可维护性、兼容性、安全性、可配置性、可服务性、可安装性，可国际化性、可用性、易用性等方面H勺考虑原因；4）外部接口：顾客、硬件、其他软件和其他硬件的互有关系，如顾客接口、软件接口、硬件接口、通信接口等；5）强加的设计限制或实现约束：阐明必须遵守H勺技术原则和软硬件限制等设计约束，如对硬件配置H勺规定，对软件开发环境限制、运行环境限制和对软件设计、实现方式的限制；六 .包括第五条中未列出但应当在需求分析阐明书中阐明的J其他信息；七 .对第五条第5项详细需求所列出的几类需求的规定：除功能需求总是必须的，其他需求根据产品/项目的实际状况进行增删淘汰。4.1.2.需求项信息完整性需求项信息完整性指每个详细需求的需求项需包括足够的信息，来详细明确定义需求要实现H勺目的。一.针对每个需求项，必须包括下列信息：1 .唯一标识：跟踪需求的标签，唯一且不变，提议采用“项目编号+内部编号”方式，使需求编号在整个企业的范围内都是唯一点；2 .简要描述：简朴描述该需求要实现口勺目口勺；3 .类型：需求H勺类型，依所采用H勺需求分类措施而定;4 .目的：简要描述提出该需求的目的，若很明显则写“略”；5 .来源：谁提出该需求，详细可以是人（客户、顾客、员工）、企业、市场等；6 .详细描述：对该需求H勺详细阐明；由于不同样类型的需求其详细描述需要包括时内容不同样，下面分类列出详细应当包括的详细内容：A.功能性需求：应包括但不仅限于下列内容：1）环境规定，完毕该功能应当满足的详细条件，如什么状态、状况、什么样的软硬件环境下可以进行该功能；2）触发者,使该功能的执行的人或事，可以是顾客或是其他系统、定期事件等;3）输入：描述该功能执行前及在执行过程中所有输入的详细定义。例如：数据类型输入的数据类型、数量、度量单位、源、时间关系、规定（如精度）；功能执行过程中的顾客操作控制信息；事件类型输入的事件时间设定；所引用的用以统一定义输入的有关接口阐明或接口控制文献。4）处理：该功能所完毕的任务，即从输入到输出的变换操作过程。详细应包括但不仅限于下列内容：对所有输入H勺有效性检查；对所有输入的处理次序、流程或措施，即系统怎样把输入变换成对应输出，可以使用自然语言、方程式、数学算法、逻辑操作、图、表、状态机等不同样体现方式进行描述;对所有输出有效性的检查；对所有异常状况的处理及响应，例如，溢出、通信故障、要所有非合法输入的响应、错误处理等；5）输出：描述该功能所有最终预期成果的详细定义。如：数据类型输出的数据类型、数量、目的地、度量单位、时间关系、规定（如精度）；所引用H勺用以统一定义输出的有关接口阐明或接口控制文献。B.非功能性需求：性能需求：抵达该性能需求必须具有的条件或限制；该性能需求所要抵达的详细性能指标属性需求：可移植性：详细列出规定可以移植的J平台；可维护性：详细列出保证可维护性的详细的措施；安全性：详细列出要抵达口勺安全级别或安全程度：兼容性：详细列出所要兼容的平台或软硬件环境；可测试性：详细列出保证该特性的详细功能和措施；可靠性：详细列出可靠性的规定，如无端障运行时间；设计限制：列出所有的限制原因,如:需遵守的技术原则：列出所有必须遵守的技术原则、规范（包括原则名、原则编号、版本号（或公布日期）、企业受控编号信息）硬件限制：列出所有影响或约束产品/项目硬件成分，如运行环境最低配置;软件限制：列出所有影响或约束产品/项目的软件成分，如软件开发环境限制、软件运行环境限制和软件H勺设计限制；7 .验证原则：用于该需求被实现后，检查实现成果与否符合需求，给测试或顾客提供明确的验证根据。如：对于性能需求，列出详细的性能指标；对于功能需求，给出详细的实现效果；若验证原则已包括在详细描述中，则指明位置即可；8 .优先级：用以表明该需求在产品/项目中的重要程度及被实现代优先次序，应定义优先级的划分方式，不同样的产品/项目可以采用不同样的划分方式；9 .依赖性：对其他需求口勺存在、变化的依赖，如列出本需求所引用的需求，若无任何依赖，则写“无”；二.包括第一条中未列出但应当在需求项中阐明的其他信息；42对的性对的性指对需求H勺定义必须是对的，它涵盖了软件需求分析阐明书中所定义H勺需求与顾客的实际需求是一致的、对需求内容的描述是明确、精确、精确和无歧义的。详细应满足但不仅限于下列规定：1 .每个需求与顾客的实际需求是一致，即对的体现了顾客的真正需求，可以使用让顾客确认的方式来保证；2 .内容的体现没有错误，应满足包括但不仅限于下列规定:1）使用对的的语法，拼写，标点;2）无错字和别字；3）用词贴确；3 .内容的体现无歧义，如同一读者对同一体现通过不同样的断句方式得出多种对时时理解：4 .无不一致的内容，详见质量规定的“一致性”部分；5 .没有因使用不明确的表述而存在可随意发挥的内容，如：描述中出现了对于软件需求分析阐明书作者自己很清晰但读者并不清晰H勺主观性词语（除了己经对这些词语进行了明确H勺定义或引用阐明），详细如：“待定”、“也许”、“即将”、“考虑”、“最佳”、“最差”、“一般状况”、“特殊状况”、“可以”、“顾客友好性”，“轻易”,“简朴”，“迅速卜“有效”，“几种”，“艺术级”，“改善的”，“最大”，“最小”、“很好”、“较差”、“等等”、“一期实现”、“根据需要”、“假如也许”、“高级”。4.3. 一致性一致性指不存在内容互相矛盾的地方。详细应满足但不仅限于下列规定：1 .同一内容在整个软件需求分析阐明书中其内涵和外延都是一致的；2 .不存在一种需求与软件的其他需求或高级别In系统需求发生冲突的现象；3 .术语的定义与原则、规范、行业顾客的定义一致；4 .需求被引用时的含义与定义时的含义保持一致；5 .术语被引用时的含义与定义时的含义保持一致，若某一术语在某一特殊的行文中使用时具有多种歧义，那么对该术语的每种含义作出解释并指出其合用场所;44可验证性可验证性指针对每项需求可以找到某种措施，通过这种措施可以验证该需求被实现后其实现Fl勺成果与否对的。详细应满足但不仅限于下列规定：1.每个需求必须是可行於J,只有可行的才是可验证的；2 .每个需求项必须有明确的验证原则，且验证原则在既有的技术水平下是可测量的（可以找到某种测试措施，通过这种措施可以明确判断出与否已经抵达预期指定的规定），如对于该性能需求，必须给出已经量化口勺所要抵达的详细性能指标，且这些指标都能用某种措施或工具进行测量；3 .需求必须一致的，详见质量规定的“一致性”部分；4 .需求必须是明确口勺，详见质量规定口勺“对时性”部分的第5条：如任何需求假如说“产品/项目将要支持什么”是不可验证的，必须详细阐明何时支持，怎样支持。4.5.划分优先级划分优先级指为每个需求指定实行的优先级，以表明它在产品/项目中的重要程度及被实现代优先次序。详细应满足下列规定：为整个软件需求分析阐明书制定统一的优先级划分原则；为每个需求指定一种定义好的优先级；46.可用性可用性指需求分析阐明书易于阅读、理解、修改、跟踪、维护、管理。详细应满足但不仅限于下列规定:1 .每项需求均有唯一标识，便于需求的引用、跟踪、管理；2 .明确指出需求间的互有关联，便于在需求变更时确定变更所波及和影响的范围；3 .明确阐明每项需求的来源和目H勺，便于需求的跟踪、维护；4 .维护记录需求的修改历史，便于需求的跟踪、管理；5 .对需求进行良好H勺组织，如：对需求进行类型划分后将有关的需求分组，对需求进行层次划分使需求H勺构造层次清晰，为需求建立目录表、索引等。便于需求的阅读、管理。6 .编写、排版风格保持统一，便于阅读、理解，如对于同一类的内容，使用相似的体现方式和措施；7 .最终产品的每一种特性用某一术语描述，便于修改、维护；8 .部分编写格式符合一定的原则，如参照文档记录的格式；9 .需求的粗细粒度要保持一致;如软件需求分析阐明书中同步存在下列的需求描述,其粒度是不一致日勺：“顾客信息对于红色合法的颜色代码应是R”、“对于绿色合法的颜色代码应是G"、“产品应能对来自语音编辑指示做出反应”，最终一种需求应作为一种子系统而不应作为单个的I功能性需求。10 .对多处出现的同一内容进行统一的定义再分别引用，便于修改、维护和保证一致性；11 .防止将多种需求合成单个需求12 .若选择使用某软件需求分析阐明书的模板，应：D假如模板中Fl勺个别章节或部分内容不合用，则在软件需求分析阐明书中要保留章节号并写明不合用，不应删除;2）若模板中未列出，但需求中应当包括的信息，应在文档中合适H勺位置添加;5.附件此章节内容只作为开发人员编写软件需求分析阐明书时的一种参照，不作为审查的内容。5.1. 某些编写提议列出软件需求分析阐明书编写过程中的某些提议，这些提议的描述相对比较定性、笼统。1 .使用书面语，不用口语；2 .使用短句和短的段落；3 .采用积极语气；4 .语句体现方式的风格要保持一致；5 .编写时尽量使用定量、客户的词汇，少用定性、主观的词汇；6 .编写时以开发人员的角度来审阅与否需要软件需求分析阐明书作者的额外解释和协助开发人员才能理解需求，才能进行设计和实现？若是，则需深入细化需求；7 .防止一种段落中包括了多种的需求；8 .对软件需求阐明书进行持续的改善，软件产品的开发过程中，在项目的开始阶段也许无法详细阐明某些细节，在开发过程中也许发现缺陷、缺陷和错误，一旦发现需立即按需求管理的!流程改善；9 .不要在一种需求中使用“和”/“或"，以防止将多种需求合成一种需求:10 .使用需求编制、管理工具，以便需求的变更并保证变更后需求仍是一致口勺、保证编写和排版风格的统一；11 .尽量使用形式化的语言，少用自然语言，如使用UML、图、表格、规范化模型等方式。由于尽管自然语言是丰富多彩的，但不易精确表述；12 .编写时重点在其体现H勺内容，不要拘泥于体现的形式，形式可以多种多样，合适易用时即可；13 .提议选择使用合用的需求分析阐明书模板；52部分参照实例列出软件需求分析阐明书中部分重要内容的常见体现方式口勺例子。5.2.1. 需求项表格使用表格的方式来组织需求项口勺内容。唯一标识【必须】（跟踪需求的标签，唯一且不变，提议采用（项目编号+文档的内部编号）方式，使需求编号在整个企业口勺范围内都是唯一点）简要描述【必须】（简朴描述该需求要实现H勺目H勺）类型【必须】（需求的类型，依需求的分类措施而定）目的【可选】（简要描述提出该需求的目的，若很明显则写“略”）来源【必须】（指谁提出该需求，详细可以是人（客户、顾客、员工）、企业、市场等）详细描述【必须】对该需求的详细阐明；由于不同样类型的需求其详细描述需要包括的内容不同样，下面分类列出详细应当包括的详细内容：A.功能性需求：应包括但不仅限于下列内容：1 .环境规定：完毕该功能应当满足的详细条件，如什么状态、状况、什么样的软硬件环境下可以进行该功能；2 .触发者：使该功能的执行的人或事，可以是顾客或是其他系统、定期事件等；3 .输入：描述该功能执行前及在执行过程中所有输入的详细定义。例如：数据类型输入日勺数据类型、数量、度量单位、源、时间关系、规定（如精度）；功能执行过程中的顾客操作控制信息；事件类型输入的事件时间设定；所引用的用以统一定义输入H勺有关接口阐明或接口控制文献。4 .处理：该功能所完毕的J任务，即从输入到输出的变换操作过程。详细应包括但不仅限于下列内容：对所有输入的有效性检查；对所有输入的处理次序、流程或措施，即系统怎样把输入变换成对应输出，可以使用自然语言、方程式、数学算法、逻辑操作、图、表、状态机等不同样体现方式进行描述；对所有输出有效性的检查；对所有异常状况的处理及响应，例如，溢出、通信故障、要所有非合法输入的响应、错误处理等；5 .输出：描述该功能所有最终预期成果的详细定义,如：数据类型输出口勺数据类型、数量、目的地、度量单位、时间关系、规定（如精度）；所引用的用以统一定义输出的有关接口阐明或接口控制文献。非功能性需求：性能需求：抵达该性能需求必须具有的条件或限制；该性能需求所要抵达的详细性能指标属性需求：可移植性：详细列出规定可以移植的平台；可维护性：详细列出保证可维护性的详细的措施；安全性：详细列出要抵达的安全级别或安全程度；兼容性：详细列出所要兼容的平台或软硬件环境；可测试性：详细列出保证该特性的详细功能和措施；设计限制：列出详细口勺限制原因；验证原则【必须】（用于后期检查实现成果与否符合需求，给测试或顾客提供明确的验证根据。如1：对于性能需求，列出详细的）性能指标；对于功能需求，给出详细的实现效果；若验证原则已包括在详细描述中，则指明位置即,）优先级【必须】（用以表明该需求在产品/项目中的重要程度及被实现代优先次序，应定义优先级H勺划分方式，不同样的产品/项目可以采用不同样的划分方式）依赖性【必须】（对其他需求的存在、变化口勺依赖，如列出本需求所引用的需求，若无任何依赖，则写“无）5.2.2. 表格需求项实例使用表格方式组织需求项内容的一种简朴实例。唯一标识XX_SDK_简要描述视频预览类型功能目的满足顾客对视频进行实时预览的规定提出人XX详细描述该功能的环境规定：1 .装有板卡及对应的驱动；2 .安装了显卡及对应的驱动；该功能的触发者：顾客该功能的输入：视频通道，显示位置该功能的处理：能控制通道对应的视频源数据通过显卡在屏幕上实时显示出来。能对如下异常状况反馈顾客告知：1）忽视频信号；2）显卡未准备好；该功能的输出：显示在屏幕上的视频预览图像；该功能波及的关键术语的索引或解释：无验证原则1 .能正常预览视频图像；2 .预览图像实时（实时原则：24fps）;3 .对异常状况下口勺处理参照详细描述中内容；优先级高依赖性XX_SDK_：显卡管理5.2.3. 优先级划分措施实例进行优先级划分时首先要制定划分原则，下面为优先级划分措施的2个例子:1.根据需求对产品或项目的重要性进行简朴的划分：高：必须实现的基本功能、性能需求或客户强烈规定实现的需求；中：辅助需求;低：特色需求;2.以通过对每个需求综合评估优先级的J多种影响原因及每个原因H勺权重，再计算出优先权值，最终再根据优先权值划分优先级，或者直接使用优先权值体现优先级;如：确定优先权值与优先级的对应关系：综合优先权值优先级70100r4069中139低确定优先级H勺考虑原因、权重分派及综合优先权值算法:原因（Fn,列出所有考虑原因）原因的J优先权值（Pn：1-100）权重（Wn：O-I,所有原因H勺权重和为1）对客户的重要程度最重要日勺取100,最不重要的取10.8预估的实现成本成本最低於J取100,成本最高的取10.150.05综合优先权值(Pn*Wn)优先级一种需求的优先级评估:原因（Fn,列出所有考虑原因）原因的优先权值（Pn：l-100）权重（Wn：01,所有原因的权重和为1）对客户H勺重要程度900.8预估的实现成本600.15400.05综合优先权值(Pn*Wn)=90×0.8+60X0.15+40X0.05=83优先级高5.2.4. 软件需求分析阐明书模板列出实际工作中也许比较常用!勺软件需求分析阐明书模板。1 .计算机软件产品开发文献编制指南(GB8567-88)之软件需求阐明书模板国标GB8567-88计算机软件产品开发文献编制指南中的软件需求阐明书模板。计软竹产部开发文件”词指南(CB2 .RUP2023模板包括软件需求规约模板与软件需求补充规约模板，两者构成相对完整的需求分析，合用于采用RUP过程的需求分析。RI2002软件W求MlRfT22软件；8求补约AUk先艘为HUk