文档库 最新最全的文档下载
当前位置:文档库 › 软件开发如何应对非功能性需求变更

软件开发如何应对非功能性需求变更

软件开发如何应对非功能性需求变更
软件开发如何应对非功能性需求变更

软件开发如何应对非功能性需求变更?

需求变更本应是客户的权力,如果确是需要变更,当然要满足客户需要。但问题是不能让变更权力滥用,把一些无关痛痒的非功能性需求变更宠惯养成堂而皇之的变更。对于非功能性需求客户总会有新的想法,项目好像总没有办法终结。以前当出现这种情况时,我总觉得很沮丧,觉得自己非常不幸,怎样会碰上这样的客户。可在读了《设计模式精解(Design Patterns Explained)》一书的一段话后,我恍然大悟,这不是我的错,世界原来就是这样子的啊,永远不变的就是变化。

令人烦恼的非功能性需求变更

在软件开发中,大家都会遇到过这样的问题:客户的一个新想法,就推翻了之前与客户经过再三讨论而确认定下来的需求。如果是功能性需求变更还会让人容易接受一些,毕竟功能性需求不实现的话,是会大大影响到软件产品的质量。但现在我所负责的这个开发项目中遇到的都是一些非功能性的变更,而且许多是看起来无关痛痒的、鸡毛蒜皮的变更。

(1)什么是非功能性需求?

在IEEE中,软件需求的定义是:用户解决问题或达到目标所需的条件或功能。一般包含业务需求、用户需求、功能需求、行业隐含需求和一些非功能性需求。业务需求反映了客户对系统、产品高层次的目标要求;功能需求定义了开发人员必须实现的软件功能。所谓非功能性需求,是指为满足用户业务需求而必须具有除功能需求以外的特性。包括系统性能、可靠性、可维护性、易用性和对技术和对业务适应性等。其中最常见的是软件界面、操作方便等一系列要求。

(2)非功能性需求变更的特点

让我们从客户角度和开发人员角度去看看非功能性需求的特点。首先,有些非功能性小需求从客户角度看起来工作量不大,但是实际上开发人员要耗费比较长的时间去完成这些小功能。其次,许多非功能性需求,如界面美观、操作方便等都是客户头脑一热、或领导一拍脑袋就部署下去的需求,往往是原来在需求分析阶段所没有注意的内容。

其实,非功能性需求是常常被轻视,甚至被忽视的。原因是非功能性需求描述很困难,它很难像功能性需求那样,可以通过结构化和量化的词语来描述清楚。在描述这类需求时候,我们经常采用软件性能要好、操作要方便、软件界面要美观大方等较模糊的描述词语。例如,

易用性就同时涉及到美工和UI界面、人机工程、交互式设计、心理学、用户行为模式等内容。这类描述词语都是脱离了软件的执行环境,是对人和相关的场景的描述,因此很难体现到软件架构设计和具体的实现中。

为什么非功能性需求变更会频繁发生?

为什么非功能性需求不能固定下来呢?或定下来后就不许变了呢?通常有许多人会

问这样的问题。实际上,当他变成了客户时,他可能就不会问这个问题了。

(1)非功能性需求容易产生理解分歧

在软件需求分析阶段,客户和开发人员对非功能性需求的理解呈现"大体上共识多,细节上差异多"的特点。一般跟分析员的知识、背景,还有客户表述的标准程度、双方的交流情况有关。即使通过反复沟通,但是以实践经验来看非功能性需求的描述还是永远不够清晰、不够明确的,主要是因为在这个阶段所谓的产品还只存在于大家的大脑构思中。

作为一个客户,大多数情况下是不懂技术的,但他所需要的软件在他的心里还是有一个印象的。他会想象出软件的样子和功能,然后通过口头或者笔头的方式告诉需求分析人员。简单的说,就是在这个阶段用户往往不能确切地定义自己需要什么。用户常常以为自己清楚,但实际上他们提出的需求只是依据当前的工作所需,或者是他们想象出来的东西。结果是当客户向需求分析人员提出需求的时候,往往是通过自己的想法用自然语言来表达的,这样的表达结果对于真实的需求来说只是一种描述,甚至只是某个角度的描述,但远远不能保证这样的描述可以得到百分之百的正确理解。

当客户提出要求之后,在双方认为理解大概没有分歧的时候,开发人员就开始工作了。但随着开发工作的不断进展,系统开始展现雏形,客户对系统的了解也逐步深入。这个时候,客户就会对系统的界面、操作、功能、性能等有一些了解,就有可能提出需求变更要求,而且这些要求很多是基于主观的、人为的因素。总之,他们了解得越多,新的要求也就会越多。(2)没有明确的需求变更管理流程

在软件开发中的常识是,一旦发生需求变更不要一味的抱怨,也不要一味地去迎合客户的新需求,而是要管理和控制需求变更。但令人不解的是我们常常看到变更的提出、讨论和执行常常只停留在口头上。这样做有两个弊端:首先是时间一长,无论是当事人还是开发团队都说不清楚变更是因何发生以及结果怎么样了。显然,这对于提高项目质量、改进开发过程是很不利的。其次是由于缺乏形式上的约束和对变更代价的定量分析,变更会被非常随意地提出、或被草率地执行,也会大大影响项目的进展和开发质量。

因此,没有明确的需求变更管理流程,就会使需求变更变得泛滥。因为并不是所有的变更都要修改,也不是所有变更都要立刻修改,需求变更管理的目的是为了决定什么类型的变更需要修改和什么时候修改。比如界面风格问题,就可以先不修改,或者规划一下修改的时间待到以后进行优化。

(3)没有让客户知道需求变更的代价

对变更的影响没有评估是需求变更泛滥的根本原因。变更都是有代价的,应该要评估变更的代价和要让客户了解需求变更的后果。如果客户不知道需求变更付出的代价,对开发人员的辛苦就会难以体会。

相比于需求开发人员而言,客户可能对需求变更认识不足,认为他们出钱,软件开发团队就要为它服务。因此,客户对需求变更往往会肆无忌弹,将需求变更视为儿戏,随个人喜好随意变更需求。所以,在和客户接触时应该挑明态度,特别是要让他们清楚需求随意变更所带来的代价和风险。如果客户认为代价太大,那么开发人员就没有必要及时修改,按原来的进度走,但仍要记录变更,待下一版本在修改。

如何有效控制非功能性需求的变更?

做任何变更之前,我们都要考虑后果。由于非功能性需求变更在开发中所处的重要地位,一旦需求发生变化,影响面是很广的。因此,有效控制非功能性需求频繁变更是一件不容小视的事情。

(1)建立明确的非功能性需求基线

对于软件开发来说,变更无可避免,也无从逃避,只能积极应对。因此,在开发过程中,建立明确的非功能性需求基线是一件重要的事情。如果非功能性需求没做好,基线范围就含糊不清,就容易被客户抓住空子,往往要付出许多无谓的变更。如果非功能性需求基线做得好,文档清晰且又有客户签字,那么后期客户提出的非功能性需求变更就会大大减少。因此,在建立需求基线的时候千万不能手软,这并非要刻意针对客户,而是不能让客户养成经常变更的习惯,否则后患无穷。

(2)建立需求变更管理流程

需求变更对软件开发成败有重要影响,既不能一概拒绝客户的变更要求,也不能一味地迁就客户,所以必须要做好需求变更的控制。有句通俗的话说得非常好:需求变更管理的目的不是控制变更的发生,而是对变更进行管理,确保变更有序进行。需求变更管理流程包括变更申请环节、审批人员、审批事项、审批流程等。

目的有两个:一是将客户下达变更的流程尽可能地规范化,减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。二是留下书面依据,为今后可能的成本核算准备好变更账。因此,凡未履行审批程序的变更,一律是无效变更不予受理。在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。但正是由于这种观念才会使到需求变更逐渐变为不可控,最终导致项目的失败。

(3)确认客户是否接受变更的代价

需求变更作为一个计划外的风险对项目肯定存在冲击,只是大小的差别。而且客户的需求是永远不会满足的,可能一天一个样,为了达到控制频繁的需求变更。需要将变更后产

生的成本进行评估与量化,形成分析报告提交双方领导。否则,一味的妥协只会让项目进一步恶化。因此,要让客户认识到变更都是有代价的,不要让客户养成随意变更的毛病。一般来说,如果客户认为该非功能性变更是必须的,而不是其上级领导拍脑袋提出的就会接受这些代价。通过与客户的沟通和协商,开发团队即使没有回报也不会招致客户的埋怨。

(4)加强合同约束力

虽然软件开发合同很难在签订之初就能够精确定义每项需求,单靠合同是帮不上忙的,但也不能忽视合同的约束力。因为有时销售人员为使客户能够快速的签订合同,往往草率决定和片面同意客户提出的需求。当客户提出新的需求时,销售人员往往一看"应该"只是一个小小的修改,没有太大的影响,可能会直接答应能变更。所以,在与客户签订开发合同时,可以增加一些相关条款,如限定客户提出需求变更的时间,规定何种情况的变更可以接受、拒绝接受或部分接受,还可以规定发生需求变更时必须执行变更控制流程等。

(5)加强感情沟通,注意沟通技巧

大多时候单靠合同的约束力是解决不了纷争的。客户着急了就是一句潜台词:做不做,不想做就滚蛋,想做的公司多着呢。例如,有时明明是不合理的要求,可是客户也会狡辩凭什么不给他们做,这可是合同范围内的工作。所以,单看合同是没用的。

那可怎么办呢?通常的做法是通过感情联络,争取客户的同情。我们常常对客户说的一句老生常谈的话,就是提需求也要讲究合情合理,这句话在变更管理中有着独特的意义。用我们的行话说是:做好需求变更管理控制只是做好了一半的工作,还有一半的工作就是去讲道理,去用心、用感情劝客户回头。

月有阴晴圆缺,潮涨潮落。变化并不一定总是给我们带来麻烦,有时也会带来惊喜。在软件开发中,对待客户提出的非功能性需求变更,我们需要用平常心去看待,不是一味拒绝,也不要一味答应。

软件开发案例分析需求模板汇总

E-Storage Management System Software Requirements Specification 电子化仓储管理系统软件需求规格说明书 版权所有不得复制 Copyright ? BroadenGate Technologies, Co., Ltd. All Rights Reserved

Revision Record 修订记录

Catalog 目录

错误!未找到引用源。 Keywords 关键词:仓储管理 Abstract 摘要:本文主要描述电子化仓储管理系统的设计需求,包括功能需求和性能需求,以及其他设计约束等。 List of abbreviations 缩略语清单:

1Introduction 简介 1.1Purpose 目的 1.2Scope 范围 本文档包含电子化仓储管理系统V1.0的对外接口和功能描述,以及和外部的约束关系。2General description 总体概述 2.1Software perspective 软件概述 2.1.1About the Project 项目介绍 2.1.2Environment of Pruduct 产品环境介绍 2.2User characteristics 用户特征 2.3Software function 软件功能 2.4Assumptions & Dependencies 假设和依赖关系 3Specific Requirements 具体需求

3.1Functional Requirements 功能需求 我们采用面向对象分析的方法来作为主要的系统建模方法,使用UML(Unified Modeling Language)作为建模语言。UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。在UML中,从任何一个角度对系统所作的抽象都可能需要几种模型来描述,而这些来自不同角度的模型图最终组成了系统的映像。 Use Case描述的是“actor”(用户、外部系统以及系统处理)是如何与系统交互来完成时,该模型将来可 派生出动态对象模型。 设计Use-case时,我们遵循下列步骤: 第一步: 识别出系统的管理员。管理员可以是用户、外部系统,甚至是外部处理,通过某种途径与系统交互。重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能,并指明这些功能的执行者是谁。尽可能地确保所有管理员都被完全识别出来。 第二步: 描述主要的Use Case。可以采取不断地问自己“这个管理员究竟想通过系统做什么?”来准确地描述Use Case。 第三步: 重新审视每个Use Case,为它们下了详尽的定义。 电子化仓库管理系统是通过对入库业务、出库业务、仓库调拨、库存调整业务信息的管理,提高仓库管理信息的实时性和准确性,达到即时库存管理的功能,并有效控制并跟踪业务的物流和成本管理全过程,实现完善的企业仓储信息管理。系统中设计了装箱算法,为客户提供合理有效的装箱方案,保证了货物集装箱的利用。本系统可以提供有关库存情况的准确信息,增强了作业的准确性和快捷性、减少了整个物流中由于商品误置、送错、偷窃、损害和库存、出货错误等造成的损耗,并最大限度减少存储成本。 总体功能时序图:(如图3-1所示)

系统的功能性需求与非功能性需求

1. 文档介绍 1.1 文档目的 为了明确客户的基本需求,更好地完成对客户需求的了解,并量化和明晰本系统的工作量和工作进度,特编写此说明书。 1.2 文档范围 该文档包括产品售后服务系统项目的介绍、面向的用户群体、系统的功能性需求及非功能性需求。 1.3 读者对象 本手册适用于与客户进行需求的沟通与确认,及所有《产品售后服务跟踪系统》的设计开发人员。 2 系统介绍 2.1 背景 随着信息技术的日益发展,产品售后服务的信息化已成为产品售后服务跟踪系统的必然趋势。产品售后服务系统的核心部分是对客户进行回访问卷调查,以确定客户对产品的评价,服务的满意度。为了更详细的了解产品售后服务过程中各项管理业务,调研人员和最终用户进行了多次讨论,并提出了双方认可的解决方案。 2.2 系统说明 产品售后服务跟踪系统主要为公司解决售后服务管理的需求,协助回访工作人员对客户进行日常回访调查和客户管理,提高管理效率,降低运作成本,增强 企业长期竞争力

通过该系统,公司系统管理人员能实现对回访用户、客户的动态管理;系统管理人员能随时了解回访用户的回访情况;回访用户能记录客户的回访记录;3. 系统面向的用户群体 系统面向产品公司的售后服务管理员,回访用户。 3.1 用户的特征 用户大都具备以下特征: ? 有IE 使用经验 ? 了解网络 ? 了解办公自动化 3.2 用户环境 用户的计算机环境大致如下: ? Microsoft Windows XP ?Microsoft Internet Explorer 6 或更高版本 ? MS Office 办公软件 ? Outlook 或Foxmail 邮件管理 ? Microsoft Windows .NET Framework 2.0 4. 系统的功能性需求 系统包含的功能概括如下表:

需求分析中需求规格SRS的非功能性需求的考虑因素

需求分析中需求规格SRS的非功能性需求的考虑因素 * 功能性质量因素:正确性,健壮性,可靠性 * 非功能性质量因素:性能,易用性,清晰性,安全性,可扩展性,兼容性,可移植性正确性 * 正确性是指软件按照需求正确执行任务的能力。“正确性”的语义涵盖了“精确性”。 * 正确性无疑是第一重要的软件质量属性。 * 技术评审和测试的第一关都是检查工作成果的正确性。 * 机器不会主动欺骗人,软件运行出错通常都是人造成的,所以不要找借口埋怨机器有毛病。 健壮性 * 健壮性是指在异常情况下,软件能够正常运行的能力。 * 正确性描述软件在需求范围之内的行为,而健壮性描述软件在需求范围之外的行为。 * 开发者往往把异常情况错当成正常情况而不作处理,结果降低了健壮性。 * 用户才不管正确性与健壮性的区别,反正软件出了差错都是开发方的错。所以提高软件的健壮性也是开发者的义务。 * 健壮性有两层含义:一是容错能力,二是恢复能力。 可靠性 * 可靠性是指在一定的环境下,在给定的时间内,系统不发生故障的概率。 * 可靠性本来是硬件领域的术语。比如某个电子设备在刚开始工作时挺好的,但由于器件在工作中其物理性质会发生变化(如发热),慢慢地系统的功能或性能就会失常。所以一个从设计到生产完全正确的硬件系统,在工作中未必就是可靠的。 * 软件在运行时不会发生物理性质的变化,人们常以为如果软件的某个功能是正确的,那么它一辈子都是正确的。可是我们无法对软件进行彻底地测试,无法根除软件中潜在的错误。平时软件运行得好好的,说不准哪一天就不正常了,如有千年等一回的“千年虫”问题,司空见惯的“内存泄露”问题、“误差累积”问题等等。 * 时隐时现的错误一般都属于可靠性问题,纠错的代价很高。 性能 * 性能通常是指软件的“时间-空间”效率,而不仅是指软件的运行速度。人们总希望软件的运行速度高些,并且占用资源少些。 * 性能优化的关键工作是找出限制性能的“瓶颈”

软件开发文档规范

附2: 软件文档编写向导 文档分类 项目包括如下几类文档: 项目管理文档。包括:《软件项目计划》、《项目进度报告》、《项目开发总结报告》 软件开发文档。包括:《需求规格说明》、《概要设计说明》、《详细设计说明》、《测试计划》、《软件测试分析报告》。 产品文档。包括:《用户操作手册》《演示文件》。 软件项目计划 (Software Project Plan) 一?引言 1?编写目的(阐明编写软件计划的目的,指出读者对象。) 2?项目背景(可包括:(1 )项目委托单位、开发单位和主管部门;(2)该软件系统与 其他系统的关系。) 3?定义(列出本文档中用到的专门术语的定义和缩略词的原文。) 4?参考资料(可包括:文档所引用的资料、规范等;列出资料的作者、标题、编号、发 表日期、出版单位或资料来源。) 二?项目概述 1.工作内容(简要说明项目的各项主要工作,介绍所开发软件的功能性能等?若不编写可行性研究报告,则应在本节给出较详细的介绍。) 2.条件与限制(阐明为完成项目应具备的条件开发单位已具备的条件以及尚需创造的 条件?必要时还应说明用户及分合同承包者承担的工作完成期限及其它条件与限制。) 3.产品 (1)程序(列出应交付的程序名称使用的语言及存储形式。) (2)文档(列出应交付的文档。) (3 )运行环境(应包括硬件环境软件环境。) 4?服务(阐明开发单位可向用户提供的服务?如人员培训安装保修维护和其他运行支持。 5.验收标准

三.实施计划 1.任务分解(任务的划分及各项任务的负责人。) 2?进度(按阶段完成的项目,用图表说明开始时间完成时间。) 3?预算 4?关键问题(说明可能影响项目的关键问题,如设备条件技术难点或其他风险因素,并说明对策。) 四.人员组织及分工 五.交付期限 六.专题计划要点(如测试计划等。) 项目开发进度报告 一.报告时间及所处的开发阶段 二.给出进度 1.本周的主要活动 2.实际进展与计划比较 三.所用工时(按不同层次人员分别计时。) 四.所有机时 五.工作遇到的问题及采取的对策 六.本周完成的成果 七.下周的工作计划 八.特殊问题 项目开发总结报告 一.引言 1.编写目的(阐明编写总结报告的目的,指明读者对象。) 2.项目背景(说明项目的来源、委托单位、开发单位及主管部门。) 3.定义(列出报告中用到的专门术语定义和缩写词的原意。) 4.参考资料(列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源,可包括: (1 )项目开发计划;(2 )需求规格说明书;(3 )概要设计说明书;(4 )详细设计说明

软件开发需求说明书文档(精)

需求说明书 目录 1. 引 言 ........................................................................................................................................... ...................... 4 1.1 编写的目 的 ........................................................................................................................................... 4 1.2 背 景 ........................................................................................................................................... ............ 4 1.3 项目专用术 语 (4) 1.4 参考资 料 ........................................................................................................................................... . (4) 2. 任务概 述 ........................................................................................................................................... .............. 5 2.1 目 标 ........................................................................................................................................... ............ 5 2.2 运行环 境 ........................................................................................................................................... .... 5 2.3 条件与限 制 (5) 2.4 工作流 程 ........................................................................................................................................... . (5)

关于非功能性需求说明书

非功能性需求 ) 什么是非功能性需求 非功能性需求是这样一种需求,它解决“如何使这个系统能在实际环境中运行”。 ) 重要吗? 在设计解决方案的过程中满足功能性需求当然是很重要的。但是,如果没有考虑非功能性需求,那么这个解决方案则很难取得实效,因为用户可能难以甚至无法使用系统的功能。 很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。 ) 非功能性需求要考虑那些方面 非功能性的特性一般有这些: 可靠性 只显示系统可以做某些事情是不够的。如果一个系统不能可靠地运行(例如,在加载时,或者在系统故障时,等等),则它就不能满足客户的需要。 有一些问题应该自问一下: * 即使硬件出现故障,系统也可以可靠运行吗? * 复制和故障转移方案是什么? * 需要手动干预,还是系统可以自动进行故障转移? * 实现可靠性会对性能造成负面影响吗? * 实现可靠性的成本有多高? 可靠性需要考虑的一些具体方面是: 安全性:假设攻击者就在外面。如何知道系统用户就是他们所声称的,并只让他们访问经过授权的功能?如何保护我的系统不受攻击?考虑到网络攻击、机器攻击,甚至从您自己的系统内部发起的攻击。 事务性:如何设计系统来保存工作单元的属性?如果在设计中涉及多个独立的子系统(服务和就是这种情况),则这一点就显得特别重要。不要假设始终可以进行两阶段提交 ( )。 可用性 如果用户不能够从他们可用的渠道(例如)方便地访问您的产品,那么它的好处何在呢?这有时是作为功能性的一部分一起考虑(或者应该在理想的环境下)的,但是常常被忽视,以致于整个项目处于危险之中。这里需要考虑的一些问题是: * 您是否为用户带来不适当的负担(例如,需要特殊的浏览器版本)? * 系统是否根据模型视图控制器 () 体系结构设计以使多用户界面成为可能?如果是这样,如何将它们绑定在一起? * 是否界面本来就有状态而功能无状态(反之亦然)? 有效性 如果没有有效地使用资源(例如处理器、内存和磁盘空间),功能性、可靠性和可用性再好的系统最后都会失败。我们经常发现将有效性划分成两个子范围是很有用的,这两个子范围都应该加

软件系统开发需求分析-模板

软件系统开发需求分析模板 1. 引言 1.1 编写目的 本系统的开发目的在于更好的管理和经营酒店餐饮行业。本文档的预期读者是酒店管理系统软件开发有关的开发人员。 1.2 项目背景 本项目的名称:酒店管理系统。 随着国民经济的发展,酒店餐饮行业的队伍在全国范围(尤其是在经济发达地区)不断壮大,从事酒店餐饮行业的单位之间竞争愈加激烈。为了提升自身的竞争能力, 各酒店餐饮单位都在尽量定制或购买各项业务的应用软件,运用高科技手段进行经营 和管理。为了让酒店更好的经营,我们组织开发了本软件。 本项目的任务提出者及开发者是酒店管理系统软件开发小组,主要是面向酒店餐饮服务行业。 1.3 定义 酒店管理系统是帮助酒店自身管理和服务酒店客户的软件。 1.4 参考资料 ①《现代软件工程》北京希望电子出版社孙涌等编著 ②《Delphi住宿餐饮管理系统开发实例导航》人民邮电出版社 刘敬严东明马刚编著 ③《软件需求说明书(GB856T——88).doc》 ④《iso标准之需求分析说明书.doc》 2.任务概述 2.1 目标 开发本软件是为了服务酒店,使得酒店更好的经营。适用于一些大中型酒店,主要用于就餐管理和住宿管理。本软件产品是一项独立的软件,不过功能还可以增加,

完成后可以升级以增加功能和完善系统。 2.2 用户的特点 使用本软件要求用户熟悉Windows 操作,并且有一定的软件操作基础。预计本软件将会在一些大中型酒店中得到广泛使用。 2.3 假定和约束 本软件由我们小组六个人共同开发,几乎不要经费,开发期限一个月左右。3.需求规定 3.1 对功能的规定 ①系统帐号管理 第一次用一个管理员账号(系统给定)登陆,登陆成功后,可以设置其他用户,包括密码、权限等。 ②就餐管理 为就餐客户查询并分配餐桌,纪录客户用餐情况并结帐。 ③住宿管理 为住宿客户查询并分配房间,纪录客户住宿情况并结帐。 3.2 对性能的规定 3.2.1精度 本软件主要用于管理,不是科学计算,要求计算的精度不是很苛刻。所以输入,输出数据精度的要求不是很高,用于计算的数用浮点数就可以了。 3.2.2时间特性要求 本软件运行的响应时间要求不超过1~2秒,基本能实现。 3.2.3灵活性 本软件具有升级功能,以满足用户的需求。 3.3输人输出要求

软件开发需求文档

1. 引言 引言是对这份软件系统详细设计报告的概览,是为了帮助阅读者了解这份文档如何编写的,并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件系统详细设计报告是基于哪份软件产品需求分析报告、哪份软件产品概要设计报告和哪份软件产品数据库设计说明书(如果该软件产品需要数据库支持)编写的,开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件系统详细设计报告详尽说明了该软件产品的编码结构,从而对该软件产品的物理组成进行准确的描述。 如果这份软件系统详细设计报告只与整个系统的某一部分有关系,那么只定义软件系统详细设计报告中说明的那个部分或子系统。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者,以及各自在本阶段所需要承担的主要风险,首要风险承担者包括: ●任务提出者; ●软件开发者; ●产品使用者。 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话),或者各种编写约定。编写约定应该包括:●部件编号方式; ●界面编号方式; ●命名规范: ●等等。 1.4 预期读者和阅读建议 列举本软件系统详细设计报告所针对的各种不同的预期读者,例如,可能的读者包括: ●开发人员; ●项目经理; ●测试人员; ●文档编写人员; ●等等。 描述文档中,其余部分的内容及其组织结构,并且针对每一类读者提出最适合的文档阅读建议。

1.5 参考资料 列举编写软件系统详细设计报告时所用到的参考文献及资料,可能包括: ●本项目的合同书; ●上级机关有关本项目的批文; ●本项目已经批准的计划任务书; ●用户界面风格指导; ●开发本项目时所要用到的标难; ●系统规格需求说明; ●使用实例文档; ●属于本项目的其它己发表文件; ●本软件系统详细设计报告中所引用的文件、资料; ●相关软件系统详细设计报告; ●等等。 为了方便读者查阅,所有参考资料应该按一定顺序排列。如果可能,每份资料都应该给出:●标题名称; ●作者或者合同签约者; ●文件编号或者版本号; ●发表日期或者签约日期; ●出版单位或者资料来源。 2. 支撑环境 2.1 数据库管理系统 描述数据库管理系统、以及安装配置情况,需要描述的内容可能包括: ●产品名称以及发行厂商 这里的产品名称指的是数据库发行厂商发布产品时公布的正式商品名称,不应该使用别名、简称、研发代号等非正式名称,以免混淆;同样的道理,发行厂商的名称也应该使用正式名称。 ●版本号 数据库管理系统的准确版本号,必须按产品的实际情况描述到最细节的版本号。 ●补丁包版本号 描述实际上将要使用的数据库管理系统补丁包的版本号,必须注意,在某些情况下该版本号不一定是最新的版本号。 ●语言或代码集 对于只支持一种语言或者一个代码集的数据库管理系统来说,该项描述不具意义。对于支持多种语言或者多个代码集的数据库管理系统来说,该项描述指的是实际使用的语言或者代码集。 ●安装位置 描述数据库管理系统的实际安装位置,应该分别对管理系统安缺位置和数据存放位置进行描述,应该指明服务器名和安装卷号(盘号)。对于分布式数据库,必须分别描述每一个数据

软件开发-非功能性需求——性能需求-嘉为科技

释放办公激情,效能触手可及嘉为IT咨询培训0 非功能性需求——性能需求分析 软件的非功能性需求是衡量软件质量很重要的一个因素,同时也决定了功能相似的条件下不同软件的价格。比如,一个同时能处理一万用户请求的网站的技术要求和一个没考虑过这方面问题的网站相比就有天壤之别。然而实际工作中,非功能性需求却常常被忽略,或者制定得非常随意。那么非功能性需求应该怎么制定,又如何验收呢? 下面我们以常见的非功能性需求——性能需求为例,介绍一下非功能性需求应该怎么制定和验证。 在许多网站开发项目中我们都会在合同或者招标说明中看到“本网站必须能同时满足多少用户的使用”,这就是一个针对性能的非功能性需求,不过这个需求定义的非常不专业。 首先,对于一个服务器系统来说同时在线的用户,或者并发用户数并不是一个清晰的概念。在线用户或者更具体的——和服务器保持连接的用户,如果不进行操作,那么除了占用一点服务器内存外没有任何开销。用户只有执行了向服务器发起请求在操作,服务器才需要消耗CPU、硬盘、网络和更多的内存资源来响应这些请求。因此性能指标应该使用每秒请求数来标定。虽然每秒请求数通常和并发用户数成正比,但由于应用不同、用户使用方式不同等原因。即使是同类型网站并发用户数和每秒请求数的比例也有很大的差别。具体的数字是多少就需要进一步的需求分析才能确定。 其次,这个需求没有限定系统响应时间。响应时间是性能需求中另一个重要指标。正确的性能需求是通常以一定平均响应时间条件下服务器的极限指标来描述的。 好了,我们知道制定性能需求需要每秒请求数和响应时间两个数值。那么这两个数值如何制定才合理呢?需要注意的是性能指标不是越高越好,高性能通常需要复杂的实现技术、更高的部署成本和更多的维护工时。因此制定性能需求绝对不能拍脑袋。 做性能需求分析通常有这么几个步骤: 1、确定参照系统 2、测量参照系统的性能指标 3、预测目标系统 4、计算目标系统性能指标 参照系统是一个和目标系统类似并且已经存在的系统。通常将要被目标系统替换的老系统就是一个很好的参照系统。需要注意的是如果新系统的业务或者技术基础变化很大,那么旧系统未必是一个好的参照系统。 测量参照系统的性能指标通常比较容易,比如对于IIS网站来说,打开日志记录至少一个业务周期(比如一周)或者几个典型时段的数据,然后可以使用各种专业工具进行分析。从这些日志我们很容易得到所谓的用户数和每秒请求数的关系,以及系统响应时间等参数。简单的统计有时甚至通过自行编写的程序来完成。 有了基本的参照数据,那么接下来拍脑袋决定的目标系统预测也会相对靠谱。最后计算目标系统的指标就是一些普通的算术问题了。

软件功能需求和非功能需求

*功能需求和非功能需求* 软件产品的需求可以分为功能性需求和非功能性需求,其中非功能性需求是常常被轻视,甚至被忽视的一个重要方面。其实,软件产品非功能性定义不仅决定产品的质量,还在很大程度上影响产品的功能需求定义。如果事先缺乏很好的非功能性需求定义,结果往往是使产品在非功能性需求面前捉襟见肘,甚至淹没功能性需求给用户带来的价值。 所谓非功能性需求,是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。下面对其中的某些指标加以说明。 1.系统的完整性 系统的完整性指为完成业务需求和系统正常运行本身要求而必须具有的功能,这些功能往往是用户不能提出的,典型的功能包括联机帮助、数据管理、用户管理、软件发布管理和在线升级等。 并不是所有的系统都必须包括以上所有的功能,而是可以根据产品的使用环境和企业的产品发展决策进行挑选。例如,在线升级、软件发布管理适用于具有Internet或内网环境的软件产品;数据管理对于产生数据存储的产品则是必须的,设计人员不应假设用户同时是一个合格的DBA。而且系统所产生信息的分布和关系,也不是DBA所应该了解的内容。因此完整的系统应该包括数据备份、恢复、日志管理及垃圾数据清除等基本功能,哪怕这些功能的核心只是一条语句或命令;用户管理功能是另一项必不可少的功能,它定义哪些用户可以以什么样的功能使用系统。好的用户管理功能不仅可以有效控制用户对系统的使用,使系统处于一个安全且负载合理的运行状况,还能提高系统的应用适应性。 2.系统的可扩充性与可维护性 指系统对技术和业务需求变化的支持能力。当技术变化或业务变化时,不可避免将带来系统的改变。不仅要进行设计实现的修改,甚至要进行产品定义的修改。好的软件设计应在系统架构上考虑能以尽量少的代价适应这种变化,常用的技术有面向对象的分析与设计及设计模式。 3.技术适应性与应用适应性 系统的适应性与系统的可扩充性和可维护性的概念相似,也表现产品的一种应变能力,但适应性强调的是在不进行系统设计修改的前提下对技术与应用需求的适应能力,软件产品的适应性通常表现为产品的可配置能力。好的产品设计可能要考虑到运行条件的变化,包括技术条件(网络条件、硬件条件和软件系统平台条件等)的变化和应用方式的变化,如在具体应用中界面的变化、功能的剪裁、不同用户的职责分配和组合等。 对以上重要的非功能性需求进行逐一分析后,即可开始进行产品功能设计。实际上,非功能性需求定义将反映到系统的功能设计中,表现为系统的架构。

软件开发需求文档模板

软件开发需求文档模板

目录

1. 范围 本指南用于指导软件开发者为南京市交通局开发软件项目的过程,通过规范软件项目承担单位的开发过程达到提高软件质量,降低维护成本的目的。开发者应根据本指南进行软件开发和编制软件开发文档。本指南是对软件项目承担单位的基本要求。在本指南的附录A至E中提供了文档的编写模板供开发者参考,在进行具体软件开发时,开发者可根据实际情况采编写,但必须提供双方约定的文档,文档中约定的内容必须描述清楚。 2. 总体要求 2.1 总体功能要求 网络应用环境以Internet/Intranet技术为核心。 开发者应在充分分析需求的基础上,选择采用B/S结构或者C/S结构。 软件系统的数据库应依照《南京市交通局信

息化数据库建设规范》进行设计和建设。 本指南中没有规定开发者采用何种具体的软件工程开发方法,开发者可根据项目具体特点、自身擅长来选择采用面向过程的方法、面向对象的方法或面向数据的方法,但建议开发商使用面向对象软件工程的方法,如:采用目前被广泛使用的RUP(Rational Unified Process)方法来进行分析、设计和开发。 2.2 软件开发平台要求 开发者开发的软件必须能够在南京市交通局规定的软件平台上正常运行。目前软件平台为: 数据库管理系统: Oracle 9i以上版本 中间件(应用服务器)系统: IBM WebSphere OA系统: Lotus Domino/Notes 网络架构: 完全支持TCP/IP协议 开发工具或技术体系:

为保证软件的上下兼容性,开发者应选择比较通用的开发工具的较新版本进行开发,如Microsoft Visual https://www.wendangku.net/doc/6c12712811.html,,Borland Delphi,C++ Builder, 或J2EE(Java2 P1atform Enterprise Edition)等。 2.3 软件项目的开发实施过程管理要求 2.3.1 软件项目实施过程总体要求 (一)开发者提交软件开发工作大纲,交通局组织专家组对工作大纲进行评审,并提出整改意见。 (二)通过评审后,开发者根据整改意见完善工作大纲,经过交通局认可后组织项目组进行软件开发。软件开发工作按照需求分析、概要设计、详细设计、编码、测试等几个阶段进行,在开发过程中,开发者需分阶段提交相关文档。 (三)在软件开发工作完成后,开发者应向交通局提交完整的软件文档,交通局组织验收组对软件进行验收审查。 2.3.2 软件项目实施变更要求 在开发过程中,需求或设计不可避免地需要

业务需求03非功能性需求模版

〈项目名称〉业务需求-非功能性需求 版本 <1.0> 文档编号: 当前版本: 1.0 修改日期:

修订文档历史记录

目录 1.简介4 1.1目的4 1.2范围4 1.3定义、首字母缩写词和缩略语4 1.4参考资料4 2.性能4 2.1交易响应时间4 2.2用户数5 2.3吞吐量需求5 2.4数据存储容量6 3.可扩展性6 4.伸缩性6 5.安全性7 5.1应用安全性需求7 5.1.1认证与授权服务7 5.1.2资源访问控制服务7 5.1.3应用日志7 5.2基础级安全需求7 5.2.1防火墙保护7 5.2.2防病毒服务7 5.2.3数据安全7 5.2.4入侵检测及漏洞扫描7 5.2.5数据传输服务7 6.可用性7 7.易用性8 8.可靠性8 8.1计划维护服务时间8 8.2单点故障对系统的影响程度8 8.3可恢复性8 8.3.1停机恢复8 8.3.2程序和数据的备份8 8.3.3灾难恢复8 9.业务约束9 9.1<业务约束-001>业务组织架构9 9.2<业务约束-002>语言要求9 10.技术约束9 10.1<技术约束-001>客户端规范9 10.2<技术约束-002>服务器规范9 10.3<技术约束-003>网络环境规范10 10.4<技术约束-004>外设规范10 10.5<技术约束-005>开发规范10

[说明:文档模板中蓝字部分为模板说明和示例,黑字部分为内容要求。黑字部分不允许删除,对于对项目不适用的部分,在相应的章节中进行说明。] 1.简介 1.1目的 [阐明业务需求文档中,非功能性需求文档的目的。] 1.2范围 [包括所有的非功能性需求。] 1.3定义、首字母缩写词和缩略语 [本小节应提供正确理解此非功能性需求文档所需的全部术语、首字母缩写词和缩略语的定义。这 些信息可以通过引用项目词汇表来提供。] 1.4参考资料 [列出与本业务有关的一些参考资料,以备出现业务疑问时,可以方便地追根溯源。每个文档应标 有标题、报告号(如果适用),如需要,列出文档的日期和发布组织。列出可从中获取这些引用的来 源。这些信息可以通过引用附录或其他文档来提供。] 2.性能 [与性能有关的非功能需求由以下几个单独的子需求组成:] 2.1交易响应时间 [交易可以定义为:一个交易是指一个单一角色跨越系统边界触发一个事件并执行一定数量的处 理和数据库访问。交易响应时间指完成目标系统中的交互或批量处理所需的响应时间。 根据业务处理类型的不同,本规范把交易划分为三类:交互类业务、查询类业务和大数据量批 处理类业务,并根据交易类别分别给出响应时间要求的参考值,包括峰值响应时间、平均响应时间。] ●交互类业务 [交互类业务的响应需求。] ●查询类业务 [查询类业务的响应需求,可以包括一些对信息进行分析的需求。] ●大数据量、批处理业务

软件开发需求分析模板

需求分析 1.引言 1.1目的 说明编写这份报告的目的,指出预期的读者。 1.2背景 指出待开发的软件系统的名称;行业情况;本项目的任务提出者、开发者、用户;该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3参考资料 列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、技术标准,以及他们的作者、标题、编号、发布日期和出版单位。 列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网 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输入输出要求 解释各输入输出数据类型,并逐项说明其媒体、格式、数值范围、精度等。 对系统的数据输出及必须标明的控制输出量进行解释并举例。

软件项目需求分析通用模板

1. 引言 1.1 目的 说明编写这份报告的目的,指出预期的读者。 1.2 背景 指出待开发的软件系统的名称;行业情况;本项目的任务提出者、开发者、用户;该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 参考资料 列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、技术标准,以及他们的作者、标题、编号、发布日期和出版单位。 列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网址。 1.4 术语 列出本报告中用到的专门术语的定义。

2. 任务概述 2.1 目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中的其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2 系统(或用户)的特点 如果是产品开发,应列出本软件的特点,与老版本软件(如果有的话)的不同之处,与市场上同类软件(如果有的话)的比较。说明本软件预期使用频度; 如果是针对合同开发,则应列出本软件的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长,以及本软件预期使用频度。这些是软件设计工作的重要约束。3. 假定和约束 列出进行本软件开发工作的假定和约束,例如经费限制、开发期限等。 4. 需求规定 4.1 软件功能说明 逐项定量和定性地叙述对系统所提出的功能要求,说明输入什么量、经怎样的处理、得到什么输出,说明产品的容量,包括系统应支持的终端数和应支持的并行操作的用户数等指标。 4.2 对功能的一般性规定

软件开发需求文档模板

目录 1. 范围.............................................................................................................. 错误!未定义书签。 2. 总体要求...................................................................................................... 错误!未定义书签。 2.1总体功能要求 ........................................................................................ 错误!未定义书签。 2.2软件开发平台要求 ................................................................................ 错误!未定义书签。 2.3软件项目的开发实施过程管理要求..................................................... 错误!未定义书签。 2.3.1 软件项目实施过程总体要求........................................................ 错误!未定义书签。 2.3.2 软件项目实施变更要求................................................................ 错误!未定义书签。 2.3.3 软件项目实施里程碑控制............................................................ 错误!未定义书签。 3. 软件开发...................................................................................................... 错误!未定义书签。 3.1软件的需求分析 .................................................................................... 错误!未定义书签。 3.1.1 需求分析........................................................................................ 错误!未定义书签。 3.1.2 需求分析报告的编制者................................................................ 错误!未定义书签。 3.1.3 需求报告评审................................................................................ 错误!未定义书签。 3.1.4 需求报告格式................................................................................ 错误!未定义书签。 3.2软件的概要设计 .................................................................................... 错误!未定义书签。 3.2.1 概要设计........................................................................................ 错误!未定义书签。 3.2.2 编写概要设计的要求.................................................................... 错误!未定义书签。 3.2.3 概要设计报告的编写者................................................................ 错误!未定义书签。 3.2.4 概要设计和需求分析、详细设计之间的关系和区别 ................ 错误!未定义书签。 3.2.5 概要设计的评审............................................................................ 错误!未定义书签。 3.2.6 概要设计格式................................................................................ 错误!未定义书签。 3.3软件的详细设计 .................................................................................... 错误!未定义书签。 3.3.1 详细设计........................................................................................ 错误!未定义书签。 3.3.2 特例................................................................................................ 错误!未定义书签。 3.3.3 详细设计的要求............................................................................ 错误!未定义书签。 3.3.4 数据库设计.................................................................................... 错误!未定义书签。 3.3.5 详细设计的评审............................................................................ 错误!未定义书签。 3.3.6 详细设计格式................................................................................ 错误!未定义书签。 3.4软件的编码 ............................................................................................ 错误!未定义书签。 3.4.1 软件编码........................................................................................ 错误!未定义书签。 3.4.2 软件编码的要求............................................................................ 错误!未定义书签。 3.4.3 编码的评审.................................................................................... 错误!未定义书签。 3.4.4 编程规范及要求............................................................................ 错误!未定义书签。 3.5软件的测试 ............................................................................................ 错误!未定义书签。 3.5.1 软件测试........................................................................................ 错误!未定义书签。 3.5.2 测试计划........................................................................................ 错误!未定义书签。 3.6软件的交付准备 .................................................................................... 错误!未定义书签。 3.6.1 交付清单........................................................................................ 错误!未定义书签。 3.7软件的鉴定验收 .................................................................................... 错误!未定义书签。 3.7.1 软件的鉴定验收............................................................................ 错误!未定义书签。

相关文档