规范化软件开发过程中的《需求说明书》的编写,使之成为整个开发工作的基础。
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、BUG描述报告(主要可以包括,测试环境的介绍,预置条件,测试人员,问题重现的操作步骤和当时测试的现场信息),
5、整个项目的测试报告(从设计和执行的角度上来对此项目测试情况的介绍,从分析中总结此次设计和执行做的好的地方和需要努力的地方和对此项目的一个质量评价)。
那测试用例要怎么写?从哪得来的那
软件开发需要哪些文档?
可行性研究报告、需求规格说明书、项目计划、软件测试计划、概要设计说明书、详细设计说明书、编程规范、软件测试用例、软件测试报告、用户手册、安装手册、项目总结报告
在软件开发中,需求分析阶段产生的主要文档是什么?
当然是需求规格说明书啊。描述客户为什么要做这个软件,描述软件都实现什么功能,如何实现,实现是都需要什么样的条件和数据。以及软件的运行环境及对软件的硬性要求。
项目需求分析文档都包括哪些内容
需求分析是指理解用户需求,就软件功能与客户达成一致,估计软件风险和评估项目代价,最终形成开发计划的一个复杂过程在这个过程中,用户的确是处在主导地位,需求分析工程师和项目经理要负责整理用户需求,为之后的软件设计打下基础。需求分析阶段包括:
业务需求——反映了组织机构或客户对系统、产品高层次的目标要求,通常在项目定义与范围文档中予以说明。
用户需求——描述了用户使用产品必须要完成的任务,这在使用实例或方案脚本中予以说明。
功能需求——定义了开发人员必须实现的软件功能,使用户利用系统能够完成他们的任务,从而满足了业务需求。
非功能性的需求——描述了系统展现给用户的行为和执行的操作等,它包括产品必须遵从的标准、规范和约束,操作界面的具体细节和构造上的限制。
需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
什么是软件需求?包括哪些层次
我们的软件产品或者项目,其需求都有三个层级和三个方面。 一、我们首先看需求的三个层次 软件需求包括3个不同的层次――业务需求、用户需求和功能需求。 业务需求(Business requirement)表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。使用前景和范围(vision and scope)文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(project charter 或 market 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. 摘要 3. 系统详细需求分析 3.1. 详细需求分析 3.1.1. 详细功能需求分析 3.1.2. 详细性能需求分析 3.1.3. 详细信息需求分析 3.1.4. 详细资源需求分析 3.1.5. 详细组织需求分析 3.1.6. 详细系统运行环境及限制条件需求分析 3.1.7. 信息要求 3.1.8. 性能要求 3.2. 接口需求分析 3.2.1. 系统接口需求分析 3.2.2. 现有软、硬件资源接口需求分析 4. 总体方案设计4.1. 系统总体结构 4.1.1. 系统组成、逻辑结构 4.1.2. 应用系统结构 4.1.3. 支撑系统结构 4.1.4. 系统集成 4.1.5. 系统工作流程
.2. 分系统详细界面划分 4.2.1. 应用分系统与支撑分系统的详细界面划分 4.2.2. 应用分系统之间的界面划分 5. 应用分系统详细设计 5.1. XX分系统详细需求分析 5.1.1. 功能详细需求分析 5.1.2. 性能详细需求分析 5.1.3. 信息详细需求分析 5.1.4. 限制条件详细分析 5.2. XX分系统结构设计及子系统划分 5.3. XX分系统功能详细设计 5.4. 分系统界面设计 5.4.1. 外部界面设计 5.4.2. 内部界面设计 5.4.3. 用户界面设计 6. 数据库系统设计 6.1. 设计要求 6.2. 信息模型设计 6.3. 数据库设计 6.3.1. 数据访问频度和流量 6.3.2. 数据库选型 6.3.3. 异构数据库的连接与数据传递方式
6.3.5. 数据共享方式设计 6.3.6. 数据安全性及保密设计 6.3.7. 数据字典设计
8. 信息编码设计 8.1. 代码结构设计 8.2. 代码编制 9. 关键技术 9.1. 关键技术的提出 9.2. 关键技术的一般说明 9.3. 关键技术的实现方案 10. 系统配置 10.1. 硬件配置 10.2. 软件配置 11. 限制 12. 组织机构及人员配置 12.1. 机构调整与确认 12.2. 组织机构的任务和职责 12.3. 人员配置方案 12.4. 培训计划 13. 工程实施计划 13.1. 分期实施内容 13.2. 进度计划 13.3. 实施条件 13.4. 测试与验收 14. 投资预算 15. 参考和引用资料
16. 术语
这里还有很需要补充的,也有很多是可以不写的;因为一份需求文档不是谁能写的,呵呵,在实际的工作中
是那些负责人才能写这个的。如果是课设的话,只要在流程图 逻辑结构 或者是XX分系统的设计图上下点功夫就好了。说到格式 就是按上面的写 然自己弄一个目录 就像是我们平时翻书的时候看到的那种,这样好阅读。
产品经理都需要写哪些文档,会哪些软件?
一、PRD的含义
PRD英文全称Product Requirement Document,中文意思是:产品需求文档。 PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档,其作用就是“对MRD中的内容进行指标化和技术化”,这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
二、MRD的含义
MRD英文全称Market Requirement Document,中文意思是:市场需求文档。 该文档在产品项目中是一个“承上启下”的作用,“向上”是对不断积累的市场数据的一种整合和记录,“向下”是对后续工作的方向说明和工作指导。 作用是:产品项目由“准备”阶段进入到“实施”阶段的第一文档,其作用就是“对年度产品中规划的某个产品进行市场层面的说明”,这个文档的质量好坏直接影响到产品项目的开展,并直接影响到公司产品战略意图的实现。
三、BRD的含义
BRD,英文全称为:Business Requirement Document;中文意思是:商业需求描述。 基于商业目标或价值所描述的产品需求内容文档(报告),其核心的用途就是用于产品在投入研发之前,由企业高层作为决策评估的重要依据。BRD是产品生命周期中最早的文档,再早就应该是脑中的构思了,其内容涉及市场分析,销售策略,盈利预测等,通常是供决策层们讨论的演示文档,一般比较短小精炼,没有产品细节。
四、PRD、MRD、BRD之间的关系
1、PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明,而产品需求本身是在MRD中有所体现的。
2、MRD侧重的是对产品所在市场、客户(client)、购买者(buyer)、用户(user)以及市场需求进行定义,并通过原型的形式加以形象化。
3、如果说PRD的好坏,直接决定了项目的质量水平;那么BRD的作用,就是决定了你的项目的商业价值。 PRD、BRD和MRD,一起被认为是从市场到产品需要建立的文档规范。
1、Axure RP(Rapid Prototyping)
Axure(读音为Ack-Sure)无疑是目前最受关注的原型开发工具,其能通过组件的方式帮助网站或软件设计师快速建立带有注释的原型(流程图、线框图),并凭借自定义可重用的元件、动态面板以及丰富的script能够建立基本功能或页面逻辑的动态演示文件。
Axure借鉴了office的界面,能够让用户快速上手,并且提供了丰富的组件样式修改,使得通过其能够创建低保真、高保真甚至接近于实际效果的界面。然而最让人称道的是,Axure的丰富的脚本模式,可以通过点击和选择能够快速完成界面元素的交互,如链接、state切换、动态变化等效果,使得Axure能够生成十分接近于真实产品的原型。另一方面,Axure能够导入其他人创建的元件库,使得Axure能够满足绝大多数类型产品的设计。
但Axure仍然有一个让人头痛的问题:对于中文的支持不太友好。在小部分元件上输入中午的时候,经常需要像碰运气似的反复切换输入法,破坏了咱们设计师的用户体验。
瑕不掩瑜,Axure仍然是交互设计师的首选原型工具。
2、Microsoft Office Visio
Visio在2000年被微软收购,并在2002年成为office2003套件中的一个组件,最新版本是2007。Visio能够获得推荐的原因是因为Visio的适用性非常之广,从网站界面、数据库模型,到平面布置图到工艺流程图,Visio都提供了相应的元件库和模板来进行快速创建。
相较Axure而言,Visio更适合于传统行业的生产或流程设计,或者软件及互联网行业中的信息、数据和流程的说明,而不太适用于web界面。因为其的基于web的元件库还是比较少,并且形式和结构也更类似于word中的图形工具,因此在原型开发效率上都有所不足。
3、Balsamiq Mockups
这个基于Adobe AIR Runtime的工具实在是有让人眼前一亮的感觉,手绘风格的元件样式粗犷淋漓,能创建接近于纸上手绘的原型文件。其提供了丰富的手绘风格的web常用元件,包括常用的html控件、以及一些组合控件,如多媒体控制器、标签页、列表、Iphone界面元件等。
Mockups最值得赞赏之处在于其提供的多数组件都可定制外观,对于中文的支持也不错(选择View > Use System Fonts)。
4、Mockflow
Mockflow和以上工具最大的不同在于Mockflow是一项基于Adobe Flex技术开发在线服务,提供了与Balsamiq Mockups基本相似的功能,甚至更丰富的组件,虽然其元件定制化不够强大,但其提供的元件库默认样式却非常适合用来做商业产品原型的搭建。有一个让我爱不释手的功能是模板,可以设置基于任何页面的模板来进行新的页面设计。
与其他模板工具相比,mockflow有一个非常特色的功能,基于web的存储可以在任意电脑上联机打开,同时可以其他人进行快速的分享,并收集在线反馈意见,非常适合虚拟团队的原型设计交流。
虽然在线服务的基本帐号只能创建一个文件,但单个文件却没有限制页数,因此也基本上足够使用。
5、Pencil sketch
Pencil 是一款基于Firefox的扩展组件,安装之后即可在Firefox的工具菜单中打开Pencil的绘图面板。功能比较简单,仅能用以日常简单工作的辅助 说明。提供的默认元件都是基于软件工程,因此更适合用于windows桌面程序的简易界面搭建,或者是基本的页面功能说明,并不适用于严肃的原型开发,但 好在体积小、又轻便,能够方便将网页中的元素直接拖到或者复制到当前的画布中,这也是Pencil安装在Firefox所带来的便利之一吧。
更多工具...
在以上列举的原型开发工具都是较为常用的,也是在国内的交互设计师们比较常讨论的,但其实和Axure功能相似的软件还有很多,下面也就一些简单说明:
6、GUI Design Studio
这 是一款真的非常强大的原型制作工具,没有在上面推荐的原因是因为我还没有实际体验过,但冲着这工程级的界面设计就没有去尝试的冲动,但是从官方网站的截图 和视频演示来看,这款软件的操作模式和前面的原型工具大有不同。Axure之类多是基于页面的原型设计,对于web网站尽管很实用,但是对于软件界面的流 程设计却略显繁琐。而GUI Design Studio却另辟蹊径,直接以建立元素与元素之间的关联的方式来自动化的创建动作流程,而从视频演示来看,这样的确很大程度上提升了软件界面原型搭建的 效率。
7、Prototype Composer
Serena 公司免费提供的原型开发工具,功能确实强大,提供了基于项目管理主要流程的产出物文档模板、原型工具以及开发流程控制,这个软件的开发理念非常好,用这一 款工具来满足项目开发流程中各个环节的沟通和决策。但软件的学习和使用成本比较高,要了解其中的全部功能,貌似需要花不少时间。另外软件的效率和稳定性还 有待提高,试用的过程中多次出错及停止响应。
8、Lucid Spec
由 Elegance科技推出的Lucid Spec是一款很类似Pencil的原型工具,仅仅是提供了更多控件。不过Lucid Spec强调了生成干净的说明文档的功能,这可能是针对于多数原型工具的自动化生成规范的冗余而言的,不过老实说Lucid Spec提供的原型界面太过简陋,并且生成的说明文档也未见优化有怎样的提升。视频介绍
9、Irise Professional Edition
Irise与其他原型工具相比其中一个特色在于提供了样本数据的功能,这是类似于excel表的一个样本数据库,可以通过界面元素直接获取样本数据库中的数据,这样所生成的原型甚至可以使动态数据更新的。
10、Adobe Reader
Adobe reader?没错。其实理论上任何可以创建图形和文本的工具都可以用来原型开发,因为原型本身就是对于业务逻辑和功能界面的模拟或仿真,因此有何理由不能使用PDF格式呢?BoxandArrow的这篇文章《PDF Prototype》提醒了我们,所有的原型工具都只是工具,而不是设计本身。
另外这里的也可参考一下.http://www.oschina.net/project/tag/291/ui-design/
但个人推荐:
原型
• Axure 7.0
• UIDesigner
思维
• Mindmanager
• Xmind
流程
• Visio 2013
• EDraw Max
知识
• 有道云笔记
• 印象笔记
时间
• Todolist
• Worktile
图形
• Photoshop
• Colorpix
交互
• 快现
• UIDesiger
转载请注明出处51数据库 » 软件需求文档有哪些 产品需求文档应该包含哪些内容