软件需求规格说明包括 软件需求规格说明文档
发布日期:2020-10-11摘要:软件需求规格说明有哪些特点? 1 完整性 不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息,用TBD (“待确定” )作为标...
软件需求规格说明有哪些特点?
1. 完整性 不能遗漏任何必要的需求信息。
遗漏需求将很难查出。
注重用户的任务而不是系统的功能将有助于你避免不完整性。
如果知道缺少某项信息,用TBD (“待确定” )作为标准标识来标明这项缺漏。
在开始开发之前,必须解决需求中所有的TBD项。
2. 一致性 一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。
在开发前必须解决所有需求间的不一致部分。
只有进行一番调查研究,才能知道某一项需求是否确实正确。
3. 可修改性 在必要时或为维护每一需求变更历史记录时,应该修订SRS。
这就要求每项需求要独立标出,并与别的需求区别开来,从而无二义性。
每项需求只应在SRS中出现一次。
这样更改时易于保持一致性。
另外,使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。
4. 可跟踪性
软件需求说明书内容都包括哪些
规范化软件开发过程中的《需求说明书》的编写,使之成为整个开发工作的基础。
2 适用范围本规范适用于集团开发项目的(软件)《需求说明书》的编写。
3 编写内容提示1 引言3.1.1 背景说明说明被开发软件的名称,任务提出者,用户及实现该软件的计算机网络。
3.1.2 参考资料列出有关资料(名称,发表日期,出版单位,作者等)。
3.1.3 术语和缩写词列出本文件中用到的专门术语的定义,及术语缩写词。
3.2 软件总体概述3.2.1 目标软件开发的意图、应用目标、作用范围以及需说明背景材料。
3.2.2 系统模型图示说明该软件的所有功能及其相互关系和数据传递情况。
3.2.3 假设和约束说明影响软件开发、运行环境和系统能力(如预告出错类型的能力)的某些假设和约束。
3.3 详细需求详细描述此软件系统的功能需求和性能需求。
3.3.1 功能需求对系统中每一个功能,要详细描述(图示或文字)。
概述 叙述功能名称,目标和作用。
输入 输入该功能的信息。
处理 描述该功能做什么,如何对输入信息进行加工并转换成输出信息。
输出 列出内部生成的文件。
3.3.2 性能需求定量地描述此软件系统应满足的具体性能需求。
可考虑以下方面:3.3.2.1精度说明系统的精度要求,如:数据的精度要求。
数字计算的精度要求。
数据传送的误码率要求。
3.3.2.2 时间特性说明系统的时间特性要求,如:解题时间。
询问和更新数据文件的响应时间。
系统各项功能的顺序关系。
3.3.2.3 灵活性说明当需求发生某些变化时系统的适应能力,指出为适应这些变化而需要设计的软件成分和过程。
3.3.2.4系统容量包括系统的设计容量和理论(计算)容量。
3.3.3 输入和输出解释各输入输出数据类型,并逐项说明某媒体、格式、数值范围等。
对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。
3.3.4 数据管理能力说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作估算。
3.3.5 故障处理列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.4 环境描述所开发软件运行所需的环境。
3.4.1 设备环境描述运行软件系统所需的设备能力,如:处理器的型号和内存容量。
存储媒体的数量。
通信网络(包括说明网络结构,线路速度及通讯协议等)。
3.4.2 支持软件环境列出与待开发的软件互相配合的支持软件(包括名称,版本号和文件资料),必要时还应列出测试软件,还要指出该软件用的编程语言,编译程序,操作系统和数据管理系统。
3.4.3 接口说明本软件与其他软件之间的接口、数据通信协议等。
3.4.4其他说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。
软件需求规格说明起到什么作用?
规范化软件开发过程中的《需求说明书》的编写,使之成为整个开发工作的基础。
2 适用范围本规范适用于集团开发项目的(软件)《需求说明书》的编写。
3 编写内容提示1 引言3.1.1 背景说明说明被开发软件的名称,任务提出者,用户及实现该软件的计算机网络。
3.1.2 参考资料列出有关资料(名称,发表日期,出版单位,作者等)。
3.1.3 术语和缩写词列出本文件中用到的专门术语的定义,及术语缩写词。
3.2 软件总体概述3.2.1 目标软件开发的意图、应用目标、作用范围以及需说明背景材料。
3.2.2 系统模型图示说明该软件的所有功能及其相互关系和数据传递情况。
3.2.3 假设和约束说明影响软件开发、运行环境和系统能力(如预告出错类型的能力)的某些假设和约束。
3.3 详细需求详细描述此软件系统的功能需求和性能需求。
3.3.1 功能需求对系统中每一个功能,要详细描述(图示或文字)。
概述 叙述功能名称,目标和作用。
输入 输入该功能的信息。
处理 描述该功能做什么,如何对输入信息进行加工并转换成输出信息。
输出 列出内部生成的文件。
3.3.2 性能需求定量地描述此软件系统应满足的具体性能需求。
可考虑以下方面:3.3.2.1精度说明系统的精度要求,如:数据的精度要求。
数字计算的精度要求。
数据传送的误码率要求。
3.3.2.2 时间特性说明系统的时间特性要求,如:解题时间。
询问和更新数据文件的响应时间。
系统各项功能的顺序关系。
3.3.2.3 灵活性说明当需求发生某些变化时系统的适应能力,指出为适应这些变化而需要设计的软件成分和过程。
3.3.2.4系统容量包括系统的设计容量和理论(计算)容量。
3.3.3 输入和输出解释各输入输出数据类型,并逐项说明某媒体、格式、数值范围等。
对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。
3.3.4 数据管理能力说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作估算。
3.3.5 故障处理列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.4 环境描述所开发软件运行所需的环境。
3.4.1 设备环境描述运行软件系统所需的设备能力,如:处理器的型号和内存容量。
存储媒体的数量。
通信网络(包括说明网络结构,线路速度及通讯协议等)。
3.4.2 支持软件环境列出与待开发的软件互相配合的支持软件(包括名称,版本号和文件资料),必要时还应列出测试软件,还要指出该软件用的编程语言,编译程序,操作系统和数据管理系统。
3.4.3 接口说明本软件与其他软件之间的接口、数据通信协议等。
3.4.4其他说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。
一道软件工程的选择题软件需求规格说明书的内容不应该包括()。
...
如何理解“规格说明必须容忍不完整和可扩充”。
我们把描述需求的文档叫做软件需求规格说明书,同时为确切表达用户对软件的输入输出要求,还需要制定数据要求说明书及编写初步的用户手册。
需求规格说明书是用户和开发者之间的一个协约。
实际的需求获取过程中,存在若干风险,包括用户参与不足,需求不断增加,需求模棱两可等等,用户由于不明白需求分析的重要性,有时只做一份很简略的规格说明,仅涉及到产品概念上的内容,而希望开发人员在开发过程中去完善,这种情况下的规格说明势必不够完整,需要开发过程中双方不断完善和补充。
另一方面,由于在需求阶段,很多需求细节客户自己未必清楚,因此这一阶段也无法达成一个一成不变的规格说明,必须允许客户在开发过程中不断明确自己的需求,这就要容忍规格说明不完整和可扩充。
网站开发需求规格说明书怎么写?
1 是否有需求与其他需求相互冲突或者重复? 通常一份长达几百页的需求规格说明书都不会是一蹴而就的,它可能是系统分析师几个夜晚的心血之作。
正是因为撰写过程的连续性,可能导致同一份文档中前后名词定义不一致,前后观点上有重叠或差异的情况出现,这需要我们在撰写报告前首先要在思想上形成统一概念, 可使术语列表贯穿整份文档以达提纲挈领之效。
谈及此点,让我想起在“商机管理系统”需求评审会上,火眼金睛的用户们发现了我的需求说明书中关于系统用户角色定义部分出现了前后不一致的情况。
在该报告前文中我定义了该系统有二种角色,即“商机成员”、“商机管理成员”,但在功能需求中我的报告中居然新生出一种“商机监理”角色,导致出现尴尬局面。
事后总结其主要原因是在撰写报告的前期和后期阶段,需求分析的思路有了明显的异动,但却没有把文档前后更新一致,这个教训是深刻的,时至今日记忆犹新。
2 是否清晰、简洁、无二义地表达了每个需求? “清晰”是让人能够读懂;“简洁”是让人愿意去读;“无二义”决定”读”的效果,是让大家对需求描述的理解能够达成一致 。
需求陈述是“三重门”,这三扇门是否开启决定了需求说明书的质量高低。
我们尤其要拒绝“二义性”的名词术语的出现, 似是而非的概念定义是需求书应该避免的。
换句话说,如果一份需求说明书没能给人以清晰、简洁和无二义的阐述,则需求评审是没有进行下去的必要,同时也无法进行下去。
需求评审的前提是用户读懂了需求说明,并且用户的理解内容就是分析师们所描述的内容。
3 是否每个需求都通过了演示、测试、评审,分析是否得到了验证? 需求应该是可以测试的,通常通过测试去验证它是不是正确。
比如我们完成了“销售员客户佣金提成规则”需求的撰写,如果需求书未能经过原型测试通过,则需求评审是不能得到通过的。
面对相当复杂的业务需求,经过测试或演示是让用户信任的一个必要过程。
试想一下, 如果连需求都不能很好地被确认,则开发实现阶段更是没有把握控制了。
4 是否每个需求都在项目的范围内? 划分项目范围和区分系统边界同样是需求说明书的一个任务,不要对需求书作出超范围的论述和延伸,要知道需求书不是分析师卖弄概念、展示时尚的场所,它是软件工程的一个重要环节。
5 是否每个需求都没有内容和语法上的错误? 按照传统的需求列表方式,需求像菜单一样被一条条列出来,构成需求项的主要栏位包括:需求ID、 需求描述、优先级、来源和状态等。
通常需求首先要经过“拼写检查”,保证没有拼写上的问题,然后通过逐行浏览修改那些在内容或行文上出现问题的需求。
6 在现有的资源内, 是否能实现所有的需求? 需求规格说明要考虑可行性的问题。
事实上,分析师的关注层面是价值驱动和成本驱动方面。
分析师应该明白不是所有的需求都要去实现,一些看上去很明显与涉及用户有冲突的、费力不讨好的需求应该果断地舍弃。
国内有专家提出,搞需求也要讲“和谐”即是此中道理。
举例而言,企业中的用户可分为三种类型:决策层用户、管理层用户、操作层用户。
每种用户所代表的价值取向是不同的,决策和管理层希望系统处理业务是业务安全优先的,而操作系统用户则是更多地考虑方便性的。
国内某电子贸易公司,从自身业务安全考虑,规定了系统不允许“借货”,意即代理商的产品直接发到客户根本不经过本贸易公司的物流部门。
如果操作层用户提出了这样的“借货”需求,倒是可以方便他的日常处理,但却违背了公司的根本利益。
很显然,这样的需求肯定是有所不为的。
7 每一条特定的错误信息,是否都是唯一的和具有含义的? 不要忽视错误信息的定义, 它必须具有唯一性。
如果过于笼统地定义错误信息则和没有定义的效果是一样的。
-
给我们打电话
7*24小时服务热线:1399999999
全国客服热线:400-0000-000 -
百度地图
福建省三明市 -
给我们发邮件
E-mail:[email protected]
在线沟通