软件需求分析文档模板(2020年整理).pdf
需求分析文档模板
1.4 术语列出本报告中用到的专门术语的定义。
2. 任务概述2.1 目标叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。
解释被开发软件与其他有关软件之间的关系。
如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。
如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
2.2 系统（或用户）的特点如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。
说明本软件预期使用频度；如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。
这些是软件设计工作的重要约束。
3. 假定和约束列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
4. 需求规定4.1 软件功能说明逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。
4.2 对功能的一般性规定本处仅列出对开发产品的所有功能（或一部分）的共同要求，如要求界面格式统一，统一的错误声音提示，要求有在线帮助等。
4.3 对性能的一般性规定4.3.1 精度说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。
4.3.2 时间特性要求说明对于该系统的时间特性要求。
4.3.3 灵活性说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。
4.4 输入输出要求解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。
对系统的数据输出及必须标明的控制输出量进行解释并举例。
4.5数据管理能力要求（针对软件系统）说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储作出估算。
软件需求分析报告模板
软件需求分析报告文档模板1. 引言引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。
1.1 编写目的说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。
通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和（或）发行版本号，从而对该软件产品进行准确的定义。
如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统。
1.2 项目风险具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括：●任务提出者；●软件开发者；●产品使用者。
1.3 文档约定描述编写文档时所采用的标准（如果有标准的话），或者各种排版约定。
排版约定应该包括：●正文风格；●提示方式；●重要符号；也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。
1.4 预期读者和阅读建议列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括：●用户；●开发人员；●项目经理；●营销人员；●测试人员；●文档编写入员。
并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。
1.5 产品范围说明该软件产品及其开发目的的简短描述，包括利益和目标。
把软件产品开发与企业目标，或者业务策略相联系。
描述产品范围时需注意，可以参考项目视图和范围文档，但是不能将其内容复制到这里。
1.6 参考文献列举编写软件产品需求分析报告时所用到的参考文献及资料，可能包括：●本项目的合同书；●上级机关有关本项目的批文；●本项目已经批准的计划任务书；●用户界面风格指导；●开发本项目时所要用到的标淮；●系统规格需求说明；●使用实例文档；●属于本项目的其它己发表文件；●本软件产品需求分析报告中所引用的文件、资料；●相关软件产品需求分析报告；为了方便读者查阅，所有参考资料应该按一定顺序排列。
软件工程文档模板(完整规范版)(最新整理)
目录
1. 范围 .................................................................................................................................................1
2.3.1 软件项目实施过程总体要求 .........................................................................................2 2.3.2 软件项目实施变更要求 .................................................................................................2 2.3.3 软件项目实施里程碑控制 .............................................................................................2
3.6 软件的交付准备.....................................................................................................................6
ILeabharlann 3.6.1 交付清单 .........................................................................................................................6 3.7 软件的鉴定验收.....................................................................................................................7
软件需求分析报告模板
软件需求分析报告文档模板1. 引言引言是对这份软件产品需求分析报告的概览,是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。
1.1 编写目的说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。
通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格,包括修正和（或）发行版本号，从而对该软件产品进行准确的定义。
如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统.1.2 项目风险具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括：●任务提出者；●软件开发者；●产品使用者。
1.3 文档约定描述编写文档时所采用的标准（如果有标准的话)，或者各种排版约定。
排版约定应该包括:●正文风格;●提示方式；●重要符号；也应该说明高层次需求是否可以被其所有细化的需求所继承,或者每个需求陈述是否都有其自己的优先级。
1.4 预期读者和阅读建议列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括：●用户；●开发人员；●项目经理；●营销人员；●测试人员；●文档编写入员。
并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议.1.5 产品范围说明该软件产品及其开发目的的简短描述,包括利益和目标。
把软件产品开发与企业目标，或者业务策略相联系.描述产品范围时需注意,可以参考项目视图和范围文档，但是不能将其内容复制到这里。
1.6 参考文献列举编写软件产品需求分析报告时所用到的参考文献及资料,可能包括：●本项目的合同书；●上级机关有关本项目的批文；●本项目已经批准的计划任务书；●用户界面风格指导；●开发本项目时所要用到的标淮;●系统规格需求说明；●使用实例文档;●属于本项目的其它己发表文件;●本软件产品需求分析报告中所引用的文件、资料；●相关软件产品需求分析报告；为了方便读者查阅,所有参考资料应该按一定顺序排列。
软件工程文档模板（完整规范版）
软件⼯程⽂档模板（完整规范版）软件⼯程⽂档模板⽬录1.范围 (1)2.总体要求 (1)2.1总体功能要求 (1)2.2软件开发平台要求 (1)2.3软件项⽬地开发实施过程管理要求 (2)2.3.1软件项⽬实施过程总体要求 (2)2.3.2软件项⽬实施变更要求 (2)2.3.3软件项⽬实施⾥程碑控制 (2)3.软件开发 (3)3.1软件地需求分析 (3)3.1.1需求分析 (3)3.1.2需求分析报吿地编制者 (4)3.1.3需求报吿评审 (4)3.1.4需求报吿格式 (4)3.2软件地概要设计 (4)3.2.1概要设计 (4)3.2.2编写概要设计地要求 (4)3.2.3概要设计报吿地编写者 (4)3.2.4概要设计合需求分析、详细设计之间地关系合区别 (4)3.2.5概要设计地评审 (4)3.2.6 概要设计格式 (4)3.3软件地详细设计 (5)3.3.1详细设计 (5)3.3.2特例 (5)3.3.3详细设计地要求 (5)3.3.4数据库设计 (5)3.3.5详细设计地评审 (5)3.3.6详细设计格式 (5)3.4软件地编码 (5)3.4.1软件编码 (5)3.4.2软件编码地要求 (5)3.4.3编码地评审 (6)3.4.4编程规范及要求 (6)3.5软件地测试 (6)3.5.1软件测试 (6)3.5.2测试计划 (6)3.6软件地交付准备 (6)361交付清单 (6)3.7软件地鉴定验收 (7)3.7.1软件地鉴定验收 (7)3.7.2验收△员 (7)3.7.3验收具体内容 (7)3.7.4 软件验收测试⼤纲 (7)3.8培训 (7)3.8.1系统应⽤培训 (7)3.8.2系统管理地培训（可选） (8)附录A 软件需求分析报吿⽂档模板 (9)附录b 软件概要设计报吿⽂档模板 (21)附录C 软件详细设计报吿⽂档模板 (33)附录D软件数据库设计报吿⽂档模板 (43)附录E 软件测试（验收）⼤纲..................................... 错误！未定义书签。
软件工程需求分析文档模板
软件开发中心Software Development Center需求分析报告项目名称<项目名称>文档类别<文档类别>文档编号<文档编号>版本<V1.0>密级<秘密>二〇一三年三月二十七日版本修订记录目录1引言 (4)1.1编写目的 (4)1.2背景 (4)1.3术语定义 (5)1.4参考资料 (5)2系统概述 (5)2.1系统功能框架 (5)2.2运行环境 (5)2.3开发环境 (6)2.4用户特点 (6)2.5条件与限制 (6)3功能描述 (7)3.1功能分解 (7)3.2各功能描述 (7)4数据描述 (8)5性能描述 (9)6接口描述 (10)7其他要求 (10)8未尽事宜 (11)附件 (11)1引言1.1 编写目的{简要说明编写这份需求分析报告的目的，指出预期的读者。
本软件需求分析报告的编写目的是为了提供一个由用户（或委托者）和开发者双方共同确定的开发系统的业务需求目标，并对所实现的软件功能做全面的规格描述。
同时，在用户业务需求的基础上，经过需求分析和数据整理，以向整个开发期提供关于软件系统的业务和数据的技术信息和整体描述，成为软件开发的技术基础，也作为系统设计和实现的目标及验收依据。
本软件需求分析报告的适用读者，一般为：软件客户、软件需求分析人员、软件设计及开发者和相关的测试人员}1.2 背景{1.说明待开发的软件系统的名称2.列出本项目的任务委托单位、开发单位、协作单位、用户单位3.说明项目背景，叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。
如果本次开发的软件系统是一个更大的系统的一个组成部分，则要说明该更大系统的组成和介绍本系统与其它相关系统的关系和接口部分4.保密说明：本项为可选项，只有当用户强烈要求对其业务内容进行保密，不允许被复制、使用和扩散到其企业范围之外时，才要对此项进行专门的保密说明5.版权说明：本项为可选项，若有必要，才要作有关的描述。
软件需求分析报告完整版
软件需求分析报告模板(完整版)目录1. 范围 12. 总体要求 12.1总体功能要求 (1)2.2软件开发平台要求 (1)2.3软件项目的开发实施过程管理要求 (2)2.3.1 软件项目实施过程总体要求 (2)2.3.2 软件项目实施变更要求 (2)2.3.3 软件项目实施里程碑控制 (2)3. 软件开发 33.1软件的需求分析 (3)3.1.1 需求分析 (3)3.1.2 需求分析报告的编制者 (4)3.1.3 需求报告评审 (4)3.1.4 需求报告格式 (4)3.2软件的概要设计 (4)3.2.1 概要设计 (4)3.2.2 编写概要设计的要求 (4)3.2.3 概要设计报告的编写者 (4)3.2.4 概要设计和需求分析、详细设计之间的关系和区别 (4)3.2.5 概要设计的评审 (4)3.2.6 概要设计格式 (4)3.3软件的详细设计 (5)3.3.1 详细设计 (5)3.3.2 特例 (5)3.3.3 详细设计的要求 (5)3.3.4 数据库设计 (5)3.3.5 详细设计的评审 (5)3.3.6 详细设计格式 (5)3.4软件的编码 (5)3.4.1 软件编码 (5)3.4.2 软件编码的要求 (5)3.4.3 编码的评审 (6)3.4.4 编程规范及要求 (6)3.5软件的测试 (6)3.5.1 软件测试 (6)3.5.2 测试计划 (6)3.6软件的交付准备 (6)3.6.1 交付清单 (6)3.7软件的鉴定验收 (7)3.7.1 软件的鉴定验收 (7)3.7.2 验收人员 (7)3.7.3 验收具体内容 (7)3.7.4 软件验收测试大纲 (7)3.8培训 (7)3.8.1 系统应用培训 (7)3.8.2 系统管理的培训（可选） (8)附录A 软件需求分析报告文档模板9附录B 软件概要设计报告文档模板21附录C 软件详细设计报告文档模板33附录D 软件数据库设计报告文档模板43附录E 软件测试(验收)大纲错误!未定义书签。
编写软件需求分析文档模板
ＸＸ信息管理系统需求说明书X X科技有限公司目录1前言 (1)1．1目的 (1)1．2范围 (1)1．3定义、缩写词、略语 (1)1．4参考资料 (1)2项目概述 (2)2．1产品描述 (2)2．2产品功能 (2)2．3用户特点 (2)2．4一般约束 (2)2．5假设和依据 (3)3具体需求 (3)3．1功能需求 (3)3．1．1功能需求1 (3)3．1．2功能需求2 (4)3．2外部接口需求 (4)3．2．1用户接口 (4)3．2．2硬件接口 (4)3．2．3软件接口 (4)3．2．4通信接口 (4)3．3性能需求 (4)3．4设计约束 (5)3．4．1其他标准的约束 (5)3．4．2硬件的限制 (5)3．5属性 (5)3．5．1可用性 (5)3．5．2安全性 (5)3．5．3可维护性 (5)3．5．4可转移/转换性 (5)3．5．5警告 (6)3．6其他需求 (6)3．6．1数据库 (6)3．6．2操作 (6)3．6．3场合适应性 (6)ＸＸ信息管理系统需求说明书1前言本章提供整个SRS综述。
1．1 目的在这一条包括下列内容：a.描述实际SRS的目的；b.说明SRS所预期的读者。
1．2 范围a.用一个名字标识被生产的软件产品。
比如：×××数据库系统，报表生成程序等等；b.说明软件产品将干什么，如果需要的话，还要说明软件产品不干什么；c.描述所说明的软件的应用。
应当：(1)尽可能精确地描述所有相关的利闪、目的、以及最终目标。
(2)如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。
1．3 定义、缩写词、略语本条中必须提供全部需求的术语、缩写词及略语的定义，以便对SRS进行适当的解释。
这些信息可以由SRS的附录提供。
也可以参考其他的文件。
1．4 参考资料本条应包括：a.在SRS中各处参照的文件的全部清单，如经核准的计划任务书，上级机关批文、合同等；b.列出其他参考资料，如属本项目的其他已发表的文件和主要文献等。
需求分析文档模板Requirements-Specification-Template
需求分析文档模板Requirements-Specification-Template[YourProject] Requirements SpecificationVersion 1.0February 21, 2020Use this Requirements Specification template to document the requirements for your product or service, including priority and approval. Tailor the specification to suit your project, organizing the applicable sections in a way that works best, and use the checklist to record the decisions about what is applicable and what isn't.The format of the requirements depends on what works best for your project.This document contains instructions and examples which are for the benefit of the person writing the document and should be removed before the document is finalized.To regenerate the TOC, select all (CTL-A) and press F9.c:\iknow\docshare\data\cur_work\1114012273.doc February 21, 2020 Page 2 o f 17Table of Contents1.EXECUTIVE SUMMARY (4)1.1P ROJECT O VERVIEW (4)1.2P URPOSE AND S COPE OF THIS S PECIFICATION (4)2.PRODUCT/SERVICE DESCRIPTION (4)2.1P RODUCT C ONTEXT (4)2.2U SER C HARACTERISTICS (4)2.3A SSUMPTIONS (4)2.4C ONSTRAINTS (4)2.5D EPENDENCIES (5)3.REQUIREMENTS (5)3.1F UNCTIONAL R EQUIREMENTS (6)3.2U SER I NTERFACE R EQUIREMENTS (7)3.3U SABILITY (7)3.4P ERFORMANCE (7)3.4.1Capacity (7)3.4.2Availability (7)3.4.3Latency (7)3.5M ANAGEABILITY/M AINTAINABILITY (8)3.5.1Monitoring (8)3.5.2Maintenance (8)3.5.3Operations (8)3.6S YSTEM I NTERFACE/I NTEGRATION (8)3.6.1Network and Hardware Interfaces (8)3.6.2Systems Interfaces (8)3.7S ECURITY (9)3.7.1Protection (9)3.7.2Authorization and Authentication (9)3.8D ATA M ANAGEMENT (9)3.9S TANDARDS C OMPLIANCE (10)3.10P ORTABILITY (10)ER SCENARIOS/USE CASES (10)5.DELETED OR DEFERRED REQUIREMENTS (10)6.REQUIREMENTS CONFIRMATION/STAKEHOLDER SIGN-OFF (12)APPENDIX (13)A PPENDIX A.D EFINITIONS,A CRONYMS, AND A BBREVIATIONS (13)A PPENDIX B.R EFERENCES (13)A PPENDIX C.R EQUIREMENTS T RACEABILITY M ATRIX (13)A PPENDIX D.O RGANIZING THE R EQUIREMENTS (16)c:\iknow\docshare\data\cur_work\1114012273.doc February 21, 2020 Page 3 o f 171. Executive Summary1.1 Project OverviewDescribe this project or product and its intended audience, or provide a link or reference to the project charter.1.2 Purpose and Scope of this SpecificationDescribe the purpose of this specification and its intended audience. Include a description of what is within the scope what is outside of the scope of these specifications. For example:In scopeThis document addresses requirements related to phase 2 of Project A:•modification of Classification Processing to meet legislative mandate ABC.•modification of Labor Relations Processing to meet legislative mandate ABC.Out of ScopeThe following items in phase 3 of Project A are out of scope:•modification of Classification Processing to meet legislative mandate XYZ.•modification of Labor Relations Processing to meet legislative mandate XYZ.(Phase 3 will be considered in the development of the requirements for Phase 2, but the Phase 3 requirements will be documented separately.)2. Product/Service DescriptionIn this section, describe the general factors that affect the product and its requirements. This section should contain background information, not state specific requirements (provide the reasons why certain specific requirements are later specified).2.1 Product ContextHow does this product relate to other products? Is it independent and self-contained? Does it interface with a variety of related systems? Describe these relationships or use a diagram to show the major components of the larger system, interconnections, and external interfaces.2.2 User CharacteristicsCreate general customer profiles for each type of user who will be using the product. Profiles should include:•Student/faculty/staff/other•experience•technical expertise•other general characteristics that may influence the product2.3 AssumptionsList any assumptions that affect the requirements, for example, equipment availability, user expertise, etc. For example, a specific operating system is assumed to be available; if the operating system is not available, the Requirements Specification would then have to change accordingly.2.4 ConstraintsDescribe any items that will constrain the design options, includingc:\iknow\docshare\data\cur_work\1114012273.doc February 21, 2020 Page 4 o f 17•parallel operation with an old system•audit functions (audit trail, log files, etc.)•access, management and security•criticality of the application•system resource constraints (e.g., limits on disk space or other hardware limitations) •other design constraints (e.g., design or other standards, such as programming language or framework)2.5 DependenciesList dependencies that affect the requirements. Examples:•This new product will require a daily download of data from X,•Module X needs to be completed before this module can be built.3. Requirements•Describe all system requirements in enough detail for designers to design a system satisfying the requirements and testers to verify that the system satisfies requirements. •Organize these requirements in a way that works best for your project. See Appendix DAppendix D, Organizing the Requirements for different ways to organize theserequirements.•Describe every input into the system, every output from the system, and every function performed by the system in response to an input or in support of an output. (Specify what functions are to be performed on what data to produce what results at what location for whom.)•Each requirement should be numbered (or uniquely identifiable) and prioritized.See the sample requirements in Functional Requirements, and System Interface/Integration, as well as these example priority definitions:Priority DefinitionsThe following definitions are intended as a guideline to prioritize requirements.•Priority 1 –The requirement is a “must have” as outlined by policy/law•Priority 2 – The requirement is needed for improved processing, and the fulfillment of the requirement will create immediate benefits•Priority 3 –The requirement is a “nice to have” which may include new functionality It may be helpful to phrase the requirement in terms of its priority, e.g., "The value of the employee status sent to DIS must be either A or I" or "It would be nice if the application warned the user that the expiration date was 3 business days away". Another approach would be to group requirements by priority category.• A good requirement is:•Correct•Unambiguous (all statements have exactly one interpretation)•Complete (where TBDs are absolutely necessary, document why the information is unknown, who is responsible for resolution, and the deadline)•Consistent•Ranked for importance and/or stability•Verifiable (avoid soft descriptions like “works well”, “is user friendly”; use concrete terms and specify measurable quantities)•Modifiable (evolve the Requirements Specification only via a formal change process, preserving a complete audit trail of changes)c:\iknow\docshare\data\cur_work\1114012273.doc February 21, 2020 Page 5 o f 17•Does not specify any particular design•Traceable (cross-reference with source documents and spawned documents).3.1 Functional RequirementsIn the example below, the requirement numbering has a scheme - BR_LR_0## (BR for Business Requirement, LR for Labor Relations). For small projects simply BR-## would suffice. Keep in mind that if no prefix is used, the traceability matrix may be difficult to create (e.g., no differentiation between '02' as a business requirement vs. a test case)The following table is an example format for requirements. Choose whatever format works best for your project.For Example:c:\iknow\docshare\data\cur_work\1114012273.doc February 21, 2020 Page 6 o f 173.2 User Interface RequirementsIn addition to functions required, describe the characteristics of each interface between the product and its users (e.g., required screen formats/organization, report layouts, menu structures, error and other messages, or function keys).3.3 UsabilityInclude any specific usability requirements, for example,Learnability•The user documentation and help should be complete•The help should be context sensitive and explain how to achieve common tasks•The system should be easy to learn(See /)3.4 PerformanceSpecify static and dynamic numerical requirements placed on the system or on human interaction with the system:•Static numerical requirements may include the number of terminals to be supported, the number of simultaneous users to be supported, and the amount and type of information to be handled.•Dynamic numerical requirements may include the number of transactions and tasks and the amount of data to be processed within certain time period for both normal and peak workload conditions.All of these requirements should be stated in measurable form. For example, "95% of the transactions shall be processed in less than 1 second" rather than “an operator shall not have to wait for the transaction to complete”.3.4.1 CapacityInclude measurable capacity requirements (e.g., the number of simultaneous users to be supported, the maximum simultaneous user load, per-user memory requirements, expected application throughput)3.4.2 AvailabilityInclude specific and measurable requirements for:•Hours of operation•Level of availability required•Coverage for geographic areas•Impact of downtime on users and business operations•Impact of scheduled and unscheduled maintenance on uptime and maintenance communications procedures•reliability (e.g., acceptable mean time between failures (MTBF), or the maximum permitted number of failures per hour).3.4.3 LatencyInclude explicit latency requirements, e.g., the maximum acceptable time (or average time) for a service request.c:\iknow\docshare\data\cur_work\1114012273.doc February 21, 2020 Page 7 o f 173.5 Manageability/Maintainability3.5.1 MonitoringInclude any requirements for product or service health monitoring, failure conditions, error detection, logging, and correction.3.5.2 MaintenanceSpecify attributes of the system that relate to ease of maintenance. These requirements may relate to modularity, complexity, or interface design. Requirements should not be placed here simply because they are thought to be good design practices.3.5.3 OperationsSpecify any normal and special operations required by the user, including:•periods of interactive operations and periods of unattended operations•data processing support functions•backup and recovery operations•safety considerations and requirements•disaster recovery and business resumption3.6 System Interface/IntegrationSpecify the use of other required products (e.g., a database or operating system), and interfaces with other systems (e.g., UWHires package interfaces with PubCookie and ODS, HEPPS system interfaces with Budget system). For each interface, define the interface in terms of message format and content. For well-documented interfaces, simply provide a reference to the documentation.Outline each interface between the product and the hardware or network components of the system. This includes configuration characteristics (e.g., number of ports, instruction sets), what devices are to be supported, and protocols (e.g., signal handshake protocols).3.6.1 Network and Hardware InterfacesSpecify the logical characteristics of each interface between the product and the hardware or network components of the system. This includes configuration characteristics (e.g., number of ports, instruction sets), what devices are to be supported, and protocols (e.g., signal handshake protocols).3.6.2 Systems InterfacesExample systems interface requirements:A. System1-to-System2 InterfaceThe <external party> will create and send a fixed length text file as an email attachment toSystem2mail@ to be imported into the System2 system for payroll calculation.This file must be received on EDIT day by 4:00 PM in order to be processed in the EDIT night run.The requirements below document the file specifications, data transfer process, and specificschedule. This file is referred to as "FileName" in this document.c:\iknow\docshare\data\cur_work\1114012273.doc February 21, 2020 Page 8 o f 17File Structure and FormatA1. The FileName file is a fixed length text file.A2. The FileName file is an unformatted ASCII file (text-only).A3. The FileName file contains a batch totals record and several detail records.File Description: Batch Totals RecordA4. The batch totals record can be placed at the beginning, in the middle, or at the end of the file.A5. The batch totals record contains the following:•Record Type (value: XA)•Process Type (value: A)•Batch Number (3 digit number assigned by Payroll Dept)•Origin Code (AIG)•Total number of detail records•Total deduction amountFile Description: Detail RecordsA6. The FileName file contains a row for each record meeting xxx criteria.A7. Each row in the FileName file contains the following fields, comma-delimited and encased in double-quotes where the data includes commas or spaces:•Employee Id•Record Type•Process Date (MMDDYY)•XYG Number•Element Code•Amount•Amount Sign•Year Flag•Total Amount•Total Amt Sign3.7 Security3.7.1 ProtectionSpecify the factors that will protect the system from malicious or accidental access, modification, disclosure, destruction, or misuse. For example:•encryption•activity logging, historical data sets•restrictions on intermodule communications•data integrity checks3.7.2 Authorization and AuthenticationSpecify the Authorization and Authentication factors. Consider using standard tools such as PubCookie.3.8 Data ManagementSpecify the requirements for any information that is to be placed into a database, including •types of information used by various functions•frequency of use•data access rulesc:\iknow\docshare\data\cur_work\1114012273.doc February 21, 2020 Page 9 o f 17•data entities and relationships•integrity constraints•data retention•valid range, accuracy, and/or tolerance•units of measure•data formats•default or initial values3.9 Standards ComplianceSpecify the requirements derived from existing standards, policies, regulations, or laws (e.g., report format, data naming, accounting procedures, audit tracing). For example, this could specify the requirement for software to trace processing activity. Such traces are needed for some applications to meet minimum regulatory or financial standards. An audit trace requirement may, for example, state that all changes to a payroll database must be recorded in a trace file with before and after values.3.10 PortabilityIf portability is a requirement, specify attributes of the system that relate to the ease of porting the system to other host machines and/or operating systems. For example,•Percentage of components with host-dependent code;•Percentage of code that is host dependent;•Use of a proven portable language;•Use of a particular compiler or language subset;•Use of a particular operating system;•The need for environment-independence - the product must operate the same regardless of operating systems, networks, development or production environments.4. User Scenarios/Use CasesProvide a summary of the major functions that the product will perform. Organize the functions to be understandable to the customer or a first time reader. Include use cases and business scenarios, or provide a link to a separate document (or documents). A business scenario: •Describes a significant business need•Identifies, documents, and ranks the problem that is driving the scenario•Describes the business and technical environment that will resolve the problem•States the desired objectives•Shows the “Actors” and where they fit in the business model•Is specific, and measurable, and uses clear metrics for success5. Deleted or Deferred RequirementsIdentify any requirements that have been deleted after approval or that may be delayed until future versions of the system. For example:c:\iknow\docshare\data\cur_work\1114012273.doc February 21, 2020 Page 10 o f 176. Requirements Confirmation/Stakeholder sign-offInclude documentation of the approval or confirmation of the requirements here. For example:APPENDIXThe appendixes are not always considered part of the actual Requirements Specification and are not always necessary. They may include•Sample input/output formats, descriptions of cost analysis studies, or results of user surveys;•Supporting or background information that can help the readers of the Requirements Specification;• A description of the problems to be solved by the system;•Special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements.When appendixes are included, the Requirements Specification should explicitly state whether or not the appendixes are to be considered part of the requirements.Appendix A. Definitions, Acronyms, and AbbreviationsDefine all terms, acronyms, and abbreviations used in this document.Appendix B. ReferencesList all the documents and other materials referenced in this document.Appendix C. Requirements Traceability MatrixThe following trace matrix examples show one possible use of naming standards for deliverables (FunctionalArea-DocType-NN). The number has no other meaning than to keep the documents unique. For example, the Bargaining Unit Assignment Process Flow would be BUA-PF-01.For example (1):Appendix D. Organizing the RequirementsThis section is for information only as an aid in preparing the requirements document.Detailed requirements tend to be extensive. Give careful consideration to your organization scheme. Some examples of organization schemes are described below:By System ModeSome systems behave quite differently depending on the mode of operation. For example, a control system may have different sets of functions depending on its mode: training, normal, or emergency.By User ClassSome systems provide different sets of functions to different classes of users. For example, an elevator control system presents different capabilities to passengers, maintenance workers, and fire fighters.By ObjectsObjects are real-world entities that have a counterpart within the system. For example, in a patient monitoring system, objects include patients, sensors, nurses, rooms, physicians, medicines, etc. Associated with each object is a set of attributes (of that object) and functions (performed by that object). These functions are also called services, methods, or processes. Note that sets of objects may share attributes and services. These are grouped together as classes.By FeatureA feature is an externally desired service by the system that may require a sequence of inputs to affect the desired result. For example, in a telephone system, features include local call, call forwarding, and conference call. Each feature is generally described in a sequence ofstimulus-response pairs, and may include validity checks on inputs, exact sequencing of operations, responses to abnormal situations, including error handling and recovery, effects of parameters, relationships of inputs to outputs, including input/output sequences and formulas for input to output.By StimulusSome systems can be best organized by describing their functions in terms of stimuli. For example, the functions of an automatic aircraft landing system may be organized into sections for loss of power, wind shear, sudden change in roll, vertical velocity excessive, etc.By ResponseSome systems can be best organized by describing all the functions in support of the generation of a response. For example, the functions of a personnel system may be organized into sections corresponding to all functions associated with generating paychecks, all functions associated with generating a current list of employees, etc.By Functional HierarchyWhen none of the above organizational schemes prove helpful, the overall functionality can be organized into a hierarchy of functions organized by common inputs, common outputs, or common internal data access. Data flow diagrams and data dictionaries can be used to show the relationships between and among the functions and data.Additional CommentsWhenever a new Requirements Specification is contemplated, more than one of the organizational techniques given above may be appropriate. In such cases, organize the specific requirements for multiple hierarchies tailored to the specific needs of the system under specification.There are many notations, methods, and automated support tools available to aid in the documentation of requirements. For the most part, their usefulness is a function of organization. For example, when organizing by mode, finite state machines or state charts may prove helpful; when organizing by object, object-oriented analysis may prove helpful; when organizing by feature, stimulus-response sequences may prove helpful; and when organizing by functional hierarchy, data flow diagrams and data dictionaries may prove helpful.。
需求分析报告参考
需求分析报告篇一：软件需求分析报告模板(完好版)软件需求分析报告模板(完好版)目录1. 范围12. 总体要求12.1 总体功能要求 (1)2.2 软件开发平台要求 (1)2.3 软件工程的开发施行过程治理要求 (2)2.3.1 软件工程施行过程总体要求 (2)2.3.2 软件工程施行变更要求 (2)2.3.3 软件工程施行里程碑操纵 (2)3. 软件开发33.1 软件的需求分析 (3)3.1.1 需求分析 (3)3.1.2 需求分析报告的编制者 (4)3.1.3 需求报告评审 (4)3.1.4 需求报告格式 (4)3.2 软件的概要 (4)3.2.1 概要设计 (4)3.2.2 编写概要设计的要求 (4)3.2.3 概要设计报告的编写者 (4)3.2.4 概要设计和需求分析、详细设计之间的关系和区别 (4)3.2.5 概要设计的评审 (4)3.2.6 概要设计格式 (4)3.3 软件的详细设计 (5)3.3.1 详细设计 (5)3.3.2 特例 (5)3.3.3 详细设计的要求 (5)3.3.4 数据库设计 (5)3.3.5 详细设计的评审 (5)3.3.6 详细设计格式 (5)3.4 软件的编码 (5)3.4.1 软件编码 (5)3.4.2 软件编码的要求 (5)3.4.3 编码的评审 (6)3.4.4 编程标准及要求 (6)3.5 软件的测试 (6)3.5.1 软件测试 (6)3.5.2 测试打算 (6)3.6 软件的交付预备 (6)3.6.1 交付清单 (6)3.7 软件的鉴定验收 (7)3.7.1 软件的鉴定验收 (7)3.7.2 验收人员 (7)3.7.3 验收详细内容 (7)3.7.4 软件验收测试大纲 (7)3.8 培训 (7)3.8.1 系统应用培训 (7)3.8.2 系统治理的培训（可选） (8)附录A 软件需求分析报告文档模板9附录B 软件概要设计报告文档模板21附录C 软件详细设计报告文档模板33附录D 软件数据库设计报告文档模板43附录E 软件测试(验收)大纲错误！未定义书签。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
3. 需求规定
3.1. 软件功能说明 列出本系统中所有软件功能子系统和功能。如果子系统比较大，每个子系统分别编 写《软件功能规格说明书》，在本处列出编号和名称。 功能说明应包含以下几部分内容 3.1.1 软件功能列表 3.1.2 主要业务流程分析 3.1.3 软件部署结构分析
2. 假定和约束.....................................................................................................................3 3. 需求规定.........................................................................................................................3
如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同 之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度；
如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、 维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工 作的重要约束。
2. 假定和约束
项目编号：
（项目名称）
需求分析报告文件编号：Βιβλιοθήκη 编制： 日期：审核： 日期：
生效日期： 年 月 日 批准： 日期：
同方智能卡产品公司研发中心
1
文件状态： [ ] 草稿 [ ] 正式发布 [ ] 正在修改
文件标识： 当前版本： 作 者： 完成日期：
2
目录
1. 任务概述.........................................................................................................................3 1.1. 目标 ...................................................................................................................3 1.2. 系统（或用户）的特点 ....................................................................................3
3.1. 软件功能说明....................................................................................................3 3.2. 对功能的一般性规定 ........................................................................................3 3.3. 对性能的一般性规定 ........................................................................................4 3.4. 其他专门要求....................................................................................................4 3.5. 对安全性的要求................................................................................................4 4. 运行环境规定 .................................................................................................................4 4.1. 设备及分布 .......................................................................................................4 4.2. 支撑软件 ...........................................................................................................4 4.3. 接口 ...................................................................................................................4 4.4. 程序运行方式....................................................................................................5 5. 尚需解决的问题 .............................................................................................................5
2
1. 任务概述
1.1. 目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关
该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软 件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产 品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成 部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各 部分的联系和接口。 1.2.系统（或用户）的特点