Ashark
范文一：软件需求分析总结范文
? ? ? ? ?软件需求?分析总结?范文
? 1.? 引言 ? 引言是?对这份软?件产品需?求分析报?告的概览?，是为了?帮助阅读?者了解这?份文档是?如何编写?的，并且?应该如何?阅读、理?解和解释?这份文档?。
?
? 1.?1 编写?目的 ?说明这份?软件产品?需求分析?报告是为?哪个软件?产品编写?的，开发?这个软件?产品意义?、作用、?以及最终?要达到的?意图。通?过这份软?件产品需?求分析报?告详尽说?明了该软?件产品的?需求规格?，包括修?正和(或?)发行版?本号，从?而对该软?件产品进?行准确的?定义。 ?
? 如果这?份软件产?品需求分?析报告只?与整个系?统的某一?部分有关?系，那么?只定义软?件产品需?求分析报?告中说明?的那个部?分或子系?统。
? ?
1?.2 项?目风险 ? 具体说?明本软件?开发项目?的全部风?险承担者?，以及各?自在本阶?段所需要?承担的主?要风险，?首要风险?承担者包?括:
? ?? 任务?提出者;? ? ?软件开发?者; ?? 产品?使用者。?
?
? 1.3? 文档约?定 描?述编写文?档时所采?用的标准?(如果有?标准的话?)，或者?各种排版?约定。排?版约定应?该包括:?
? ? ?正文风格?; ?? 提示方?式; ?? 重要?符号; ? 也应该?说明高层?次需求是?否可以被?其所有细?化的需求?所继承，?或者每个?需求陈述?是否都有?其自己的?优先级。?
?
? 1.4? 预期读?者和阅读?建议 ?列举本软?件产品需?求分析报?告所针对?的各种不?同的预期?读者，例?如，可能?包括:
? ? ? 用?户; ?? 开发?人员; ? ? 项?目经理;? ? ?营销人员?; ?? 测试人?员; ?? 文档?编写入员?。WwW?.Yba?sk.C?Om ?并且描述?了文档中?，其余部?分的内容?及其组织?结构，并?且针对每?一类读者?提出最适?合的文档?阅读建议?。
?
? 1.?5 产品?范围 ?说明该软?件产品及?其开发目?的的简短?描述，包?括利益和?目标。把?软件产品?开发与企?业目标，?或者业务?策略相联?系。
? ?描述产品?范围时需?注意，可?以参考项?目视图和?范围文档?，但是不?能将其内?容复制到?这里。 ?
?
?1.6 ?参考文献? 列举?编写软件?产品需求?分析报告?时所用到?的参考文?献及资料?，可能包?括:
? ?? 本项?目的合同?书; ?? 上级?机关有关?本项目的?批文; ? ? 本?项目已经?批准的计?划任务书?; ?? 用户界?面风格指?导; ?? 开发?本项目时?所要用到?的标淮;? ? ?系统规格?需求说明?; ?? 使用实?例文档;? ? ?属于本项?目的其它?己发表文?件; ?? 本软?件产品需?求分析报?告中所引?用的文件?、资料;? ? ?相关软件?产品需求?分析报告?; 为?了方便读?者查阅，?所有参考?资料应该?按一定顺?序排列。?如果可能?，每份资?料都应该?给出:
? ? ? 标?题名称;? ? ?作者或者?合同签约?者; ?? 文件?编号或者?版本号;? ? ?发表日期?或者签约?日期; ? ? 出?版单位或?者资料来?源。
? ?2. 综?合描述 ? 这一部?分概述了?正在定义?的软件产?品的作用?范围以及?该软件产?品所运行?的环境、?使用该软?件产品的?用户、对?该软件产?品己知的?限制、有?关该软件?产品的假?设和依赖?。
? 2?.1 产?品的状况? 描述?了在软件?产品需求?分析报告?中所定义?的软件产?品的背景?和起源。说明了该??软件产品?是否属于?下列情况?:
? ?? 是否是?产品系列?中的下一?成员; ? ? 是?否是成熟?产品所改?进的下一?代产品;? ? ?是否是现?有应用软?件的替代?品(升级?产品);? ? ?是否是一?个新型的?、自主型?的产品。?
? 如果?该软件产?品需求分?析报告定?义的软件?系统是:?
? ? ?大系统的?一个组成?部分; ? ? 与?其它系统?和其它机?构之间存?在基本的?相互关系?。
? 那?么必须说?明软件产?品需求分?析报告定?义的这部?分软件是?怎样与整?个大系统?相关联的?，或者(?同时)说?明相互关?系的存在?形式，并?且要定义?出两者之?间的全部?接口。 ?
? 2.2? 产品的?功能 ?因为将在?需求分析?报告的第?4部分中?详细描述?软件产品?的功能，?所以在此?只需要概?略地总结?。仅从业?务层面陈?述本软件?产品所应?具有的主?要功能，?在描述功?能时应该? 针对每?一项需求?准确地描?述其各项?规格说明?。如果存?在引起误?解的可能?，在陈述?本软件产?品主要功?能的作用?领域时，?也需要对?应陈述本?软件产品?的非作用?领域，以?利 读者?理解本软?件产品。?
? 为了?很好地组?织产品功?能，使每?个读者都?容易理解?，可以采?用列表的?方法给出?。也可以?采用图形?方式，将?主要的需?求分组以?及它们之?间的联系?使用数据?流程图的?顶层图或?类图进行?表示，这?种表示方?法是很有?用的。 ?
?各个机构?的主要职?能，将有?助于陈述?软件产品? ? 参考用?户当前管?理组织构?架，了解
的主要功?能。
? ?2.3 ?用户类和?特性 ?确定有可?能使用该?软件产品?的不同用?户类，并?且描述它?们相关的?特征。往?往有一些?软件需求?，只与特?定的用户?类有关。?描述时，?应该将该?软件产品?的重要用?户类与非?重要用户?类区分开?。
? 用?户不一定?是软件产?品的直接?使用者，?通过报表?、应用程?序接口、?系统硬件?接口得到?软件产品?的数据和?服务的人?、或者机?构也有他?们的需求?。所以，?应该将这?些外部需?求视为通?过报表、?应用程序?接口、系?统硬件接?口附加给?软件产品?的附加用?户类。 ?
? 2.4? 运行环?境 描?述了本软?件的运行?环境，一?般包括:?
? ? ?硬件平台?; ?? 操作系?统和版本?;[1]?[2][?3][4?]下一页?> ?? 支撑环?境(例如?:
? 数据库?等)和版?本; ?? 其它?与该软件?有关的软?件组件;? ? ?与该软件?共存的应?用程序。?
? 2.?5 设计?和实现上?的限制 ? 确定影?响开发人?员自由选?择的问题?，并且说?明这些问?题为什么?成为一种?限制。可?能的限制?包括下列?内容:
? ? ? 必?须使用的?特定技术?、工具、?编程语言?和数据库?; ?? 避免使?用的特定?技术、工?具、编程?语言和数?据库; ? ? 要?求遵循的?开发规范?和标准 ? 例如，?如果由客?户的公司?或者第三?方公司负?责软件维?护，就必?须定义转?包者所使?用的设计?符号表示?和编码标?准; ?? 企业?策略的限?制; ?? 政府?法规的限?制; ?? 工业?标准的限?制; ?? 硬件?的限制 ? 例如，?定时需求?或存储器?限制; ? ? 数?据转换格?式标淮的?限制。 ?
? 2.6? 假设和?约束(依?赖) ?列举出对?软件产品?需求分析?报告中，?影响需求?陈述的假?设因素(?与己知因?素相对立?)。如果?这些假设?因素不正?确、不一?致或者被?修改，就?会使软件?产品开发?项目受到?影响。这?些假设的?因素可能?包括:
? ? ? 计?划使用的?商业组件?，或者其?它软件中?的某个部?件; ?? 假定?产品中某?个用户界?面将符合?一个特殊?的设计约?定; ?? 有关?本软件用?户的若干?假定(例?如:
? 假定?用户会熟?练使用s?ql语言?。); ? ? 有?关本软件?开发工作?的若干假?定(例如?:
? 用户承?诺的优惠?、方便、?上级部门?给予的特?殊政策和?支持等。?); ?? 有关?本软件运?行环境的?一些问题?; 此?外，确定?本软件开?发项目对?外部约束?因素所存?在的依赖?。有关的?约束可能?包括:
? ? ? 工?期约束;? ? ?经费约束?; ?? 人员约?束; ?? 设备?约束; ? ? 地?理位置约?束; ?? 其它?有关项目?约束; ? 3. ?外部接口?需求 ?通过本节?描述可以?确定，保?证软件产?品能和外?部组件正?确连接的?需求。关?联图仅能?表示高层?抽象的外?部接口，?必须对接?口数据和?外部组件?进行详细?描述，并?且写入数? 据定义?中。如果?产品的不?同部分有?不同的外?部接口，?那么应该?把这些外?部接口的?全部详细?需求并入?到这一部?分实例中?。
? 注?意:
? 必须?将附加用?户类的特?征与外部?接口需求?加以区分?，附加用?户类的特?征描述的?是通过接?口取得软?件产品的?数据和服?务的人的?需求;而?外部接口?需求描述?的是接口?本身的需?求。
? ?3.1 ?用户界面? 陈述?需要使用?在用户界?面上的软?件组件，?描述每一?个用户界?面的逻
这里需要?描述的是?用户界面?的逻辑特?征，而不?是用户界?面。以辑?特征。必?须注意，?
下?是可能包?括的一些?特征:
? ? ? 将?要采用的?图形用户?界面(g?ul)标?准或者产?品系列的?风格; ? ? 有?关屏幕布?局或者解?决方案的?限制; ? ? 将?要使用在?每一个屏?幕(图形?用户界面?)上的软?件组件，?可能包括?:
? 选?单; ?标准按钮?; 导?航链接;? 各种?功能组件?; 消?息栏; ? ? 快?捷键; ? ? 各?种显示格?式的规定?，可能包?括:
? ?不同情况?下文字的?对齐方式?; 不?同情况下?数字的表?现格式与?对齐方式?; 日?期的表现?方法与格?式; ?计时方法?与时间格?式; ?等等。 ?
? ? 错?误信息显?示标准;? 对于?用户界面?的细节，?例如:
? 一?个特定对?话框的布?局，应该?写入具体?的用户界?面设计说?明中，而?不能写入?软件需求?规格说明?中。
? ?如果采用?现成的、?合适的用?户界面设?计规范(?标准)，?或者另文?描述，可?以在这里?直接说明?，并且将?其加入参?考文献。?
? 3.?2 硬件?接口 ?描述待开?发的软件?产品与系?统硬件接?口的特征?，若有多?个硬件接?口，则必?须全都描?述。接口?特征的描?述内容可?能包括:?
? ? ?支持的硬?件类型;? ? ?软、硬件?之间交流?的数据;? ? ?控制信息?的性质;? ? ?使用的通?讯协议;? 3.?3 软件?接口 ?描述该软?件产品与?其它外部?组件的连?接，这些?外部组件?必须明确?它们的名?称和版本?号以资识?别，可能?的外部组?件包括:?
? ? ?操作系统?; ?? 数据库?; ?? 工具;? ? ?函数库;? ? ?集成的商?业组件 ? 说明:?
?这里所说?的 集成?的商业组?件 ，是?指与系统?集成的商?业组件，?而不是与?软件产品?集成的商?业组件。?例如:
? 中?间件、消?息服务，?等等。 ?
? 描述并?且明确软?件产品与?软件组件?之间交换?数据或者?消息的目?的。描述?所需要的?服务，以?及与内部?组件通讯?的性质。?确定软件?产品将与?组件之间?共享的数?据。如果?必 须使?用一种特?殊的方法?来实现数?据共享机?制，例如?:
? 在多用?户系统中?的一个全?局数据区?，那么就?必须把它?定义为一?种实现上?的限制。?
? 3.?4 通讯?接口 ?描述与软?件产品所?使用的通?讯功能相?关的需求?，包括:?
? ? ?电子邮件?; ?? web?浏览器;? ? ?网络通讯?标准或者?协议; ? ? 数?据交互用?电子表格?; 必?须定义相?关的:
? ? ? 消?息格式;? ? ?通讯安全?或加密问?题; ?? 数据?传输速率?; ?? 同步和?异步通讯?机制; ? 4. ?系统功能?需求 [?3][4?]下一页?> 需要?进行详细?的需求记?录，详细?列出与该?系统功能?相关的详?细功能需?求，并且?，唯一地?标识每一?项需求。?这是必须?提交给用?户的软件?功能，使?得用户可?以使用所?提供 的?功能执行?服务或者?使用所指?定的使用?实例执行?任务。描?述软件产?品如何响?应己知的?出错条件?、非法输?入、非法?动作。 ?
? 如果每?一项功能?需求都能?用一项，?也只需要?用一项测?试用例就?能进行验?证，那么?就可以认?为功能需?求已经适?当地进行?描述了。?如果某项?功能需求?找不到合?适的测试?用例，或?者必须使?用多项测?试用例才?能验证，?那么该项?功能需求?的描述必?然存在某?些问题。?
? 功能?需求是根?据系统功?能，即软?件产品所?提供的主?要服务来?组织的。?可以通过?使用实例?、运行模?式、用户?类、对象?类或者功?能等级来?组织这部?分内容，?也可以便?用这些元?素的组合?。总而言?之，必须?选择一种?是读者容?易理解预?期产品的?组织方案?。
? 用?简短的语?句说明功?能的名称?，例如:?
? 4.1?系统参数?管理 。?按照服务?组织的顺?序，逐条?阐述系统?功能。无?论说明的?是何种功能，都应??该针对该?系统功能?重复叙述?4.1~? 4.3?这三个部?分。
? ?可以通过?各种方式?来组织这?一部分内?容，例如?采用:
? 使?用实例、?运行模式?、用户类?、对象类?、功能等?级等，也?可以采用?它们的组?合。其最?终目的是?，让读者?容易理解? 即将开?发的软件?产品。一?般来说，?每个使用?实例都对?应一个系?统功能，?因而按照?使用实例?来组织内?容比较容?易让用户?理解。 ?
? 对应一?些被共享?的独立使?用实例，?可以定义?一些公用?系统功能?。
? 必?须特别注?意的是，?在2.2?节 产品?的功能 ?中描述的?全部需求?，以及它?们的规格?说明;必?须在某个?系统功能?描述中有?所反映，?而且不应?重复。 ?
? 4.1? 说明和?优先级 ? 对该系?统功能进?行简短的?说明，并?且指出该?系统功能?的优先级?是:
? 高、?中、还是?低。需要?的话，还?可以包括?对特定优?先级部分?的评价，?例如: ? 利?益、损失?、费用和?风险，其?相对优先?等级可以?从1(低?)到9(?高)。 ?
? 4.2? 激励/?响应序列? 列出?输入激励?(用户动?作、来自?外部设备?的信号或?者其它触?发)并且?定义针对?这 功能?行为的系?统响应序?列，这些?序列将与?使用实例?中相关的?对话元素相对应。??
? 描述?激励/响?应序列时?，不仅需?要描述基?本过程，?而且应该?描述可选?(扩充)?过程，包?括例外(?引起任务?不能顺序?完成的情?况称为例?外)。疏?忽了可选?过程，有?可能影响?软件产品?的功能;?如果遗漏?例外过程?，则有可?能会引发?系统崩溃?。
? 如?果采用流?程图来描?述激励/?响应序列?，比较容?易让用户?理解。 ?
? 4.3? 输入/?输出数据? 列出?输入数据?(用户输?入、来自?外部接口?的输入或?者其它输?入)并且?定义针对?这些输入?数据的处?理(计算?)方法，?以及相应?地输出数?据，描述?对应区别?:
? 输入数?据和输出?数据。 ?
? 当有大?量数据需?要描述时?，也可以?分类描述?数据，并?且注明各?项数据的?输入、输?出属性。?
? 对于?每一项数?据，均需?要描述:?
? ? ?数据名称?; ?? 实际含?义; ?? 数据?类型; ? ? 数?据格式;? ? ?数据约束?; 对?于复杂的?处理方法?，仅仅给?出算法原?理是不够?的，必须?描述详细?的计算过?程，并且?列出每一?步具体使?用的实际?算式;如?果计算过?程中涉及?查表、判?断、迭代?等处理方?法，应该?给出处理?依据和相?关数据。?如果计算?方法很简?单，也可?以将其从?略，不加?描述。 ?
? 5. ?其它非功?能需求 ? 在这里?列举出所?有非功能?需求，主?要包括可?靠性、安?全性、可?维护性、?可扩展性?、可测试?性等。 ?
? 5.1? 性能需?求 阐?述不同应?用领域对?软件产品?性能的需?求，并且?说明提出?需求的原?理或者依?据，以帮?助开发人?员做出合?理的设计?选择。尽?可能详细?地描述性?能需求，?如果需要?，可以针?对每个功?能需求或?者特征分?别陈述其?性能需求?。在这里?确定: ? ? ? 相?互合作的?用户数量?; ?? 系统支?持的并发?操作数量?; ?? 响应时?间; ?? 与实?时系统的?时间关系?:
? ?? 容量需?求 存?储器; ? 磁盘空?间; ?数据库中?表的最大?行数。 ?
? 5.2? 安全措?施需求 ? 详尽陈?述与软件?产品使用?过程中可?能发生的?损失、破?坏、危害?相关的需?求。定义?必须采取?的安全保?护或动作?，以及必?须预防的?潜在危险?动作。明?确软件产?品必须遵?从的安全?标准、策?略、或规?则。
? ?5.3 ?安全性需?求 详?尽陈述与?系统安全?性、完整?性问题相?关的需求?，或者与?个人隐私?问题相关?的需求。?这些问题?将会影响?到软件产?品的使用?，和软件?产品所创?建或者使?用的数据?的保 护?。定义用?户身份认?证，或备?授权需求?。明确软?件产品必?须满足的?安全性或?者保密性?策略。也?可以通过?称为完整?性的质量?属性来阐?述这些需?求。一个?典型的软?件系统 ?安全需求?范例如下?:
? 每个?用户在第?一次登录?后，必须?更改他的?系统预置?登录密码?，系统预?置的登录?密码不能?重用。 ?
? 5.?4 软件?质量属性? 详尽?陈述对客?户和开发?人员至关?重要的在?软件产品?其它方面?表现出来?的质量功?能。这些?功能必须?是确定的?、定量的?、在需要?时是可以?验证的。?至少也应?该指明不?同属性的?相对侧重?点，例如?:
? 易用性?优于易学?性，或者?可移植性?优于有效?性。
? ?5.5 ?业务规则? 列举?出有关软?件产品的?所有操作?规则，例?如:
? 那些?人在特定?环境下可?以进行何?种操作。?这些本身?不是功能?需求，但?是他们可?以暗示某?些功能需?求执行这?些规则。?一个 业?务规则的?范例如下?:
? 进行?达到或者?超过10?，000?，00元?人民币的?储蓄业务?时，必须?通过附加?的管理员?[3][?4]下一?页认证。?
? 列?举业务规?则时，可?以根据规?则的数量?，选取合?适的编目?方式。 ?
? 5.6? 用户文?档 列?举出将与?软件产品?一同交付?的用户文?档，并且?明确所有?己知用户?文档的交?付格式或?标准，例?如:
? ?? 安装?指南 ?纸质文档?，16开?本; ?? 用户?手册 ?纸质文档?，16开?本; ?? 在线?帮助 ?? 电子?文档，与?软件产品?一同分发?、配置;? ? ?使用教程?电子文档?，与软件?产品一同?分发、配?置。
? ?6. 词?汇表 ?列出本文?件中用到?的专业术?语的定义?，以及有?关缩写的?定义(如?有可能，?列出相关?的外文原?词)。为?了便于非?软件专业?或者非计?算机专业?人士阅读?软件产品?需求分析? 报告，?要求使用?非软件专?业或者非?计算机专?业的术语?描述软件?需求。所?以这里所?指的专业?术语，是?指业务层?面上的专?业术语，?而不是软?件专业或?者计算机?专业的术? 语。但?是，对于?无法回避?的软件专?业或者计?算机专业?术语，也?应该列入?词汇表并?且加以准?确定义。?
? 7.? 数据定?义 数?据定义是?一个定义?了应用程?序中使用?的所有数?据元素和?结构的共?享文档，?其中对每?个数据元?素和结构?都准确描?述:
? 含义?、类型、?数据大小?、格式、?计量单位?、精度 ?以及取值?范围。数?据定义的?维护独立?于软件需?求规格说?明，并且?在软件产?品开发和?维护的任?何阶段，?均向风险?承担者开?放。
? ?如果为软?件开发项?目创建一?个独立的?数据定义?，而不是?为每一项?特性描述?有关的数?据项，有?利于避免?冗余和不?一致性。?但是却不?利于多人?协同编写?需求分析?报告，容? 易遗漏?数据，也?不方便阅?读。因此?还是建议?为每个特?性描述有?关的数据?项，汇总?数据项创?建数据定?义，再根?据数据定?义复核全?部数据，?使得它们?的名称和?含义完全?一 致。?必须注意?的是，为?了避免二?义性，在?汇总数据?项时应该?根据数据?项所代表?的实际意?义汇总，?而不是根?据数据项?的名称汇?总。
? ?在数据定?义中，每?个数据项?除了有一?个中文名?称外，还?应该为它?取一个简?短的英文?名称，该?英文名称?应该符合?命名规范?，因为在?软件开发?时将沿用?该英文名?称。可以?使用等号?表示数据?项，名称?写在左边?，定义写?在右边。?常见数据?项的描述?方式如下?:
? ?? 原数据?元素 ?一个原数?据元素是?不可分解?的，可以?将一个数?量值赋给?它。定义?原数据元?素必须确?定其 ?含义、类?型、数据?大小、格?式、计量?单位、精?度以及取?值范围。?采用以星?号为界的?一行 ?注释文本?，描述原?数据元素?的定义。?
? ? ?选择项 ? 选择项?是一种只?可以取有?限离散值?的特殊原?数据元素?，描述时?一一枚举?这些值，?并用方 ? 括号括?起来写在?原数据元?素的定义?前。在两?项离散值?之间，使?用管道符?分隔。 ?
? ? 组?合项 ?组合项是?一个数据?结构或者?记录，其?中包含了?多个数据?项。这些?数据项可以是原数??据元 ?素，也可?以是组合?数据项，?各数据项?之间用加?号连接。?其中每个?数据项都?必须是数?据定 ?义中定义?过的，结?构中也可?以包括其?它结构，?但是绝对?不允许递?归。如果?数据结构?中有 ?可选项，?使用圆括?号把该项?括起来。?
? ? ?重复项 ? 重复项?是组合项?的一种特?例，其中?有一项将?有多个实?例出现在?数据结构?中，使用?花括号 ? 把该项?括起来。?如果知道?该项可能?允许的范?围，就按? 最小值?:
? 最大值? 的形式?写在花 ? 括号前?。
? 8?. 分析?模型 ?这是一个?可选部分?，包括或?涉及到相?关的分析?模型，例?如:
? ?? 数据?流程图;? ? ?类图; ? ? 状?态转换图?; ?? 实体-?关系图。?
? 9.? 待定问?题列表 ? 编辑一?张在软件?产品需求?分析报告?中待确定?问题时的?列表，把?每一个表?项都编上?号，以便?跟踪调查?。[3]?[4]
?
范文二：软件需求分析总结范文范文
软件需求分析总结范文
1. 引言
引言是对这份软件产品需求分析报告的概览,是为了帮助阅读者了解这份文档是如何编写的,并且应该如何阅读、理解和解释这份文档。
编写目的
说明这份软件产品需求分析报告是为哪个软件产品编写的,开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格,包括修正和(或)发行版本号,从而对该软件产品进行准确的定义。
如果这份软件产品需求分析报告只与整个系统的某一部分有关系,那么只定义软朐件产品需求分析报告中说明的那个部分或子系统。
1.项目风险崽
具体说明本软件开发项目的全部风险承担者,以及各自谣在本阶段所需要承担的主要风险,首要风险承担趑者包括,
? 任务提出者;
? 软件开发者;
? 产品使用者。抿
1.文档约定
1 / 19
描述编写文档时所采用的标准避(如果有标准的话),或者各种排版约定。排版约定应该包括,浜
? 正文风格;
? 提示方式;
? 重要符号比;
也应该说明高层次需求是否可以被其所有细化鲵的需求所继承,或者每个需求陈述是否都有其自己的优先级。窈
1.预期读者和阅读建议
列举本软件产品需求分煨析报告所针对的各种不同的预期读者,例如,可能包括,
? 用户;
? 开发人员;
? 项目经理;
? 营销人员 ;
? 测试人员;
? 文档编写入员。
并且描述了文档中,其余部分的内容及其组织结构,并乏
且针对每一类读者提出最适合的文档阅读建议。沃
1.产品范围惭
说明该软件产品及其开发目的的简短描述,包括利益和鸾目标。把软件产品开发与企业目标,或者业务策略相联系。“
描述产品范围时需注意,可以参考项目视图和范围文峄
2 / 19
档,但是不能将其内容复制到这里。
1.参考文献
列?举编写软件产品需求分析报告时所用到的参考文献
及资料,可能包括,茇
? 本项目的合同书;
? 上级机关有蚴关本项目的批文;
? 本项目已经批准的计划任务书; ? 用户界面风格指导;
? 开发本项目时所要用到的 标淮; ? 系统规格需求说明;
? 使用实例文档;
? 属于本项目的其它己发表文件; ? 本软件产品需求分析报告中所引用的文件、资料酾;
? 相关软件产品需求分析报告碌;
为了方便读者查阅,所有参考资料应该 按一定顺序排
列。如果可能,每份资料都应该给出, ? 士标题名称;
? 作者或者合同签约者;
? 文件编号或者版本号啖;
? 发表日期或者签约日期;
? 出版单位或者资料来源。段
2. 综合描述
3 / 19
这一部分概述扬了正在定义的软件产品的作用范围以及该软件产品所运行的环境、使用该软件产品的用户、对该软
件产品己知的限它制、有关该软件产品的假设和依赖。
.1 产品的状况
描述了在软件产品需求分析报告中所定义的软件产品的背景和起源。说明了该软件产品是否属于下列情况,粱
? 熨是否是产品系列中的下一成员;
? 是否是成熟产品所改进的下一代产品莩;
? 是否是现有应用软件的替代品 (升级产品);
? 是否是一个新型的、自主型的产遏品。
如果该软件产品需求分析报告定义的软件系统是,
? 大系统的一个组成部分;
? 与其它系统和其它机构之间存在基本的相互关系。琐
那么必须说明软件产品需邬求分析报告定义的这部分软件是怎样与整个大系统相关联的,或者吐(同时)说明相互关系的存在形式,并且要定义守出两者之间的全部接口。
.产品的功能
因为将在需求分析报告的第雳4部分中详细描述软件产品的功能,所以在此只需要概略地总结。仅从业务层面陈述本糠
软件产品所应具有的主要功能,在描述功能时应该衲 针对每一项需求准确地描述其各项规格说明。如果存在引起误解的乱
可能,在陈述本软件产品主要功能的作用领域时,也需要对
4 / 19
应陈述本软件产品的非作用领域,以利韧 读者理解本软件产品。
为了很好地组织产品功能,使每个读者都容易理解,可以采用列表的方法给出。也可以采用图形方式,将主要的需菲韶求分组以及它们之间的联系使用数据流程图的顶层图或类急图进行表示,这种表示方法是很有用的。
参考用户当前 管理组织构架,了解各个机构的主要职能,将有助于陈述软件产品的主要功能。喉
.用户类和特性
确定有可能使用该软件产品的不同用户类,并且描述它挚
们相关的特征。往往有一些软件需求,只与特定的用户类有邂
关。描述时,应该将该软件产品的重要用户类与非重要用户芎
类区分开。
用户不一定是软件产品的直接使用者,通过报表、应用程序接口、系统硬件接口得到软件产品的数据和服务的人、?铗或者机构也有他们的需求。所以,应该将这些外部需求视为灿通过报表、应用程序接口、系统硬件接口附加给软件产硐品的附加用户类。
.运行环境
描述了本软件的运行环柠境,一般包括,
? 硬件平台;
? 操作系统和版本; ? 支撑环境弗(例如,数据库等)
5 / 19
和版本;ポ
? 其它与该软件有关的软件组件;
? 与该软件共敌存的应用程序。
.设计和实现上的限制
确定影响开发人员自由选择的问题,并且说明这些问题停
为什么成为一种 限制。可能的限制包括下列内容,
? 必须使用的特定技术、工具、编程语言和数据库罕;
? 避免使用的特定技术、工具、编程语言和数据库酎;
? 要求遵循的开发规范和标准缝
例如,如果由客户的公司或者第三方公司负澳责软件维护,就必须定义转包者所使用的设计符号表示和 编码标准;
? 企业策略的限制;
? 政府法规的限制翡;
? 工业标准的限制;
? 硬件的限制
例如,定时需求或存储器限制趸;
? 数据转换格式标淮的限制将。
.假设和约束(依赖)
列举出对软件产品需求分析报告中,影响需求陈述的假每
设因素(与己知因素相对立)窃。如果这些假设因素不正确、不一致或者被修改,就会使 软件产品开发项目受到影响。这些假设的因素可能包括,
6 / 19
? 计划使用的商业组件,或者其它软件中的某个部件;
? 假定产品中某个用户界面将符合一个特殊的设计约定;
? 有关本软件用户的若干假定(例如,假定用户会檠熟练使用sql语言。);
? 有关本软件开发工作的若干假定 (例如,用户承诺的优惠、方便、上级部门给予的特殊政策和支持等。裤);
? 有关本软件运行环境的一些问题仰;
此外,确定本软件开发项目对外部约束因素所存在的依 赖。有关的约束可能包括,
? 工期约束;
? 经费约束;
? 人员约束;
? 设备约束;
? 窃地理位置约束;
? 其它有关项目约束;
3. 外部接口需求卢
通过本节描述可以确定,保证软件产品能和外部组件正,确连接的需求。关联图仅能表示高层抽象的外蜻部接口,必须对接口数据和外部组件进行详细描述,并且亻写入数 据定义中。如果产品的不同部分有不同的外部接口,那么应该把这蹶
些外部接口的全部详细需求并入到这一部分实例中。够
7 / 19
注意,必须将附加用户类的特征与外部接邡口需求加以区分,附加用户类的特征描述的是通过接口取得软件产品的数疠
据和服务的人的需求;而外部接口需求描刎述的是接口本身的需求。
.1 用户界面
陈述需要使用在用户界面上的软件组件,描述每一个用蝤
户界面的逻辑特征。必须注意,这里需要描述的是用户界面预
的逻辑特征,而不是用户界面。以下是可能包括的一些特征,弼
? 将要采用的图形用户界面(gul)标准或者产品系列的哉风格;
? 有关屏幕布局或者解决方案的限制;
? в将要使用在每一个屏幕(图形用户界面)上的软件组件,可能包括,户
选单;
标准按钮;
导航链接;
各种功饼能组件;
消息栏;
? 快捷键;
? 各种显示格式的规定,可能包括,滔
不同情况下文字的对齐方式;
不同情况下数字的表现格式与对齐方式嵫;
8 / 19
日期的表现方法鬲与格式;
计时方法与时间格式;
等等。
? 错误信息显示标准谵;
对于用户界面的细节,例如,一个特定对锄话框的布局,应该写入具体的用户界面设计说明中,而不能写入软件需求嗍
规格说明中。
如果采用现成的、合适的用户界面设计规范崂(标准),或者另文描述,可以在这里直接说明,并且将其加入参考文献。
.硬件接口
描述待开发的软件产品与系统硬件接口的特征,若有多海
个硬件接口,则必须全都描述。接口特征的描述内容可能包汪
括,蛋
? 支持的硬件类型;
? 软、硬件之间交流的数据; 歪
? 控制信息的性质;
? 使用的通讯协议;
.软件接口
描述该软件产品与其它外部组件的连接,这些外部组件 必须明确它们的名称和版本号以资识别,可能的忙外部组件包括,
? 操作系统;
9 / 19
? 数据库;
? 工具 ;
? 函数库;
? 集成的商业组件
说明,这ュ里所说的“集成的商业组件”,是指与系统集成的商业组件,而不是与软件产品集成的商业组件。例如,中间
件、消息服务,等等。
描述并且明确软件产品与软件组件之抖间交换数据或者消息的目的。描述所需要的服务,以及与琐内部组件通讯的性质。确定软件产品将与组件之间共享的数据。如果必运 须使用一种特殊的方法来实现数据共享机制,例如,在多用户系邸
统中的一个全局数据区,那么就必 须把它定义为一种实现上的限制。
.通讯接口
描述与软件产品所使用的通讯功能相关的需求,包括,泵
? 电子邮件吧;
? web浏览器;
? 网络通讯标准或者鄹协议;
? 数据交互用电子表格;
必须定义相关的,
? 消息格式;
? 通讯安全或加密问题;
10 / 19
? 数据传输速率峤;
? 同步和异步通讯机制;
4. 系统功能需求述
> 需要进行详细的需求记录,详细列出与该系统功能相 关的详细功能需求,并且,唯一地标识每一项需求。这是必 须提交给用户的软件功能,使得用户可以使用所提供鸽 的功能执行服务或者使用所指定的使用实例执行任务。描述软件
产品如何响应己知的出错条件、非法输入妗、非法动作。
如果每一项功能需求都能用一项,也只需房要用一项测试用例就能进行验证,那么就可以认为功能需求已经适当地进弋
行描述了。如果某项功能需求找不到合适的测试用例,或者廿
必须使用多项测试用例才能验证,那么该项功能需求的描述协
必然存在某些问题。
功能需求是根据系统功能,即软件产品所提供的主要服月
务来组织的。可 以通过使用实例、运行模式、用户类、对象类或者功能等级来组织这部分内容,也可以便用这些元素的胧
组合。总而 言之,必须选择一种是读者容易理解预期产品的组织方案 。
用简短的语句说明功能的名称,例如,“系统参数管驯理”。按照服务组织的顺序,逐条阐述系统功能。无论说明的是何狄种功能,都应该针对该系统功能重复叙述~.3这三个部分。
可以通过各种方式来组织这一部分内容,例如采用,使傈
11 / 19
用实例、运行模式、用户类、对象类、功能等级等,也可以?
采用它们的组合。其最终目的是,让读者爪容易理解 即将开发的软件产品。一般来说,每个使用实例都对应一个系统功彭
能,因而按照使用实例来组织内容比较容易让用户理解。殉
对应一些被共享的独立使用实例,内可以定义一些公用系统功能。
必须特别注意的是,在节“产品的功能”中描述的全部需帽
求,以及它们的规格说明;弯必须在某个系统功能描述中有所反映,而且不应重复。
.1 说明和优先级
对该系统功能进行简短的说明,并且指出该系统功能的贵
优先级是,高、中、还是低。需要妈的话,还可以包括对特定优先级部分的评价,例如,利益壹、损失、费用和风险,其相对优先等级可以从1(低)到9(斗高)。
.激励/响应序列
列出输入激励(用户动阏作、来自外部设备的信号或者其它触发)并且定义针对这,——功能行为的系统响应序列,这些序列将与使用实例中相关的对话元素相对应。魑
描述激励/响应序列时,不仅需要描述基本过程,而且应袄
该描述可选(扩充)过程,包括例外橡(引起任务不能顺序完成的情况称为例外)。疏忽末了可选过程,有可能影响软件产品的功能;如果遗漏例外佻过程,则有可能会引发系统崩溃。
12 / 19
如果采用流程图来描述激励锈/响应序列,比较容易让用户理解。
.输入/输出数据夜
列出输入数据(用户输入、来自外部接口的输入或者其它鳗输入)并且定义针对这些输入数据的处理(计算)丐方法,以及相应地输出数据,描述对应区别,输入数据芄和输出数据。
当有大量数据需要描述时,也可以分类描述数据,并且瞰
注明各项数据的输入、输出属性。
对于每一项数据,均需要描述,逡
? 数据名称;
? 实际含义蝈;
? 数据类型;
? 数据格式;
? 数据约束; 虫
对于复杂的处理方法,仅仅给出算法原理是不够的,褚必须描述详细的计算过程,并且列出每一步具体使用的实ē际算式;如果计算过程中涉及查表、判断、迭代等处理方法,应该哦给出处理依据和相关数据。如果计算方法很简单,也可以将桴其从略,不加描述。
5. 其它非功能需求
在这里列举出所有非功能需求,主要包括可靠性、安全性、可维护性、可扩展性、可测试性等。
13 / 19
.1 性能需求黉
阐述不同应用领域对软件产品性能的需求,并且说明提礞出需求的原理或者依据,以帮助开发人员做出合理的设计选 择。尽可能详细地描述性能需求,如果需要,可以针对煊每个功能需求或者特征分别陈述其性能需求。在这里确定,飒
? 相互合作的用户数量;
? 系统支持的并发操仅作数量;
? 响应时间;
? 与实时系统的时间关系,泻
? 容量需求
存储器;
磁盘空间;
数据库中表的最大行数。枢
.安全措施需求
详尽陈述与软件产品使徕用过程中可能发生的损失、破坏、危害相关的需求。定义眼必须采取的安全保护或动作,以及必须预防的潜在危险动作。明确软件产品必须遵从的安全甾
标准、策略、或规则。
.安全性需求
详尽陈述与系统安全性、完整性问题相关的需求,或者昴
与个人隐私问题相关的需求。这些问题将会影响到软件产品
的使用,和软件产品所创建或者使用的数幄据的保 护。定义
14 / 19
用户身份认证,或备授权需求。明确软件产品必须满足的安徵
全性或者保密性策略。也可以通过称为完整性的质量属性来损
阐述这些需求。一个典型的软件系统跣 安全需求范例如下,“每个用户在第一次登录后,必须更改他的系统预置登录密码,残
系统预置的登录密码不能重用。”犴
.软件质量属性
详尽陈述对客户和开发人员 至关重要的在软件产品其它方面表现出来的质量功能。这 些功能必须是确定的、定量的、在需要时是可以验证的。至少也应该指明不同属性的相稍
对侧重点,例如,易用性优于易学性,或者可移植性优于有
效性。
.业务规则
列举出有关软件产品的所有操作规则,例如,那些人在灭
特定环境下可以进行何种操作。这些本身不是功能需求,但辐
是瘭他们可以暗示某些功能需求执行这些规则。一个 业务规钵则的范例如下,“进行达到或者超过10,000,00元人民币瘃的储蓄业务时,必须通过附加的管理员
认证。”堆
列举业务规则时,可以根据规则的数量,选取合适的编 目方式。
.用户文档
列举出将与软件产品一同交付 的用户文档,并且明确所
15 / 19
有己知用户文档的交付格式或标准,例如,
? 安装指南
纸质文档,16开本;
? 谀用户手册
纸质文档,16开本;
? 在线帮助
? 睾电子文档,与软件产品一同分发、配置;
? 使用教程电子文档,与软件产品一同分发、配置。滢
6. 词汇表
列出本文件中用到的专业术语的定义,以及有关缩写的 定义(如有可能,列出相关的外文原词)。为了便于非软件专毋业或者非计算机专业人士阅读软件产品需求分析 报告,要?求使用非软件专业或者非计算机专业的术语描述?软件需求。所以这里所指的专业术语,是指业务层面上的洪专业术语,而不是软件专业或者计算机专业的术 语。但鹬是,对于无法回避的软件专业或者计算机专业术语,也应榻该列入词汇表并且加以准确定义。
7. 数据定义
数玩据定义是一个定义了应用程序中使用的所有数据元素和结构的共享文档,其中对每个数据元素和结构都准确描读
述,惧含义、类型、数据大小、格式、计量单位、精度 以及取值范围。数据定义的维护独立于软件需求规格说明,并且 螬
16 / 19
在软件产品开发和维护的任何阶段,均向风险承担者开放。魑
如果为软件开发项目创建一个独立的数据定义,而不是娣为每一项特性描述有关的数据项,有利于避免冗余和不ㄇ一致性。但是却不利于多人协同编写需求分析报告,容 忏易遗漏数据,也不方便阅读。因此还是建议为每个特性描述有关的弧数据项,汇总数据项创建数据定义,再根据数据敞定义复核全部数据,使得它们的名称和含义完全一 致。方必须注意的是,为了避免二义性,在汇总数据项时应该根卤据数据项所代表的实际意义汇总,而不是根据数据项的名称汇总。ル
在数据定义中,每个数据项除了有一个中文名圬称外,还应该为它取一个简短的英文名称,该英文名称应 该符合命名规范,因为在软件开发时将沿用该英文名称。可以使用等号
表示数据项,名称写在左边,定义写在右边。常见数据项的摸
描述方式如下,
? 原数据元素
一个原数据元素是不可分解的,可以将一个数量值赋给啾
它。定义原数据元素必须确定其
含义、类型、数据大小、格式、计量单位、精度以及取赣
值范围。采用以星号为界的一行
注释文本,描述原数据元素的定义。
? 选择项
选择项是一种只可以取有限离散值的特殊原数据元素,逖
17 / 19
描述时一一枚举这些值,并用方仲
括号括起来写在原数据元素的 定义前。在两项离散值之间,使用管道符分隔。
? 组合项
组合项是一个数据结构或者记录,其中包含了多个数据 项。这些数据项可以是原数据元
素,也可以是组合数据项,各数据项之间用加号连接。瘘
其中每个数据项都必须是数据定硒
义中定义过的,结构中也可以包括其它结构,但是绝对ē不允许递归。如果数据结构中有
可选项,使用圆括号把该项括起来。壮
? 重复项
重复项是组合项撂的一种特例,其中有一项将有多个实例出现在数据结构中,使用花括号肃
把该项括起来。如果知道该项可能允许的铫范围,就按“最小值,最大值”的形式写在花
括号前。垸
8. 分析模型
这是一个可选部分,包括或涉及到相关的分析模型,例憧
如,
? 数据流程图;
? 类图; 追
18 / 19
? 状态转换图;
? 实体-关系图。
9. 待定问题列表
编辑一张在软件产品需求分析报告中待确定问喔题时的
列表,把每一个表项都编上号,以便跟踪调查。
19 / 19
范文三：软件需求分析总结范文.doc
软件需求分析总结范文
1. 引言 引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。 如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括: ? 任务提出者; ? 软件开发者; ? 产品使用者。 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括: ? 正文风格; ? 提示方式; ? 重要符号; 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括: ? 用户; ? 开发人员; ? 项目经理; ? 营销人员; ? 测试人员; ? 文档编写入员。W 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。 1.5 产品范围 说明该软件产品及其开发目的的简短描述，包括利益和目标。把软件产品开发与企业目标，或者业务策略相联系。 描述产品范围时需注意，可以参考项目视图和范围文档，但是不能将其内容复制到这里。 1.6 > ? 支撑环境(例如:数据库等)和版本; ? 其它与该软件有关的软件组件; ? 与该软件共存的应用程序。 2.5 设计和实现上的限制 确定影响开发人员自由选择的问题，并且说明这些问题为什么成为一种限制。可能的限制包括下列内容: ? 必须使用的特定技术、工具、编程语言和数据库; ? 避免使用的特定技术、工具、编程语言和数据库; ? 要求遵循的开发规范和标准 例如，如果由客户的公司或者第三方公司负责软件维护，就必须定义转包者所使用的设计符号表示和编码标准; ? 企业策略的限制; ? 政府法规的限制; ? 工业标准的限制; ? 硬件的限制 例如，定时需求或存储器限制; ? 数据转换格式标淮的限制。 2.6 假设和约束(依赖) 列举出对软件产品需求分析报告中，影响需求陈述的假设因素(与己知因素相对立)。如果这些假设因素不正确、不一致或者被修改，就会使软件产品开发项目受到影响。这些假设的因素可能包括: ? 计划使用的商业组件，或者其它软件中的某个部件; ? 假定产品中
某个用户界面将符合一个特殊的设计约定; ? 有关本软件用户的若干假定(例如:假定用户会熟练使用sql语言。); ? 有关本软件开发工作的若干假定(例如:用户承诺的优惠、方便、上级部门给予的特殊政策和支持等。); ? 有关本软件运行环境的一些问题; 此外，确定本软件开发项目对外部约束因素所存在的依赖。有关的约束可能包括: ? 工期约束; ? 经费约束; ? 人员约束; ? 设备约束; ? 地理位置约束; ? 其它有关项目约束; 3. 外部接口需求 通过本节描述可以确定，保证软件产品能和外部组件正确连接的需求。关联图仅能表示高层抽象的外部接口，必须对接口数据和外部组件进行详细描述，并且写入数 据定义中。如果产品的不同部分有不同的外部接口，那么应该把这些外部接口的全部详细需求并入到这一部分实例中。 注意:必须将附加用户类的特征与外部接口需求加以区分，附加用户类的特征描述的是通过接口取得软件产品的数据和服务的人的需求;而外部接口需求描述的是接口本身的需求。 3.1 用户界面 陈述需要使用在用户界面上的软件组件，描述每一个用户界面的逻辑特征。必须注意，这里需要描述的是用户界面的逻辑特征，而不是用户界面。以下是可能包括的一些特征: ? 将要采用的图形用户界面(gul)标准或者产品系列的风格; ? 有关屏幕布局或者解决方案的限制; ? 将要使用在每一个屏幕(图形用户界面)上的软件组件，可能包括: 选单; 标准按钮; 导航链接; 各种功能组件; 消息栏; ? 快捷键; ? 各种显示格式的规定，可能包括: 不同情况下文字的对齐方式; 不同情况下数字的表现格式与对齐方式; 日期的表现方法与格式; 计时方法与时间格式; 等等。 ? 错误信息显示标准; 对于用户界面的细节，例如:一个特定对话框的布局，应该写入具体的用户界面设计说明中，而不能写入软件需求规格说明中。 如果采用现成的、合适的用户界面设计规范(标准)，或者另文描述，可以在这里直接说明，并且将其加入> 需要进行详细的需求记录，详细列出与该系统功能相关的详细功能需求，并且，唯一地标识每一项需求。这是必须提交给用户的软件功能，使得用户可以使用所提供 的功能执行服务或者使用所指定的使用实例执行任务。描述软件产品如何响应己知的出错条件、非法输入、非法动作。 如果每一项功能需求都能用一项，也只需要用一项测试用例就能进行验证，那么就可以认为功能需求已经适当地进行描述了。如果某项功能需求找不到合适的测试用例，或者必须使用多项测试用例才能验证，那么该项功能需求的描述必然存在某些问题。 功能需求是根据系统功能，即软件产品所提供的主要服务来组织的。可以通过使用实例、运行模式、用户类、对象类或者功能等级来组织这部分内容，也可以便用这些元素的组合。总而言
之，必须选择一种是读者容易理解预期产品的组织方案。 用简短的语句说明功能的名称，例如:4.1系统参数管理。按照服务组织的顺序，逐条阐述系统功能。无论说明的是何种功能，都应该针对该系统功能重复叙述4.1~ 4.3这三个部分。 可以通过各种方式来组织这一部分内容，例如采用:使用实例、运行模式、用户类、对象类、功能等级等，也可以采用它们的组合。其最终目的是，让读者容易理解 即将开发的软件产品。一般来说，每个使用实例都对应一个系统功能，因而按照使用实例来组织内容比较容易让用户理解。 对应一些被共享的独立使用实例，可以定义一些公用系统功能。 必须特别注意的是，在2.2节产品的功能中描述的全部需求，以及它们的规格说明;必须在某个系统功能描述中有所反映，而且不应重复。 4.1 说明和优先级 对该系统功能进行简短的说明，并且指出该系统功能的优先级是:高、中、还是低。需要的话，还可以包括对特定优先级部分的评价，例如:利益、损失、费用和风险，其相对优先等级可以从1(低)到9(高)。 4.2 激励/响应序列 列出输入激励(用户动作、来自外部设备的信号或者其它触发)并且定义针对这——功能行为的系统响应序列，这些序列将与使用实例中相关的对话元素相对应。 描述激励/响应序列时，不仅需要描述基本过程，而且应该描述可选(扩充)过程，包括例外(引起任务不能顺序完成的情况称为例外)。疏忽了可选过程，有可能影响软件产品的功能;如果遗漏例外过程，则有可能会引发系统崩溃。 如果采用流程图来描述激励/响应序列，比较容易让用户理解。 4.3 输入/输出数据 列出输入数据(用户输入、来自外部接口的输入或者其它输入)并且定义针对这些输入数据的处理(计算)方法，以及相应地输出数据，描述对应区别:输入数据和输出数据。 当有大量数据需要描述时，也可以分类描述数据，并且注明各项数据的输入、输出属性。 对于每一项数据，均需要描述: ? 数据名称; ? 实际含义; ? 数据类型; ? 数据格式; ? 数据约束; 对于复杂的处理方法，仅仅给出算法原理是不够的，必须描述详细的计算过程，并且列出每一步具体使用的实际算式;如果计算过程中涉及查表、判断、迭代等处理方法，应该给出处理依据和相关数据。如果计算方法很简单，也可以将其从略，不加描述。 5. 其它非功能需求 在这里列举出所有非功能需求，主要包括可靠性、安全性、可维护性、可扩展性、可测试性等。 5.1 性能需求 阐述不同应用领域对软件产品性能的需求，并且说明提出需求的原理或者依据，以帮助开发人员做出合理的设计选择。尽可能详细地描述性能需求，如果需要，可以针对每个功能需求或者特征分别陈述其性能需求。在这里确定: ? 相互合作的用户数量; ? 系统支持的并发操作数量;
? 响应时间; ? 与实时系统的时间关系: ? 容量需求 存储器; 磁盘空间; 数据库中表的最大行数。 5.2 安全措施需求 详尽陈述与软件产品使用过程中可能发生的损失、破坏、危害相关的需求。定义必须采取的安全保护或动作，以及必须预防的潜在危险动作。明确软件产品必须遵从的安全标准、策略、或规则。 5.3 安全性需求 详尽陈述与系统安全性、完整性问题相关的需求，或者与个人隐私问题相关的需求。这些问题将会影响到软件产品的使用，和软件产品所创建或者使用的数据的保 护。定义用户身份认证，或备授权需求。明确软件产品必须满足的安全性或者保密性策略。也可以通过称为完整性的质量属性来阐述这些需求。一个典型的软件系统 安全需求范例如下:每个用户在第一次登录后，必须更改他的系统预置登录密码，系统预置的登录密码不能重用。 5.4 软件质量属性 详尽陈述对客户和开发人员至关重要的在软件产品其它方面表现出来的质量功能。这些功能必须是确定的、定量的、在需要时是可以验证的。至少也应该指明不同属性的相对侧重点，例如:易用性优于易学性，或者可移植性优于有效性。 5.5 业务规则 列举出有关软件产品的所有操作规则，例如:那些人在特定环境下可以进行何种操作。这些本身不是功能需求，但是他们可以暗示某些功能需求执行这些规则。一个 业务规则的范例如下:进行达到或者超过10，000，00元人民币的储蓄业务时，必须通过附加的管理员上一页[1][2][3][4]下一页认证。 列举业务规则时，可以根据规则的数量，选取合适的编目方式。 5.6 用户文档 列举出将与软件产品一同交付的用户文档，并且明确所有己知用户文档的交付格式或标准，例如: ? 安装指南 纸质文档，16开本; ? 用户手册 纸质文档，16开本; ? 在线帮助 ? 电子文档，与软件产品一同分发、配置; ? 使用教程电子文档，与软件产品一同分发、配置。 6. 词汇表 列出本文件中用到的专业术语的定义，以及有关缩写的定义(如有可能，列出相关的外文原词)。为了便于非软件专业或者非计算机专业人士阅读软件产品需求分析 报告，要求使用非软件专业或者非计算机专业的术语描述软件需求。所以这里所指的专业术语，是指业务层面上的专业术语，而不是软件专业或者计算机专业的术 语。但是，对于无法回避的软件专业或者计算机专业术语，也应该列入词汇表并且加以准确定义。 7. 数据定义 数据定义是一个定义了应用程序中使用的所有数据元素和结构的共享文档，其中对每个数据元素和结构都准确描述:含义、类型、数据大小、格式、计量单位、精度 以及取值范围。数据定义的维护独立于软件需求规格说明，并且在软件产品开发和维护的任何阶段，均向风险承担者开放。 如果为软件开发项目创建一个独立的数据
定义，而不是为每一项特性描述有关的数据项，有利于避免冗余和不一致性。但是却不利于多人协同编写需求分析报告，容 易遗漏数据，也不方便阅读。因此还是建议为每个特性描述有关的数据项，汇总数据项创建数据定义，再根据数据定义复核全部数据，使得它们的名称和含义完全一 致。必须注意的是，为了避免二义性，在汇总数据项时应该根据数据项所代表的实际意义汇总，而不是根据数据项的名称汇总。 在数据定义中，每个数据项除了有一个中文名称外，还应该为它取一个简短的英文名称，该英文名称应该符合命名规范，因为在软件开发时将沿用该英文名称。可以使用等号表示数据项，名称写在左边，定义写在右边。常见数据项的描述方式如下: ? 原数据元素 一个原数据元素是不可分解的，可以将一个数量值赋给它。定义原数据元素必须确定其 含义、类型、数据大小、格式、计量单位、精度以及取值范围。采用以星号为界的一行 注释文本，描述原数据元素的定义。 ? 选择项 选择项是一种只可以取有限离散值的特殊原数据元素，描述时一一枚举这些值，并用方 括号括起来写在原数据元素的定义前。在两项离散值之间，使用管道符分隔。 ? 组合项 组合项是一个数据结构或者记录，其中包含了多个数据项。这些数据项可以是原数据元 素，也可以是组合数据项，各数据项之间用加号连接。其中每个数据项都必须是数据定 义中定义过的，结构中也可以包括其它结构，但是绝对不允许递归。如果数据结构中有 可选项，使用圆括号把该项括起来。 ? 重复项 重复项是组合项的一种特例，其中有一项将有多个实例出现在数据结构中，使用花括号 把该项括起来。如果知道该项可能允许的范围，就按最小值:最大值的形式写在花 括号前。 8. 分析模型 这是一个可选部分，包括或涉及到相关的分析模型，例如: ? 数据流程图; ? 类图; ? 状态转换图; ? 实体-关系图。 9. 待定问题列表 编辑一张在软件产品需求分析报告中待确定问题时的列表，把每一个表项都编上号，以便跟踪调查。上一页[1][2][3][4]
范文四：软件需求分析和软件需求规格
第3章
软件需求分析和软件需求规格 IEEE把软件需求定义为：
（1）用户为了解决某一问题或者达到某一目标而需要的功能和条件；
（2）这些条件和功能要求必须要被系统所满足，同时要满足相关的合同
契约、标准、规范，或者其他一些正式强制性文件。需要指出的是，所需处理的软件需求是动态的，也就是系统的性能是不断发展的。
正如我们所看到的，所有的开发模型都要求有明确的需求。若使用敏捷
技术就需要高层需求说明书，详细需求通过与客户反复交换意见得到，并且
直接反映在软件中。另一方面是需求描述要精准，需求活动的目的就是要得
到软件需求规格说明书SRS（software requirement specification），它描述了
软件需要做什么，而不描述怎么做。
这一章中要讨论：
转载请注明出处范文大全网 » 软件需求分析总结范文
