软件需求说明书内容都包括哪些
规范化软件开发过程中的《需求说明书》的编写,使之成为整个开发工作的基础。
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 引言 1.1 编写目的:阐明编写需求说明书的目的,指明读者对象。
1.2 项目背景:应包括 ● 项目的委托单位、开心单位和主管部门; ● 该软件系统与其他系统的关系。
1.3 定义:列出文档中所用到的专门术语的定义和缩写词的愿文。
1.4 参考资料:可包括 ● 项目经核准的计划任务书、合同或上级机关的批文 ● 文档所引用的资料、规范等 1.5其他说明: 前期开发为客户关系管理中的客户管理和市场管理、决策支持中的客户信息部分 2 任务概述 2.1 目标 2.2 运行环境 2.3 条件与限制 3 数据描述 3.1 表态数据 3.2 动态数据:包括输入数据和输出数据。
3.3 数据库描述:给出使用数据库的名称和类型。
3.4 数据词典 3.5 数据采集 4 功能需求 4.1功能划分...
需求分析应包括哪些内容?
需求分析包括这些内容1 、写出系统的任务和特点2 、要实现的功能模块和作用3、 系统结构图4 、采用的数据库5 、开发运行环境"需求分析",是指对要解决的问题进行详细的分析,弄清楚问题的要求,包括需要输入什么数据,要得到什么结果,最后应输出什么。
在软件工程当中的"需求分析"就是确定要计算机"做什么",要达到什么样的效果。
软件需求分类有哪些
软件需求的定义;IEEE软件工程标准词汇表(1997年)中定义需求为:(1)用户解决问题或达到目标所需的条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。
简单的就是:用户需求;用户需要在应用系统中实现什么东西,为实现这个目标,需要用户提供的全部的详细的业务说明,业务流程,表格样式等。
功能需求;将用户需求归类分解为计算机可以实现的子系统和功能模块,用设计语言描述和解释用户的需求,以达到可以指导程序设计的目的。
...
什么是软件需求,什么是功能需求?
我们的软件产品或者项目,其需求都有三个层级和三个方面。
一、我们首先看需求的三个层次软件需求包括3个不同的层次――业务需求、用户需求和功能需求。
业务需求 (Business requirement)表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
业 务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。
使用前景和范围(vision and scope)文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(project charter 或 market requirement)文档。
用户需求 (user requirement)描述的是用户的目标,或用户要求系统必须能完成的任务。
用例、场景描述和事件――响应表都是表达用户需求的有效途径。
也就是说用户需求描述了用户能使用系统来做些什么。
功能需求 (functional requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。
功能需求有时也被称作行为需求 (behavīoral requirement),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。
功能需求描述是开发人员需要实现什 么。
注意:用户需求不总是被转变成功能需求。
产品特性,所谓特性(feature),是指一组逻辑上相关的功能需求,它们为用户提供某项功能,使业务目标 得以满足。
对商业软件而言,特性则是一组能被客户识别,并帮助他决定是否购买的需求,也就是产品说明书中用着重号标明的部分。
客户希望得到的产品特性和用 户的任务相关的需求不完全是一回事。
一项特性可以包括多个用例,每个用例又要求实现多项功能需求,以便用户能够执行某项任务。
系统需求 (system requirement)用于描述包含有多个子系统的产品(即系统)的顶级需求。
系统可以只包含软件系统,也可以既包含软件又包含硬件子系统。
人也可以是系统的一部分,因此某些系统功能可能要由人来承担。
业务规则 包 括企业方针、政府条例、工业标准、会计准则和计算方法等。
业务规划本身并非软件需求,因为它们不属于任何特定软件系统的范围。
然而,业务规则常常会限制谁 能够执行某些特定用例,或者规定系统为符合相关规则必须实现某些特定功能。
有时,功能中特定的质量属性(通过功能实现)也源于业务规则。
所以,对某些功能 需求进行追溯时,会发现其来源正是一条特定的业务规则。
功能需求记录在软件需求规格说明(SRS)中。
SRS完整地描述了软件系统的预期特性。
SRS我们一般把它当作文档,其实,SRS还可以是包含需求信息的数据库 或电子表格;或者是存储在商业需求管理工具中的信息;而对于小型项目,甚至可能是一叠索引卡片。
开发、测试 、质量保证、项目管理和其他 相关的项目功能都要用到 SRS。
除此之外,对于需求层次,我们还有其它的分法:组织级需求->业务需求->用户需求->功能需求(有时也叫行为需求)。
组织级需求: 一 般代表着组织的愿景和目标。
对于大的公司,一般是通过资深的咨询顾问和咨询公司得出的,呈现的方式是咨询报告。
比如在ITSM或者企业信息化这方面。
典型 的组织级的需求是:降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。
业务需求: 是要完组织的使命,达成组织的愿景的各个业务流程和业务单元具有的需求。
业务需求服从于组织需求。
用户需求: 用户级的需求,是在业务级的需求下,各个岗位协作完成业务而具有的需求。
我们在软件需求规格说明书中表述的需求其实主要是这一部分需求。
功能需求: 同样,它代表着产品或者软件需求具备的能力。
一般是管理人员或者产品的市场部门人员负责定义软件的业务需求,以提高公司的运营效率(对信息系统而言)或产品的市场竞争力(对商业软件而言)。
所有的用 户需求都必须符合业务需求。
需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。
开发人员则根据功能需求和非功能需求设计解决方案,在约束条 件的限制范围内实现必需的功能,并达到规定的质量和性能指标。
当一项新的特性、用例或功能需求被提出时,需求分析员必须思考一个问题:“它在范围内 吗?”。
如果答案是肯定的,则该需求属于需求规格说明,反之则不属于。
但答案也许是“不在,但应该在”,这时必须由业务需求的负责人或投资管理人来决定: 是否扩大项目范围以容纳新的需求。
这是一个可能影响项目进度和预算的商业决策。
二、需求的三个方面 除了功能需求外,SRS中还包含非功能需求,包括性能指标和对质量属性的描述。
质量属性 (quality attribute)对产品的功能描述作了补充,它从不同方面描述了产品的各种特性。
这些特性包括可用性、可移植性、完整性、效率和健壮性,它们对用户或 开发人员都很重要。
其他的非功能需求包括系统与外部世界的外部界面,以及对设计与实现的约束。
还有一项称为可用性(usability)的质量属性,它规 定了业务需求中“有效”(efficiently)一词的含义。
约束(constraint)限制了开发人员设计和构建系...
软件需求工程有哪些过程?
一、 开始 1. 项目经理根据项目特点,指定对过程表格的具体要求; 2. 项目经理制订项目的标准,包括:DTS(缺陷类型)、TRA(风险类型)、TRS(需求类型)等,在过程表格中按标准引用. 二、 计划 1. 计划经理估算需求开发时间; 2. 计划经理完成:SPT(进度计划)、TPT(任务计划),将计划数据录入PDS(项目计划摘要). 三、 需求获取 1. 软件需求工程师搜集系统概要信息,填写REQ(需求获取概貌); 2. 软件需求工程师搜集用户需求,分类并清晰地把需求写入REA(需求获取/分析)、RES(需求获取情节)、UIR(用户交互需求); 3. 检查需求获取过程,并填写REC(需求获取检查); 4. 如果检查不通过,从1.重头开始过程; 5. 软件需求工程师填写TRL(时间记录日志)、PIP(过程改进建议); 6. 计划经理整理本阶段数据,录入SPT、TPT. 四、 需求分析 1. 软件需求工程师进行需求分析,建立分析模型,数据字典及项目词汇表,完成REA(分析模型的具体要求,请分别参见结构化分析和面向对象分析的具体作业指导书); 2. 软件需求工程师将发现的需求的冲突、交迭、冗余或矛盾,记入NCR; 3. 检查需求分析,完成RAC(需求分析检查); 4. 如果检查不通过,从1重头开始过程; 5. 软件需求工程师填写TRL、PIP; 6. 计划经理整理数据,录入TPT、SPT. 五、 协商 1. 软件需求工程师利用NCR,与风险承担者协商解决需求分析中发现的问题,将决议录入NCR; 2. 软件需求工程师根据决议,修改REA等相关文档; 3. 如果有新的需求引入,需要重新进行需求分析阶段; 4. 软件需求工程师填写TRL、PIP; 5. 计划经理整理数据,录入TPT、SPT. 六、 需求评审 1. 评审小组负责人拟定检查清单,为成员分派检查任务,制订评审日程表; 2. 评审员各自评审分派的内容,将发现的问题录入DRL(缺陷记录日志); 3. 评审小组负责人组织评审会议,各小组成员提交DRL并讨论; 4. 评审小组以IRF形式提交检查报表; 5. 软件需求工程师根据IRF修订相关文档; 6. 计划经理整理数据,录入TPT、SPT。
七、 需求文档编写 1. 软件需求工程师综合考虑功能需求和非功能需求,编写《软件需求说明书》 《软件需求说明书》的编写格式与要求,请参见具体的作业指导书。
2. 利用RDC检查《软件需求说明书》是否全面、正确并可执行; 3. 如果检查不通过,从1重头开始过程; 4. 软件需求工程师填写TRL、PIP; 5. 计划经理整理数据,录入TPT、SPT。
八、 需求确认 1. 评审小组,对需求进行确认: l 确认每一个需求及相互关系; l 需求的总体质量达到标准。
将结果写到RVC。
2. 软件需求工程师根据RVC,修订需求文档,并最终通过; 3. 软件工程师为每一个需求设计测试用例,并录入TRF; 4. 相关人员填写TRL、PIP; 5. 计划经理整理数据,录入TPT、SPT。
九、 配置管理 1. RD(需求文档)成为基线后,即纳入到配置管理; 2. 如果需要对基线RD(需求文档)进行修改,填写CCP; 3. 配置管理人员征求需求开发小组和其他相关人员(风险承担者)关于CCP的意见; 4. 如果所有人员通过CCP,则将需求文档的配置管理取出,并填写CCF; 如果否决需求,则填写RRF; 5. 软件需求工程师修改RD以适应新的需求 (可能包括REA等); 6. 评审小组对修改的RD执行第八步; 7. 相关人员填写TRL、DRL. 十、 事后分析 1. 计划经理将DRL、TRL、需求增长率,整理到PPS; 2. 小组分析SREP过程,找出需要改进的地方,填写PIP,并提交质量经理; 3. 小组建立未来过程的改进目标.
转载请注明出处51数据库 » 软件需求包括哪些方面