软件需求规约(带有用例)Software Requirements Specification

合集下载

软件需求规约

软件需求规约
简介
软件需求规约是分析任务的最终产物，是定义需求的基本格式。

通过建⽴完整的信息描述、详细的功能和⾏为描述、性能需求和设计约束的说明、合适的验收标准，给出对⽬标软件的各种需求。

⼀个需求规约是⼀个软件项/产品/系统所有需求陈述的正式⽂档，是⼀个软件产品/系统的概念模型。

表达需求规约（规格说明书）的风格
⾮形式化的规约
即以⼀种⾃然语⾔来表达需求规约，如同使⽤⼀种⾃然语⾔写了⼀篇⽂章
半形式化的规约
即以半形式化符号体系（包含术语表、标准化的表达格式等）来表达需求规约。

因此，半形式化规约的编制应遵循⼀个标准的表⽰模板（⼀些约定）。

形式化规约
即以⼀种基于良构数学概念的符号体系来编制需求规约，⼀般往往有解释性注释的⽀持。

需求规约的作⽤
最重要的，作为软件开发组织和⽤户之间⼀份事实上的技术合同书；是产品功能及其环境的体现。

对于项⽬的其余⼤多数⼯作，它是⼀个管理控制点。

对于产品设计，它是⼀个正式的、受控的起点。

是创建产品验收测试计划和⽤户指南的基础，即基于需求分析规约⼀般还会产⽣另外两个⽂档——初始测试计划和⽤户系统操作描述。

需求规约不能实现的
它不是⼀个设计⽂档，它是⼀个“为了”设计⽂档。

它不是进度或规划⽂档，不应该包含更适宜包含在⼯作陈述（SOW）、软件配置管理计划（spmp）、软件⽣存周期管理计划
（SCMP）或软件质量保证计划（SQAP）等⽂档中的信息。

不应给出：项⽬成本；交付进度；报告规程；软件开发⽅法；质量保证规程；验收规程；安装规程。

软件需求规范

软件需求规范软件需求规范是对软件实施的全过程进行描述和指导的一种综合文件，是软件开发的基础文档之一。

软件需求规范的主要目的是明确软件的功能、性能、界面、安全等方面的需求，为软件开发和测试提供依据。

软件需求规范一般包括以下内容：1. 介绍：对软件的背景、目的、范围、读者等进行介绍，为后续内容提供背景信息和上下文。

2. 功能需求：对软件的主要功能进行详细描述，包括输入、输出、处理逻辑等方面的需求。

可以采用用例图、用例描述等方式进行描述。

3. 非功能需求：对软件的性能、可靠性、安全性、可用性等方面的需求进行详细描述。

可以包括性能指标、数据安全性要求、用户友好性等方面的要求。

4. 界面需求：对软件的用户界面进行详细描述，包括界面布局、样式、交互逻辑等方面的要求。

可以采用界面原型、界面流程图等方式进行描述。

5. 数据需求：对软件的数据模型、数据流程、数据存储等方面的需求进行描述。

可以使用数据模型图、数据流程图等方式进行描述。

6. 约束和限制：对软件开发和实施过程中的约束和限制进行描述，包括时间、成本、技术平台、法律法规等方面的约束。

7. 接口需求：对软件与其他系统、硬件设备等的接口进行描述，包括数据格式、通信协议、接口功能等方面的要求。

8. 测试需求：对软件测试的需求进行描述，包括测试用例、测试环境、测试数据等方面的要求，为测试人员提供指导。

软件需求规范应具有以下特点：1. 明确性：需求规范中的要求应该具有明确性，能够让软件开发人员和测试人员一目了然，不产生二义性。

2. 完整性：需求规范应该尽可能地覆盖软件的各个方面，包括功能需求、非功能需求、界面需求等。

3. 一致性：需求规范中的各个部分应该是一致的，相互之间不产生矛盾。

4. 可追踪性：需求规范应该具有可追踪性，能够将需求与软件的设计、实现、测试等阶段进行关联。

5. 可验证性：需求规范中的要求应该是可验证的，能够通过测试或其他手段进行验证。

以上只是软件需求规范的一些基本要点，具体的需求规范内容和格式可以根据具体项目的情况进行调整。

软件需求与软件需求规约

其次，了解需求工作在系统工程中的位置
图工程活动和产品流
摘自《软件工程最佳实践－项目经理的指南》
附注：
•系统工程过程是一组集成的、有序的活动和决策，把一个定义的需求转化未一个可操作的、生存周期优化的系统，该系统实现了组件的集成并达到最佳的平衡。
——《ＵS Airforce.Technical Reviews and Audits for systems, Equipment, and Computer programs. JointPolicy Coordination Group on Computer Resource Management, Washington DC》
外部接口需求外部接口需求(External interface requirement)规约了系统或系统构件必须与之交互的硬件、软件或数据库元素。它也可能规约其格式、时间或其他因素。例如：账户接收系统必须为月财务状况系统提供更新信息，如在“ 财务系统描述”第4修订版中所描述的。引擎控制系统必须正确处理从飞行控制系统接收来的命令，符合接口控制文档B2-10A4，修订版C的1到8段的规定。
设计约束设计约束限制了系统或系统构件的设计方案。就约束的本身而言，对其进行权衡或调整是相当困难的，甚至是不可能的。它们必须予以满足。这一性质，是与其它需求的最主要差别。为了满足功能、性能和其它需求，许多设计约束将对软件项目规划、所需要的附加成本和工作产生直接影响。例如：
•系统必须用C++或其他面向对象语言编写。系统用户接口需要菜单。 •任取10秒，一个特定应用所消耗的可用计算能力平均不超过50%。 •必须在对话窗口的中间显示错误警告，其中使用红色的、14点加粗Arial 字体。

软件需求规约模板

软件需求规约。

Software Requirements Specification项目名称：。

摘要：本文档系统阐述使一台Windows客户端，。

本文档主要介绍。

在开发过程中的具体需求，以及设计约束条件，作为将来项目设计、测试和验收的标准。

SoftwareRequirementSpecification（软件需求分析）

SoftwareRequirementSpecification（软件需求分析）the College Online Q&A System--Software Requirement Specification1. Introduction1.1. PurposeThe purpose of this document is to present a detailed description of the College Online Q&A System. It will explain the purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which it must operate and how the system will react to external system. This document is intended for both the stakeholders and the developers of the system.1.2. Scope of ProjectThis software system will be an Online Q&A System for the students in the college. This system will help students to find answers to any questions they want to know, even they can answer question raised by other students to help solve their problems. By maximizing the efficiency for students to find answers, this system will meet their demands while remaining easy to understand and use. The software will facilitate communication between students via the internet. The system also contains a relational database containing a list of questions, answers, and students’ information.1.3 Definitions, Acronyms, and AbbreviationsThis term refers to the short name of the system. The full name is College Online Questions And Answers System.When a student search for answers, the COQAS will also provided information from other website. Using the search Engineer of other website, we can provide the links to the student.The system is designed for the students. So when a person registers for the system, the system must verify the person. As a result, the COQAS needs the Student information System to verify the student ID number or other account.The student will be ranked to several levels, according to the total mark of each student. The student can get point from answering questions.When a student wants to ask questions, he can set the awarding points in order to give them to the student who provided the best answer to the question. If he or she gives awarding points to others, he or she will lost the corresponding points.A question may have a list of answers, the student who asked the question has the right to select the best answer and give the awarding points to the students who provided the best answers.1.4 ReferencesIEEE Standard 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.1.5. Overview of DocumentThe next chapter, the Overall Description section, of this document gives an overview of the functionality of the product. It shows the use cases in the use case diagram and list how the use cases are intended to do.The third chapter, Requirements Specification section, of this document is written primarily for the developers and describes in technical terms the details of the functionality of the product.The supporting information chapter includes the table of contents; index and appendices with glossaries are explained.2. Overall Description2.1 Use-Case Model SurveyThe COQAS has two active actors and two cooperating systems.The Student and Administrator access the COQAS by logging in through the Internet. The Student may search answer, ask a question and answer a question. The Administrator can manage the users and questions. There is a link to the (existing) Student Information System and Search Engine. More details are shown in the use case diagram and table below.3.2 Functional Requirement 3.2.1 Use Case: Login 3.2.2 Use Case: Search Answer2.2 Assumptions and DependenciesThe existing Student Information System and Search Engines which reside on the server will continue to be supported until at least 2008.The external interfaces of the Student Information System and Search Engines are as defined and will not be altered.It is assumed that the College will continue to operate and support the existing server until at least 2008.3. Specific Requirements3.1 Use-Case Reports3.2 Supplementary Requirements4. Supporting InformationMore details are referred in the Supporting Information Documentation。

为了确保软件的实现满足需求

为了确保软件的实现满足需求，至少需要下列基本文档(2011-08-30 11:16:14)转载▼标签：分类：软考杂谈为了确保软件的实现满足需求，至少需要下列基本文档：4.3.1.1软件需求规格说明书software requirements specification软件需求规格说明书必须清楚、准确地描述软件的每一个基本需求（功能、性能、设计约束和属性）和外部界面。

必须把每一个需求规定成能够通过预先定义的方法（例如检查、分析、演示或测试等）被客观地验证与确认的形式。

软件需求规格说明书的详细格式按GB 8567。

4.3.1.2软件设计说明书software design description软件设计说明书应该包括软件概要设计说明和软件详细设计说明两部分。

其概要设计部分必须描述所设计软件的总体结构、外部接口、各个主要部件的功能与数据结构以及各主要部件之间的接口；必要时还必须对主要部件的每一个子部件进行描述。

其详细设计部分必须给出每一个基本部件的功能、算法和过程描述。

软件设计说明书的详细格式按GB 8567。

4.3.1.3软件验证与确认计划software verification and validation plan软件验证与确认计划必须描述所采用的软件验证和确认方法（例如评审、检查、分析、演示或测试等），以用来难软件需求规格说明书中的需求是否已由软件设计说明书描述的设计实现；软件设计说明书表达的设计是否已由编码实现。

软件验证与确认计划还可用来确认编码的执行是否与软件需求规格说明书中所规定的需求相一致。

软件验证与确认计划的详细格式按GB 8567中的测试计划的格式。

4.3.1.4软件难和确认报告software verification and validation report软件验证与确认报告必须描述软件验证与确认计划的执行结果。

这里必须包括软件质量保证计划所需要的所有评审、检查和测试的结果。

软件需求的职责和要求

软件需求的职责和要求Software requirements are essential for defining the responsibilities and specifications that a software application must meet. 软件需求是定义软件应用程序必须满足的职责和规范的关键。

They serve as a blueprint for the development team, guiding them on what needs to be built and ensuring the final product meets the needs of its users. 它们为开发团队提供了一个蓝图，指导他们建造什么，并确保最终产品满足用户的需求。

One of the main responsibilities of software requirements is to clearly outline the functionality that the software must provide. 软件需求的主要责任之一是清楚地概述软件必须提供的功能。

This includes defining the various features, capabilities, and tasks that the software should be able to perform to meet user needs. 这包括定义软件应该能够执行的各种特性、功能和任务，以满足用户的需求。

In addition to functionality, software requirements also establish non-functional requirements that dictate how the software should perform. 除功能外，软件需求还制定了规定软件应如何执行的非功能性需求。

需求规格说明书模板4种版本

需求规格说明书(ISO标准版)编者说明：当需求调查、分析工作告一段落时，你就需要将这些需求进行规格化描述，整理成文，即软件需求规格说明书，也就是SRS。

这是在软件项目过程中最有价值的一个文档。

ISO所提供的标准虽然已经时间久远，但还是颇具参考价值的。

1．引言1.1编写的目的[说明编写这份需求说明书的目的,指出预期的读者。

]1.2背景a. 待开发的系统的名称;b. 本项目的任务提出者、开发者、用户；c. 该系统同其他系统或其他机构的基本的相互来往关系。

1.3定义[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

]1.4参考资料[列出用得着的参考资料。

]2．任务概述2.1目标[叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景材料。

解释被开发系统与其他有关系统之间的关系。

]2.2用户的特点[列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本系统的预期使用频度。

]2.3假定和约束[列出进行本系统开发工作的假定和约束。

]3．需求规定3.1对功能的规定[用列表的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出，说明系统的容量,包括系统应支持的终端数和应支持的并行操作的用户数等指标。

]3.2 对性能的规定3.2.1精度[说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。

]3.2.2时间特性要求[说明对于该系统的时间特性要求。

]3.2.3灵活性[说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。

]3.3输入输出要求[解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。

对系统的数据输出及必须标明的控制输出量进行解释并举例。

]3.4数据管理能力要求（针对软件系统）[说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。

软件的测试英语术语+缩写

软件测试常用英语词汇静态测试：Non-Execution-Based Testing或Static testing 代码走查：Walkthrough代码审查：Code Inspection技术评审：Review动态测试：Execution-Based Testing白盒测试：White-Box Testing黑盒测试：Black-Box Testing灰盒测试：Gray-Box Testing软件质量保证SQA：Software Quality Assurance软件开发生命周期：Software Development Life Cycle冒烟测试：Smoke Test回归测试：Regression Test功能测试：Function Testing性能测试：Performance Testing压力测试：Stress Testing负载测试：Volume Testing易用性测试：Usability Testing安装测试：Installation Testing界面测试：UI Testing配置测试：Configuration Testing文档测试：Documentation T esting兼容性测试：Compatibility Testing安全性测试：Security Testing恢复测试：Recovery Testing单元测试：Unit Test集成测试：Integration Test系统测试：System Test验收测试：Acceptance T est测试计划应包括：测试对象：The Test Objectives测试范围：The Test Scope测试策略：The Test Strategy测试方法：The Test Approach,测试过程：The test procedures,测试环境：The Test Environment,测试完成标准：The test Completion criteria 测试用例：The Test Cases测试进度表：The T est Schedules风险：Risks接口：Interface最终用户：The End User正式的测试环境：Formal Test Environment确认需求：Verifying The Requirements有分歧的需求：Ambiguous Requirements运行和维护：Operation and Maintenance.可复用性：Reusability可靠性：Reliability/Availability电机电子工程师协会IEEE：The Institute of Electrical and Electronics Engineers) 正确性：Correctness实用性：Utility健壮性：Robustness可靠性：Reliability软件需求规格说明书：SRS （software requirement specification ）概要设计：HLD （high level design ）详细设计：LLD （low level design ）统一开发流程：RUP （rational unified process ）集成产品开发：IPD （integrated product development ）能力成熟模型：CMM （capability maturity model ）能力成熟模型集成：CMMI （capability maturity model integration ）戴明环：PDCA （plan do check act ）软件工程过程组：SEPG （software engineering process group ）集成测试：IT （integration testing ）系统测试：ST （system testing ）关键过程域：KPA （key process area ）同行评审：PR （peer review ）用户验收测试：UAT （user acceptance testing ）验证和确认：V&V （verification & validation ）控制变更委员会：CCB （change control board ）图形用户界面：GUI （graphic user interface ）配置管理员：CMO （configuration management officer ）平均失效间隔时间：（MTBF mean time between failures ）平均修复时间：MTTR （mean time to restoration ）平均失效时间：MTTF （mean time to failure ）工作任务书：SOW （statement of work ）α测试：alpha testingβ测试：beta testing适应性：Adaptability可用性：Availability功能规格说明书：Functional Specification软件开发中常见英文缩写和各类软件开发文档的英文缩写：英文简写文档名称MRD market requirement document （市场需求文档）PRD product requirement document （产品需求文档）SOW 工作任务说明书PHB Process Handbook (项目过程手册)EST Estimation Sheet (估计记录)PPL Project Plan (项目计划)CMP Software Management Plan( 配置管理计划)QAP Software Quality Assurance Plan （软件质量保证计划）RMP Software Risk Management Plan （软件风险管理计划）TST Test Strategy（测试策略）WBS Work Breakdown Structure （工作分解结构）BRS Business Requirement Specification(业务需求说明书)SRS Software Requirement Specification(软件需求说明书)STP System Testing plan (系统测试计划)STC System Testing Cases （系统测试用例）HLD High Level Design (概要设计说明书)ITP Integration T esting plan (集成测试计划)ITC Integration T esting Cases （集成测试用例）LLD Low Level Design (详细设计说明书)UTP U nit Testing Plan ( 单元测试计划)UTC U nit Testing Cases （单元测试用例）UTR U nit Testing Report （单元测试报告）ITR Integration T esting Report （集成测试报告）STR System Testing Report （系统测试报告）RTM Requirements Traceability Matrix (需求跟踪矩阵) CSA C onfiguration Status Accounting （配置状态发布）CRF Change Request Form （变更申请表）WSR Weekly Status Report （项目周报）QSR Quality Weekly Status Report （质量工作周报）QAR Quality Audit Report(质量检查报告) QCLQuality Check List(质量检查表)PAR Phase Assessment Report （阶段评估报告）CLR Closure Report （项目总结报告）RFF Review Finding Form (评审发现表)MOM Minutes of Meeting （会议纪要）MTX Metrics Sheet （度量表）CCF ConsistanceCheckForm（一致性检查表）BAF Baseline Audit Form（基线审计表）PTF Program Trace Form（问题跟踪表）领测国际科技（北京）有限公司领测软件测试网/软件测试中英文对照术语表A•Abstract test case (High level test case) ：概要测试用例•Acceptance：验收•Acceptance criteria：验收标准•Acceptance testing：验收测试•Accessibility testing：易用性测试•Accuracy：精确性•Actual outcome (actual result) ：实际输出/实际结果•Ad hoc review (informal review) ：非正式评审•Ad hoc testing：随机测试•Adaptability：自适应性•Agile testing：敏捷测试•Algorithm test (branch testing) ：分支测试•Alpha testing：alpha 测试•Analyzability：易分析性•Analyzer：分析员•Anomaly：异常•Arc testing：分支测试•Attractiveness：吸引力•Audit：审计•Audit trail：审计跟踪•Automated testware：自动测试组件•Availability：可用性B•Back-to-back testing：对比测试•Baseline：基线•Basic block：基本块•Basis test set：基本测试集•Bebugging：错误撒播•Behavior：行为•Benchmark test：基准测试•Bespoke software：定制的软件•Best practice：最佳实践•Beta testing：Beta 测试领测国际科技（北京）有限公司领测软件测试网/•Big-bang testing：集成测试•Black-box technique：黑盒技术•Black-box testing：黑盒测试•Black-box test design technique：黑盒测试设计技术•Blocked test case：被阻塞的测试用例•Bottom-up testing：自底向上测试•Boundary value：边界值•Boundary value analysis：边界值分析•Boundary value coverage：边界值覆盖率•Boundary value testing：边界值测试•Branch：分支•Branch condition：分支条件•Branch condition combination coverage：分支条件组合覆盖率•Branch condition combination testing：分支条件组合测试•Branch condition coverage：分支条件覆盖率•Branch coverage：分支覆盖率•Branch testing：分支测试•Bug：缺陷•Business process-based testing：基于商业流程的测试C•Capability Maturity Model (CMM) ：能力成熟度模型•Capability Maturity Model Integration (CMMI) ：集成能力成熟度模型•Capture/playback tool：捕获/回放工具•Capture/replay tool：捕获/重放工具•CASE (Computer Aided Software Engineering) ：电脑辅助软件工程•CAST (Computer Aided Software Testing) ：电脑辅助软件测试•Cause-effect graph：因果图•Cause-effect graphing：因果图技术•Cause-effect analysis：因果分析•Cause-effect decision table：因果判定表•Certification：认证•Changeability：可变性•Change control：变更控制•Change control board：变更控制委员会•Checker：检查人员•Chow's coverage metrics (N-switch coverage) ：N 切换覆盖率•Classification tree method：分类树方法•Code analyzer：代码分析器•Code coverage：代码覆盖率领测国际科技（北京）有限公司领测软件测试网/•Code-based testing：基于代码的测试•Co-existence：共存性•Commercial off-the-shelf software：商用离岸软件•Comparator：比较器•Compatibility testing：兼容性测试•Compiler：编译器•Complete testing：完全测试/穷尽测试•Completion criteria：完成标准•Complexity：复杂性•Compliance：一致性•Compliance testing：一致性测试•Component：组件•Component integration testing：组件集成测试•Component specification：组件规格说明•Component testing：组件测试•Compound condition：组合条件•Concrete test case (low level test case) ：详细测试用例•Concurrency testing：并发测试•Condition：条件表达式•Condition combination coverage：条件组合覆盖率•Condition coverage：条件覆盖率•Condition determination coverage：条件判定覆盖率•Condition determination testing：条件判定测试•Condition testing：条件测试•Condition outcome：条件结果•Confidence test (smoke test) ：信心测试（冒烟测试）•Configuration：配置•Configuration auditing：配置审核•Configuration control：配置控制•Configuration control board (CCB) ：配置控制委员会•Configuration identification：配置标识•Configuration item：配置项•Configuration management：配置管理•Configuration testing：配置测试•Confirmation testing：确认测试•Conformance testing：一致性测试•Consistency：一致性•Control flow：控制流•Control flow graph：控制流图•Control flow path：控制流路径•Conversion testing：转换测试•COTS (Commercial Off-The-Shelf software) ：商业离岸软件•Coverage：覆盖率•Coverage analysis：覆盖率分析领测国际科技（北京）有限公司领测软件测试网/ •Coverage item：覆盖项•Coverage tool：覆盖率工具•Custom software：定制软件•Cyclomatic complexity：圈复杂度•Cyclomatic number：圈数D•Daily build：每日构建•Data definition：数据定义•Data driven testing：数据驱动测试•Data flow：数据流•Data flow analysis：数据流分析•Data flow coverage：数据流覆盖率•Data flow test：数据流测试•Data integrity testing：数据完整性测试•Database integrity testing：数据库完整性测试•Dead code：无效代码•Debugger：调试器•Debugging：调试•Debugging tool：调试工具•Decision：判定•Decision condition coverage：判定条件覆盖率•Decision condition testing：判定条件测试•Decision coverage：判定覆盖率•Decision table：判定表•Decision table testing：判定表测试•Decision testing：判定测试技术•Decision outcome：判定结果•Defect：缺陷•Defect density：缺陷密度•Defect Detection Percentage (DDP) ：缺陷发现率•Defect management：缺陷管理•Defect management tool：缺陷管理工具•Defect masking：缺陷屏蔽•Defect report：缺陷报告•Defect tracking tool：缺陷跟踪工具•Definition-use pair：定义-使用对•Deliverable：交付物•Design-based testing：基于设计的测试•Desk checking：桌面检查领测国际科技（北京）有限公司领测软件测试网/ •Development testing：开发测试•Deviation：偏差•Deviation report：偏差报告•Dirty testing：负面测试•Documentation testing：文档测试•Domain：域•Driver：驱动程序•Dynamic analysis：动态分析•Dynamic analysis tool：动态分析工具•Dynamic comparison：动态比较•Dynamic testing：动态测试E•Efficiency：效率•Efficiency testing：效率测试•Elementary comparison testing：基本组合测试•Emulator：仿真器、仿真程序•Entry criteria：入口标准•Entry point：入口点•Equivalence class：等价类•Equivalence partition：等价区间•Equivalence partition coverage：等价区间覆盖率•Equivalence partitioning：等价划分技术•Error：错误•Error guessing：错误猜测技术•Error seeding：错误撒播•Error tolerance：错误容限•Evaluation：评估•Exception handling：异常处理•Executable statement：可执行的语句•Exercised：可执行的•Exhaustive testing：穷尽测试•Exit criteria：出口标准•Exit point：出口点•Expected outcome：预期结果•Expected result：预期结果•Exploratory testing：探测测试领测国际科技（北京）有限公司领测软件测试网/F•Fail：失败•Failure：失败•Failure mode：失败模式•Failure Mode and Effect Analysis (FMEA) ：失败模式和影响分析•Failure rate：失败频率•Fault：缺陷•Fault density：缺陷密度•Fault Detection Percentage (FDP) ：缺陷发现率•Fault masking：缺陷屏蔽•Fault tolerance：缺陷容限•Fault tree analysis：缺陷树分析•Feature：特征•Field testing：现场测试•Finite state machine：有限状态机•Finite state testing：有限状态测试•Formal review：正式评审•Frozen test basis：测试基线•Function Point Analysis (FPA) ：功能点分析•Functional integration：功能集成•Functional requirement：功能需求•Functional test design technique：功能测试设计技术•Functional testing：功能测试•Functionality：功能性•Functionality testing：功能性测试G•glass box testing：白盒测试H•Heuristic evaluation：启发式评估•High level test case：概要测试用例•Horizontal traceability：水平跟踪领测国际科技（北京）有限公司领测软件测试网/I•Impact analysis：影响分析•Incremental development model：增量开发模型•Incremental testing：增量测试•Incident：事件•Incident management：事件管理•Incident management tool：事件管理工具•Incident report：事件报告•Independence：独立•Infeasible path：不可行路径•Informal review：非正式评审•Input：输入•Input domain：输入范围•Input value：输入值•Inspection：审查•Inspection leader：审查组织者•Inspector：审查人员•Installability：可安装性•Installability testing：可安装性测试•Installation guide：安装指南•Installation wizard：安装向导•Instrumentation：插装•Instrumenter：插装工具•Intake test：入口测试•Integration：集成•Integration testing：集成测试•Integration testing in the large：大范围集成测试•Integration testing in the small：小范围集成测试•Interface testing：接口测试•Interoperability：互通性•Interoperability testing：互通性测试•Invalid testing：无效性测试•Isolation testing：隔离测试•Item transmittal report：版本发布报告•Iterative development model：迭代开发模型K•Key performance indicator：关键绩效指标领测国际科技（北京）有限公司领测软件测试网/ •Keyword driven testing：关键字驱动测试L•Learnability：易学性•Level test plan：等级测试计划•Link testing：组件集成测试•Load testing：负载测试•Logic-coverage testing：逻辑覆盖测试•Logic-driven testing：逻辑驱动测试•Logical test case：逻辑测试用例•Low level test case：详细测试用例M•Maintenance：维护•Maintenance testing：维护测试•Maintainability：可维护性•Maintainability testing：可维护性测试•Management review：管理评审•Master test plan：综合测试计划•Maturity：成熟度•Measure：度量•Measurement：度量•Measurement scale：度量粒度•Memory leak：内存泄漏•Metric：度量•Migration testing：移植测试•Milestone：里程碑•Mistake：错误•Moderator：仲裁员•Modified condition decision coverage：改进的条件判定覆盖率•Modified condition decision testing：改进的条件判定测试•Modified multiple condition coverage：改进的多重条件判定覆盖率•Modified multiple condition testing：改进的多重条件判定测试•Module：模块•Module testing：模块测试•Monitor：监视器•Multiple condition：多重条件•Multiple condition coverage：多重条件覆盖率领测国际科技（北京）有限公司领测软件测试网/•Multiple condition testing：多重条件测试•Mutation analysis：变化分析•Mutation testing：变化测试N•N-switch coverage：N 切换覆盖率•N-switch testing：N 切换测试•Negative testing：负面测试•Non-conformity：不一致•Non-functional requirement：非功能需求•Non-functional testing：非功能测试•Non-functional test design techniques：非功能测试设计技术O•Off-the-shelf software：离岸软件•Operability：可操作性•Operational environment：操作环境•Operational profile testing：运行剖面测试•Operational testing：操作测试•Oracle：标准•Outcome：输出/结果•Output：输出•Output domain：输出范围•Output value：输出值P•Pair programming：结队编程•Pair testing：结队测试•Partition testing：分割测试•Pass：通过•Pass/fail criteria：通过/失败标准•Path：路径•Path coverage：路径覆盖•Path sensitizing：路径敏感性•Path testing：路径测试领测国际科技（北京）有限公司领测软件测试网/ •Peer review：同行评审•Performance：性能•Performance indicator：绩效指标•Performance testing：性能测试•Performance testing tool：性能测试工具•Phase test plan：阶段测试计划•Portability：可移植性•Portability testing：移植性测试•Postcondition：结果条件•Post-execution comparison：运行后比较•Precondition：初始条件•Predicted outcome：预期结果•Pretest：预测试•Priority：优先级•Probe effect：检测成本•Problem management：问题管理•Problem report：问题报告•Process：流程•Process cycle test：处理周期测试•Product risk：产品风险•Project：项目•Project risk：项目风险•Program instrumenter：编程工具•Program testing：程序测试•Project test plan：项目测试计划•Pseudo-random：伪随机Q•Quality：质量•Quality assurance：质量保证•Quality attribute：质量属性•Quality characteristic：质量特征•Quality management：质量管理领测国际科技（北京）有限公司领测软件测试网/ R•Random testing：随机测试•Record/playback tool：记录/回放工具•Recoverability：可复原性•Recoverability testing：可复原性测试•Recovery testing：可复原性测试•Regression testing：回归测试•Regulation testing：一致性测试•Release note：版本说明•Reliability：可靠性•Reliability testing：可靠性测试•Replaceability：可替换性•Requirement：需求•Requirements-based testing：基于需求的测试•Requirements management tool：需求管理工具•Requirements phase：需求阶段•Resource utilization：资源利用•Resource utilization testing：资源利用测试•Result：结果•Resumption criteria：继续测试标准•Re-testing：再测试•Review：评审•Reviewer：评审人员•Review tool：评审工具•Risk：风险•Risk analysis：风险分析•Risk-based testing：基于风险的测试•Risk control：风险控制•Risk identification：风险识别•Risk management：风险管理•Risk mitigation：风险消减•Robustness：健壮性•Robustness testing：健壮性测试•Root cause：根本原因S•Safety：安全领测国际科技（北京）有限公司领测软件测试网/ •Safety testing：安全性测试•Sanity test：健全测试•Scalability：可测量性•Scalability testing：可测量性测试•Scenario testing：情景测试•Scribe：记录员•Scripting language：脚本语言•Security：安全性•Security testing：安全性测试•Serviceability testing：可维护性测试•Severity：严重性•Simulation：仿真•Simulator：仿真程序、仿真器•Site acceptance testing：定点验收测试•Smoke test：冒烟测试•Software：软件•Software feature：软件功能•Software quality：软件质量•Software quality characteristic：软件质量特征•Software test incident：软件测试事件•Software test incident report：软件测试事件报告•Software Usability Measurement Inventory (SUMI) ：软件可用性调查问卷•Source statement：源语句•Specification：规格说明•Specification-based testing：基于规格说明的测试•Specification-based test design technique：基于规格说明的测试设计技术•Specified input：特定输入•Stability：稳定性•Standard software：标准软件•Standards testing：标准测试•State diagram：状态图•State table：状态表•State transition：状态迁移•State transition testing：状态迁移测试•Statement：语句•Statement coverage：语句覆盖•Statement testing：语句测试•Static analysis：静态分析•Static analysis tool：静态分析工具•Static analyzer：静态分析工具•Static code analysis：静态代码分析•Static code analyzer：静态代码分析工具•Static testing：静态测试•Statistical testing：统计测试领测国际科技（北京）有限公司领测软件测试网/ •Status accounting：状态统计•Storage：资源利用•Storage testing：资源利用测试•Stress testing：压力测试•Structure-based techniques：基于结构的技术•Structural coverage：结构覆盖•Structural test design technique：结构测试设计技术•Structural testing：基于结构的测试•Structured walkthrough：面向结构的走查•Stub: 桩•Subpath: 子路径•Suitability: 符合性•Suspension criteria: 暂停标准•Syntax testing: 语法测试•System:系统•System integration testing：系统集成测试•System testing：系统测试T•Technical review：技术评审•Test：测试•Test approach：测试方法•Test automation：测试自动化•Test basis：测试基础•Test bed：测试环境•Test case：测试用例•Test case design technique：测试用例设计技术•Test case specification：测试用例规格说明•Test case suite：测试用例套•Test charter：测试宪章•Test closure：测试结束•Test comparator：测试比较工具•Test comparison：测试比较•Test completion criteria：测试比较标准•Test condition：测试条件•Test control：测试控制•Test coverage：测试覆盖率•Test cycle：测试周期•Test data：测试数据•Test data preparation tool：测试数据准备工具领测国际科技（北京）有限公司领测软件测试网/ •Test design：测试设计•Test design specification：测试设计规格说明•Test design technique：测试设计技术•Test design tool: 测试设计工具•Test driver: 测试驱动程序•Test driven development: 测试驱动开发•Test environment: 测试环境•Test evaluation report: 测试评估报告•Test execution: 测试执行•Test execution automation: 测试执行自动化•Test execution phase: 测试执行阶段•Test execution schedule: 测试执行进度表•Test execution technique: 测试执行技术•Test execution tool: 测试执行工具•Test fail: 测试失败•Test generator: 测试生成工具•Test leader:测试负责人•Test harness：测试组件•Test incident：测试事件•Test incident report：测试事件报告•Test infrastructure：测试基础组织•Test input：测试输入•Test item：测试项•Test item transmittal report：测试项移交报告•Test level：测试等级•Test log：测试日志•Test logging：测试记录•Test manager：测试经理•Test management：测试管理•Test management tool：测试管理工具•Test Maturity Model (TMM) ：测试成熟度模型•Test monitoring：测试跟踪•Test object：测试对象•Test objective：测试目的•Test oracle：测试标准•Test outcome：测试结果•Test pass：测试通过•Test performance indicator：测试绩效指标•Test phase：测试阶段•Test plan：测试计划•Test planning：测试计划•Test policy：测试方针•Test Point Analysis (TPA) ：测试点分析•Test procedure：测试过程领测国际科技（北京）有限公司领测软件测试网/ •Test procedure specification：测试过程规格说明•Test process：测试流程•Test Process Improvement (TPI) ：测试流程改进•Test record：测试记录•Test recording：测试记录•Test reproduceability：测试可重现性•Test report：测试报告•Test requirement：测试需求•Test run：测试运行•Test run log：测试运行日志•Test result：测试结果•Test scenario：测试场景•Test script：测试脚本•Test set：测试集•Test situation：测试条件•Test specification：测试规格说明•Test specification technique：测试规格说明技术•Test stage：测试阶段•Test strategy：测试策略•Test suite：测试套•Test summary report：测试总结报告•Test target：测试目标•Test tool：测试工具•Test type：测试类型•Testability：可测试性•Testability review：可测试性评审•Testable requirements：需求可测试性•Tester：测试人员•Testware：测试组件•Thread testing：组件集成测试•Time behavior：性能•Top-down testing：自顶向下的测试•Traceability：可跟踪性U•Understandability：易懂性•Unit：单元•unit testing：单元测试•Unreachable code：执行不到的代码领测国际科技（北京）有限公司领测软件测试网/ •Usability：易用性•Usability testing：易用性测试•Use case：用户用例•Use case testing：用户用例测试•User acceptance testing：用户验收测试•User scenario testing：用户场景测试•User test：用户测试V•V -model：V 模式•Variable：变量•Verification：验证•Vertical traceability：垂直可跟踪性•Version control：版本控制•Volume testing：容量测试W•Walkthrough：走查•White-box test design technique：白盒测试设计技术•White-box testing：白盒测试•Wide Band Delphi：Delphi 估计方法。

用例建模指南

IBM中国有限公司软件部Rational中国区技术销售经理2004 年12 月用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。

用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。

用例的使用在RUP中被推崇备至，整个RUP流程都被称作是"用例驱动"(Use-Case Driven)的，各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件，用例模型奠定了整个系统软件开发的基础。

请点击文章顶部或底部的讨论，参与论坛讨论，与其他读者分享您对本文的看法。

1. 什么是用例？在介始用例方法之前，我们首先来看一下传统的需求表述方式-"软件需求规约"(Software Requirement Specification)。

传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。

一个典型的软件需求规约可能具有以下形式：采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。

由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。

在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。

功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。

所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

软件需求规约:
用于<子系统或特性> Software Requirements Specification
项目名称：项目名称
摘要：
相关文档：
修改记录：
目录
1简介 (3)
1.1目的 (3)
1.2范围 (3)
1.3定义、首字母缩写词和缩略语 (3)
1.4参考资料 (3)
1.5概述 (4)
2整体说明 (4)
2.1用例模型调查 (4)
2.2假设与依赖关系 (4)
3具体需求 (4)
3.1用例报告 (4)
3.2补充需求 (5)
4支持信息 (5)
1简介
[软件需求规约(SRS)的简介应提供整个文档的概述。

它应包括软件需求规约的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。

]
[软件需求规约记录对系统或系统的一部分的完整软件需求。

以下是一个典型的软件需求规约概述，用于涉及用例建模的项目。

此工件由一个包组成，该包包含用例模型的用例、适合的补充规约以及其他支持信息。

有些软件需求规约没有采用用例建模，它在一个文档中记录了所有需求，而适用的部分可从补充规约（此后将不再需要）中插入，这种软件需求规约的模板请参见rup_srs.dot。

]
[软件需求规约可能会有许多不同的组织方式。

有关以上两种组织方式的进一步阐述以及软件需求规约的其他组织方式，请参见[IEEE93]。

]
1.1 目的
[阐明此软件需求规约的目的。

]软件需求规约应详细地说明所确定的应用程序或子系统的外部行为。

它还要说明非功能性需求、设计约束以及提供完整、综合的软件需求说明所需的其他因素。

]
1.2 范围
[简要说明此软件需求规约适用的软件应用程序、特性或其他子系统分组、与其相关的用例模型，以及受到此文档影响的任何其他事物。

]
1.3 定义、首字母缩写词和缩略语
[本小节应提供正确解释此软件需求规约所需的全部术语的定义、首字母缩写词和缩略语。

这些信息可以通过引用项目词汇表来提供。

]
1.4 参考资料
[本小节应完整地列出此软件需求规约中其他部分所引用的所有文档。

每个文档应标有标题、报告号（如果适用）、日期和出版单位。

列出可从中获取这些参考资料的来源。

这些信息可以通过引用附录或其他文档来提供。

]
1.5 概述
[此小节应说明软件需求规约其他部分所包含的内容，并解释文档的组织方式。

]
2整体说明
[软件需求规约的这一节应说明影响产品及其需求的一般因素。

本节并不列出具体的需求，而只是提供在第3 节中详述的各种需求的背景，以使这些需求便于理解。

其中包括产品总体效果、产品功能、用户特征、约束、假设与依赖关系、需求子集等内容。

]
2.1 用例模型调查
[当采用用例建模时，此节将概述适用于该子系统或特性的用例模型或用例模型的子集。

其中包括所有用例和主角的名称列表及简要说明，以及适用的各种图和关系。

请参见用例模型调查报告，它在此处可用作附件。

]
2.2 假设与依赖关系
[本节说明所有重要的技术可行性假设、子系统或构件可用性假设，或者可作为此软件需求规约所述软件可行性的基础的其他与项目有关的假设。

]
3具体需求
软件需求规约的这一节应包括所有的软件需求，其详细程度应使设计人员能够设计出可以满足这些需求的系统，并使测试人员能够测试该系统是否满足这些需求。

当利用用例建模时，这些需求在用例和适用的补充规约中记录。

如果没有利用用例建模，则可以将补充规约的概要直接插入此节。

]
3.1 用例报告
[在用例建模过程中，用例通常会定义系统的大部分功能性需求，以及一些非功能性需求。

对于以上用例模型中的每个用例或其子集，都需在此节中引用或附上用例报告。

务必要明确地标明每一需求。

]
3.2 补充需求
[补充规约记录未包含在用例中的需求。

应在此处列出补充规约中适用于该子系统或特性的具体需求，并对这些需求加以改进，以足够详细地说明该子系统或特性。

这些需求可以直接记录在此文档中，也可单独保存为补充规约，补充规约在此处可用作附件。

务必要明确地标明每一需求。

]
4支持信息
[支持信息用于使软件需求规约更易于使用。

它包括：
•目录
•索引
•附录
其中可以包括用例示意板或用户界面原型。

如果包含附录，软件需求规约应明确指出是否将附录当作需求的一部分。

]。