第一篇:《××项目软件需求变更说明书》
软件需求变更说明书
项目名称: 长益高速收费数据分析系统一、概述
因湖南省高速公路联网拆分系统软件升级,导致长益下属收费站入口和出
口交易数据、拆分数据、代收拆分数据无法获取。而现阶段省高管局监控中心无法在上报报表日期内提供拆分数据,从而导致长益高速收费数据分析系统无法输出相关报表。经过深入了解和分析,在与业主方多次探讨后,提出以下变更说明。
二、变更内容
MTC实收和流量
原始情况:
人工收费系统出口站收费数据和出口流量的导入,是由收费站工作
人员从站级拆帐网下载的“收费数据统计报表”并再录入部分细分数据,导入长益收费数据分析系统。
变更后:
收费站工作人员在分析系统中MTC实收功能模块中只录入出口各车
型实收收入、各车型流量、免费车流量、绿通车流量、系统外收入、绿通车减免金额、免费车减免金额、手工票金额。
运营部工作人员在分析系统中MTC实收功能模块中导入本路段各站
进,其他路段出的代收流量的各车型估算流量。其中包括各车型流量、绿通车流量、免费车流量。
MTC实得
原始情况:
人工收费系统实得数据的导入,是由收费站工作人员从站级拆帐网
下载的“拆帐统计报表”,导入长益收费数据分析系统。
代收实得的导入,是由运营部工作人员从拆帐网下载的“长张高速
公司名称,版本号
2公路联网收费实际分配收入统计表”,导入长益数据分析系统。
变更后:
运营部工作人员在分析系统中MTC实得功能模块中导入估算MTC各
车型拆分收入。其中包括本路段各车型收入、系统外收入及代收业主各车型收入、系统外收入。
报表输出
由于原始基础数据的变更,所导致从数据模型上的建立发生了变化,从而将导致原长益数据分析系统输出报表无法根据原来基础数据的数据输出,需要转换为估算的数据输出,需要对所有的报表进行修改。
需要修改的报表有以下:
公司-绿色通道车辆 公司-收费站拆帐情况表 公司-单车收费标准计算表 公司-流量对比表 公司-各类车流量收入比重对比图 公司-各类车流量收入比重表 公司-实征率 公司-高速免费车 公司-收费车流量统计 公司-ETC收费车与免费车 公司-月流量分析 公司-ETC征费情况 公司-月收入图 公司-月收费情况总表 公司-收费车流量与收入统计 路劲-收入影响因素对比表 路劲-项目每月输入及车流汇总表 路劲-各站每月收入及车流汇总表 路劲-历年路费收入图 路劲-历年次票车流量图 路劲-日报 省局-交通流量统计月报表 省局-绿色通道和免费车公司名称,版本号
省局-其他收入分项统计
三年同天对比-1月
三年同期对比-2月
三年同天对比-3月
三年同期对比-4月
三年同期对比-5月
三年同期对比-6月
三年同期对比-7月
三年同期对比-8月
三年同期对比-9月
三年同期对比-10月
三年同期对比-11月
三年同期对比-12月
周报-高速公路
周报-总表
周报-流量图
周报-收入图
周报-老路
月报-月收费
月报-财务系统内金额拆帐
月报-月度收费情况
公司名称,版本号 4
第二篇:如何写软件项目需求说明书
如何写软件项目需求说明书
进入软件开发行业也有一段时间了,大大小小项目也接触了一些,对于怎么写好项目需求文档做一下总结,发表一下自己的看法。1 获取需求:
作为需求方也就是甲方,通过语言描述或文档的方式将需求(系统需要提供的功能)提交给开发人员(需求分析人员)。
获得需求的方式可以有多种多样:电话询问、现场考察、聆听用户讲解、阅读用户编制的相关文件(如招标书),其实这些方法都是GET方式,我们可以通过以下两类技术手段来达到:GET(获取)和PUSH(引导、反馈、激发)相互结合的方式来得到我们真正的需求,而这两个过程都是必须交互进行的,一般我们可以筛选一名非常有经验(包括谈判技巧、深厚的业务和技术背景、人缘很好、勤奋努力)的人士担任需求工程师,长期在客户那里工作。2 需求分析人员
(1)根据客户提供的文档或语言描述,将需求按功能划分,以用例图的方式表达系统提供的功能模块及功能模块之间的关系,完成用例图后与客户确认大的功能模块,并对每个功能模块做进一步的沟通详细记录用户所提供的关键性的描述,此过程需要系统分析人员对客户进行引导。
(2)对每个功能模块进行详细分析与描述,具体信息包括:用户角色、功能说描述、IPO的方式进行描述(即输入项、输出项、处理)、要提供必要的功能说明,如果使文档更加直观,更容易让客户理解,可以用UI的方式表达输入输出,配合必要的描述,这样对于客户更加容易理解,需要与客户进行大量的沟通确认。
(3)编写数据字典:在需求阶段,很难使团队的思路一致,建立一个合适的机制是完全必要的,这就是数据字典,数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。
(4)关于文档具体表述的格式与形式,要根据所要表达的功能来确定,最重要的是把事情描述清楚,这事最终的目的;
(5)需求文档确定后,设计人员根据这份需求文档进行系统的设计工作了。
第三篇:怎么写软件需求说明书范文
怎么写软件需求说明书
关键字:软件需求 说明书
软件需求说明书
1.引言
1.1 项目名称
1.2 项目背景和内容概要
(项目的委托单位、开发单位、主管部门、与其它项目的关系,与其他机构的关系等)
1.3 相关资料、缩略语、定义
(相关项目计划、合同及上级机关批文,引用的文件、采用的标准等)
(缩写词和名词定义)
2.任务概述
2.1 目标
(项目的开发目标和应用目标。如果是其他系统的一部分,则说明其关系)
2.2 范围
(包含的业务,不包含的业务)
2.3 假定条件与约束限制
(尽量列出开展本项目的假定和约束,例如:经费限制,开发期限,设备条件,用户现场环境准备等)
3.业务流程
4.数据描述
4.1 原始数据描述
a.静态数据
b.动态数据
4.2 数据流向图
4.3 数据概念模型和描述
5.功能需求
5.1 功能描述
6.界面要求
6.1报表格式
6.2图形要求
6.3输入输出要求
7.接口要求
(描述与本系统相连的系统的接口的数据格式,数据交换协议,接口功能等)
8.性能需求
8.1数据精确度
(例如,数据内部精度,外部显示精度)
8.2数据量
8.3时间特性要求
(根据所开发系统的特点,规定系统对时间的特性的要求。例如: 系统响应时间、界面更新处理时间、数据转换与传输时间)
9.运行环境需求
9.1网络和硬件设备平台
(网络拓扑图及设备类型描述)
10.操作系统平台
数据库系统平台
10.1编程工具
10.2其它支撑软件
11.其它专门需求
11.1安装和操作
11.2安全保密
11.3维护服务
第四篇:如何编写高质量“软件需求说明书”.doc
如何编写高质量“软件需求说明书”2003-01-27· · ··天极论坛 2 下一页
你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大,但客户会很重视,所以说明必须得到赞同。
现在你正在设计其中的一个特性,已经发现了需求的一些问题。你可以用多种不同的方式解释需求15;需求9 的说明正好与需求21相反,你因该相信哪一个?需求24非常含糊,你根本不明白它的意思;你不得不花上一个小时与2位开发人员讨论需求30,只因为你们对 其各有各的理解;并且,唯一能够澄清这些问题的客户没有给你们答复。你被迫破解众多需求的含义,并且你能预料到,如果你错了,你要做大量的重复工作。
许多软件需求说明书(SRS)写得非常糟糕。任何产品的质量需要其原始材料的质量保证,糟糕的软件需求说明书不可能产出优秀的软件。不幸的是,几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。而且,没有非常多的好需求可以借鉴学习,部分原因是很少有工程可以找到一个好的借鉴,其 他原因是公司不愿意将其产品说明书放在公共区域。
这篇文章描述了高质量需求叙述和说明的几个特性(特点)。我们将用这些观点检查一些有缺陷的需求,带着痛楚重新编写。而且我会谈一些如何编写好 的需求的提示。你也许想通过这些质量标准评估你的工程需求。对于修订,也许迟了,但你会学到一些有用的东西,并帮助你的小组在下次编写出更好的需求。
不要期望能够编写出一份能体现需求应具备的所有特性的SRS。无论你怎么细化、分析、评论和优化需求,都不可能达到完美。但是,如果你牢记这些特性,你就会编写出更好的需求,生产出更好的产品。
高质量需求叙述的特性
我们如何从一些有问题的需求中分辨出好的软件需求?这一节将分别介绍需求叙述应体现的6个特性,下一节将从整体上介绍SRS文档应具备的特性。判断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试 例子能够明确显现在需求中描述的产品行为(特性),能够显现缺陷、冗余和含糊之处。
正确:每个需求必须精确描述要交付的功能。正确性依据于需求的来源,如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的(当然,系统需求说明书本身可能不正确)。
只有用户的代表能够决定用户需求的正确性,这就是为什么在检查需求时,要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的:“这是没意义的”,“这可能是他们的意思”等众所周知的猜测。
可行性:在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性,在需求分析阶段应该有一个开发人员参与,在抽象阶段应该有市场人员参与。这个开发人员应能检查在技术上什么能做什么不能做,哪些需要需要额外的付出或者和其他的权衡。
必要性:每个需求应载明什么是客户确实需要的,什么要顺应于外部的需求,接口或标准。每个需求源于你认可、具有权说明需求的原始资料,这是考虑 必需的另外情形(译注,此句翻译不顺,请参照原文:Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements)。跟踪每个需求回溯到出处,如用例,系统需求,规章,或来自其他用户的意见。如果你不能标识出处,可能需求只是个镀金的例子,没有真正的必须。
优先权:为了表明在一个详细的产品版本中应包含哪些要点,需要为每个需求,特征,或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优 先权。如果所有的需求都被视为同等重要,那么由于在开发中,预算削减,计划超时或组员的离开导致新的需求时,项目经理将不能起到作用。优先权的作用是提供给客户的价值,实现的相关费用,实现相关联的有关技术风险。
我是用3种级别的优先权:高优先权表明需求必须体现在下一个产品版本中,中优先权表明需求是必须的,但是如果需要可以推迟到晚一些的产品版本中,低优先权表明有它很好,但我们必须认识到如果没有充足的时间或资源,它可以被放弃掉。
明确:需求叙述的读者应只能从其得到唯一的解释说明,同样,一个需求的多个读者也应达成共识。自然语言极易导致含糊。要避免使用一些对于SRS 作者很清楚但对于读者不清楚的主观词汇,如:用户友好性,容易,简单,快速,有效,几个,艺术级,改善的,最大,最小等等。每写一个需要都应简洁,简单,直观的采用用户熟知的语言,不要采用计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查,根据需求写测试,建立用户的假想来说明产品某个特定部 分预期的特性。
可证实:看你是否能够做出测试计划或其他验证方式,如检查和实证,来决定在产品中每个需求是否正确的实现。如果需求是不可验证的,决定需求是不 是正确的实现就成了判断的事。需求之间不一致,不可行,不明确也能导致不可证实。任何需求如果说产品将要支持什么也是不可证实的。
高质量需求说明的特征
一个完整的SRS不仅是包括长长的功能性需求列表,还包括外部接口描述和一些诸如质量属性,期望性能的非功能性需求。下面描述了高质量的SRS的一些特性。
完整:不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发现缺少的信息很难,因为根本不存在。在SRS中将需求以分层目录方式组织,将帮助评审人员理解功能性描述的结构,使他们很容易指出遗失的东西。
在需求抽象时,相对于系统功能,你过多的注意用户的业务,将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上,应用用例方法会发挥很好的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。
如果你知道已缺少一些信息,使用TBD(to be determined)标准标志可以突出这些缺陷,当你在构建产品的相关部分时,就可以从一个给定的需求集中解决所有的缺陷。
一致性:一致性需求就是不要于其他的软件需求或高级别的系统(商业)需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎,如果只审定修改的部分,没有审定于修改相关的部分,就可能导致不一致性。
可修改性:当每个需求的要求修改了或维护其历史更改时,你必须能够审定SRS。也就是说每个需求必须相对于其他需求有其单独的标示和分开的说明,便于清晰的查阅。通过良好的组织可以使需求易于修改,如:将相关的需求分组,建立目录表,索引,以及前后参考(照)。
可追踪:你应能将一个软件与其原始材料相对应,如高级系统需求,用例,用户的提议等。也能够将软件需求与设计元素,源代码,用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示,细密和结构化的编写,不应过大,不应是叙述性的文字和公告式的列表。
需求质量的评审
这些有关需求质量的特性的描述在理论上都是非常好的,但一个好的需求到底是个什么样子的呢?为了体现得更切合实际,我们做个小练习。下面有几个 从实际的工程选出的需求,依据上面的质量标准,评估每个需求,看看有什么问题,然后用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢 迎你提出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客户,我们只能猜测每个需求的意图。
例1.“产品应在不少于每60秒的正常周期内提供状态信息”
这个需求是不完整的:状态信息是什么,如何显示给用户。这个需 求有几处含糊。我们在谈论产品的哪部分?状态信息间隔真的假定为不少于60秒?,甚者每10年显示一条新的状态信息也可以?也许它的意图是消息间隔不应超 过60秒,那么1毫秒是不是太短?“每”这个词导致了不确定性。问题的后果,就是需求的不可证实。
弥补缺陷,重写需求的一种方法:
1、状态信息
1.1后台任务管理器因该以误差上下不超过10秒的60秒间隔,在用户界面的指定位置显示状态信息
1.2如果后台进程处理正常,那么应该显示任务已完成的百分数/比
1.3任务完成时,应显示相关的信息
1.4后台任务出错应该显示错误信息
为了分别测试和追踪,我将其分成了多个需求。如果将几个需求串接在一节中,在构造和测试时就很容易漏掉一个。
例2.“产品应瞬间在显示和隐藏不可打印字符间切换”
计算机在瞬间不能做任何事,所以这个需求不切实可行。它的不完整性 表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己?或者用户为了模仿更改要做一些动作?而且,在文档中改变显示的范围是多大:选中的文本,整个的文档,或其他的?这也是个模糊的问题。不可打印字符合隐藏字符一样吗?或者是一些属性标志或一些控制字符?问题的后果,就是需求的不可证实。
象这样编写需求也许更好一些:“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚,不可 打印字符是HTML标记。由于没有定义触发条件,需求对设计没有约束力。只有设计人员选定了触发条件后,你才能编写测试验证触发的正确操作。
例3.“HTML分析器可以产生HTML标记错误报告,帮助HTML入门者快速解决错误”。单词“快速”使其模糊,没
有加进错误报告的定义也是其部完整。我不知道,你怎么验证这个需求。找一个自称为HTML的入门者,看看能不能根据错误报告快速解决错误?
试试这个:“HTML分析器可以产生一个错误报告,错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误,就不 会产生错误报告”。现在我们知道了,什么会被加到出错报告中,但是出错报告是个什么样子,则留由设计人员决定。我们还指定了一个例外:如果没有发现错误,不产生错误报告。
例4.“如果可能,主管号码应通过联机校验,而不是通过主全体主管号码列表校验”。真感到绝望,什么是“如果可能”:如果技术上可行?如果主全 体主管号码列表可以联机获得?要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书,采用诸如:应,将,应该/
将 要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图,指明优先级。这是修改后的:系统应校验输入的主管号码而不通过联机的主全体主 官号码列表。如果在列表中没有发现主管号码,将会显示一条错误信息,也不接受指令。
在理解各个已完成的糟糕需求上,开发人员将会遇到的难题是:开发人员与客户将会在审核需求,未达成共识前发生激烈的争论。详细检查大的需求文档 不是一件轻松的事情。我清楚有人做过,而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话,在这个阶段修补缺陷是便宜的,编写质量需求的方针
编写优秀的需求是没有公式化的方法的。这需要大量的经验,要从你在过去的文档中发现的问题学习。请在组织软件需求文档时,严格遵从这些方针。
句子和段落要短。采用主动语气。使用正确的语法,拼写,标点。使用术语,要保持一致性,并在术语表或数据字典中定义它们
要看需求是否被有效的定义,可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部,看看能不能是你紧张起来。换句话说,你 是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求,以便于设计和实现?如果是的话,在继续工作前,需求还需要细化。
需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确,那么它已经正确的细化了。如果你预想到多种不同类的测试,几个需求可能已挤到了一起,需要拆分开。
密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。
通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如:“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开,而“产品应能对来自语音编辑指示做出反应”应作为一个子系统,不应作为单个的功能性需求。
避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读,但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新,避免不一致性。
如果你遵从了这些方针,你能够尽早地经常正式或非正式的审查需求,这些需求对于产品的构造,系统测试以及最后的客户满意,都会成为好的奠基石。并且要记住,没有高质量的需求,软件就象一盒巧克力,你永远不知道你会得到什么。
第五篇:软件项目需求建议书
篇一:软件需求建议书
医院门诊管理系统需求建议书
2012年3月26日
有关公司:
现需一个医院门诊管理系统,要求具有相关项目经验的软件公司参与竞标,要求能对该系统进行合理的编写,保证系统能够稳定运行,并且在预定时间内交付我院使用。
项目目标:
系统分为5个子系统,即(a)挂号管理系统(b)病历管理系统(c)药品库存管理系统(d)内部资料管理系统(f)财务管理系统。并且需要保证系统运行稳定准确。
1.工作表述
承包商应执行以下工作任务,及工作要求:
(1)系统应使用本院的局域网,win98、win2000、winxp、win7等环境
下,可进行稳定准确的查询,修改、处理功能。
(2)数据录入功能:其中包括在挂号时的患者信息录入,病历管理的录
入处方和内部资料管理中的医师信息的添加。
(3)数据的修改和删除功能:其中包括改号、退号和内部资料管理中的
患者、医师信息的修改和删除功能。
(4)数据查询功能:包括在诊室管理中的药品的模糊查询,对库存不足
的药品报警,内部资料管理中的医师、患者信息的查询中包括单项查询和组合查询。
(5)统计报表功能,财务报表:统计每天患者交款报表和挂号员每天的
交款单。统计患者总人数和总费用。
(6)按处方类别和拼音码分别统计药品的总数和库存剩容量。
(7)按科室名称和是否专家级别分别统计医师总人数信息。日报表:打
印每天的患者人数、就诊科室等,以及医师每天的出诊数,检验、检查、手术每天的执行次数,以及这些项目的总金额。
(8)合计费用功能:患者凭挂号单到交款处交款,系统根据门诊号码自 动调用患者信息,显示患者的单项费用和总费用,自动找零。
(9)系统管理功能:其中包括用户和内部人员的修改密码功能,根据权
限添加用户和管理员。数据备份功能。
(10)帮助功能:包含医院简介和系统主要实现功能简介。
2交付实物
(1)必须准备一份详细的系统设计报告,以及所用到的技术,用以监测产品
质量。
(2)有关项目进程的书面报告必须在每15天交给本院。报告应简明,并且
重点放在与承约商的原计划和时间表相对应的进程上。报告应涉及到各项活动、取得的进展、接下来15天的计划、花费的时间与金钱。对于落后进度计划进程的工作项目,应当提供一份计划,使项目能在原进度计划和预算内完成。
(3)在合同预期内,交付我院一个能够运行正常稳定的完整的系统。并且在
后期一定时间内提供免费维护。
3其他要求
(4)本院会向承包商提供本院的一些业务流程。
(5)承约商必须在执行工作前,获得本院对最终计划的认同。
(6)合同必须以一个商定的价格,给提供满足需求建议书要求工作的承约商
付款。
(7)承约商必须最迟在2012年5月1日以前提供给本院两份建议书备份。
(8)本院希望在2012年6月1日前选中一家承约商。这个工程需要完成的
期限是十二个月,从2012年7月1日至2013年7月1日,所有交付物必须不迟于2013年10月1日提供给本院。
(9)本院将按照下面的时间表付款给承约商:当项目完成了1/3时付总额的
1/3;当项目完成了2/3时付总额的2/3;当本人已经满意于项目的100%,并且承约商已履行了全部契约义务时再付出总额的最后1/3。
申请内容
(1)承约商能清晰理解需求建议书,理解什么是被期望达到的要求。承约商应有对每个任务和任务如何完成的详细描述。
(2)承约商将要提供的每一份交付物的描述。
(3)列出条形图或网络图表,列明每周要执行的详细任务的时间表,以便在要求的项目完成日期内能够完成项目。
(4)叙述一下承约商最近已经执行过的相似项目,包括已完成的子系统,以及其他子系统的完成进度。
(5)列出工程具体人员的姓名和详细简历,以及他在类似工程的精彩的经历。
(6)必须说明项目所需要的人月,并通过一份详细的工作时间分解和每个被指派于工程的员工的小时成本费用来验证。此外,所有直接费用逐条列表也必须包括进来。
(7)承包商需列出贵公司的软件能力成熟度(cmmi)等级。
(8)本院将按照以下的标准评价所有承约商的申请书:
a.设计方案(30%)。设计的实用及涉及技术。
b.经验(30%)。被指定工程的承约商和工作人员执行类似工程的经验。
c.成本(30%)。承约商申请中的所列的固定成本。
d.进度计划(10%)。为了在要求的项目完成日期内或在此日期之前完成项目,承约商应提出进度计划的详细而全面的连续说明。
篇二:软件系统项目建议书完全版
****系统项目建议书
2014年5月
目录
概述....................................................................1 1.1 文档编写目的...........................................................................................................1 1.2 系统建设目标与内容...............................................................................................1 1.2.1 系统建设目标...................................................................................................1 1.2.2 系统建设的主要内容.......................................................................................1 2 系统设计方案.............................................................1 2.1 总体架构设计...........................................................................................................1 2.1.1 系统总体业务架构...........................................................................................1 2.1.2 系统总体软件架构...........................................................................................1 2.1.3 系统总体技术架构...........................................................................................1 2.2 系统组成...................................................................................................................1 2.3 系统数据流...............................................................................................................1 2.4 系统功能...................................................................................................................3 3 系统部署方案.............................................................3 3.1 系统部署架构...........................................................................................................3 3.2 系统环境...................................................................................................................3 3.2.1 软件环境...........................................................................................................4 3.2.2 硬件环境...........................................................................................................4 4 系统界面设计.............................................................4 5 主要技术指标.............................................................4 6 交付成果................................................................6 7 验收策略................................................................6 7.1 系统验收测试的原则...............................................................................................6 7.2 验收测试的具体内容...............................................................................................7 7.3 验收测试的步骤.......................................................................................................7 8 质量保证................................................................8 8.1 软件研制一般要求...................................................................................................8 8.2 软件评审要求...........................................................................................................9 8.3 软件配置管理要求.................................................................................................10 9 售后服务...............................................................10 9.1 培训.........................................................................................................................10 9.2 维护与升级.............................................................................................................10 9.3 质量保证期内的服务.............................................................................................10 9.4 寿命期内维修服务.................................................................................................11 10 开发进度计划............................................................11 11 项目报价...............................................................12 1 概述
1.1 文档编写目的 1.2 系统建设目标与内容
1.2.1 系统建设目标 1.2.2 系统建设的主要内容
系统设计方案 2.1 总体架构设计
2.1.1 系统总体业务架构 2.1.2 系统总体软件架构 2.1.3 系统总体技术架构
2.2 系统组成
2.3 系统数据流
系统详细数据流如下图所示。
2.4 系统功能
系统部署方案 3.1 系统部署架构
表1各子系统部署架构
3.2 系统环境 篇三:需求建议书
题目:
假设你在嘉州新城购买了一套二室二厅一厨一卫,面积大约90平方的新房,先装修入住,请你根据自己的需求对这个房屋装修项目编写项目需求建议书。
项目:房屋装修
需求建议书:
(1)承约商要执行的任务:装修材料的购买、家用设备的安装、装修工程。
① 代购装修材料,如:地砖、涂料等等
② 厨房器具、淋浴设备等的代购
(2)承约商根据国家标准装修,提供装修计划、施工方案,最后装修符合标准的房
子。
(3)本人向承约商提供装修方案。
要求:
①、卧室的颜色以暖色调为主
②、装修后简单、宽敞、采光效果良好
③、卫生间隔成两部分,分为盥洗间和浴室
(4)和承约商签订一个商定的价格,以及满足需求建议书的工作承约商付款合同。
(5)当装修工程完成1/2时付总额的1/2;当装修工程100%完成时,获得本人的
满意后,并且承约商已经全部履行契约义务时再付总额的最后1/2。
(6)希望这个项目在两个月内完成,从5月15日到7月15日,所有的可交付成果 必须不迟于7月15日提供给本人。
(7)承约商必须最迟于4月30日以前向本人提交两份申请书备份。承约商的申请书
至少包括以下内容: 1)承约商能清晰的理解需求建议书,要详细描述承约商的实施装修项目的方法,以及使用的装修材料的具体规格。
2)承约商要提供可交付成果的详细描述。
3)在6月15日向本人反映项目进行的进度。
4)叙述承约商最近实施的项目,包括客户的姓名、地址和电话号码,以备核实。
5)列出将被指定为项目主要负责人的姓名和联系方式,以及工作经验。
(8)申请书的评价标准
1)承约商提出的建设方案(30%)
2)被指定为执行此项目主要负责人的姓名和联系方式,以及类似的工作经验(30%)
3)承约商申请书所列的固定成本(30%)
4)承约商提供的施工计划(10%)
组员:岳红 117 王华 213 周燕飞 126 赵涵玉 223 曾志锦 203 篇四:需求建议书
需求建议书(request for proposal,rfp)
什么是需求建议书[1] 需求建议书是指从客户角度出发,全面、详细地向服务商陈述、表达为了满足其已识别需求所应做的准备工作。也就是说,需求建议书是客户向服务商发出的用来说明如何满足其已识别需求的建议书,是客户与服务商建立正式联系的第一份书面文件,又称招标书。需求建议书一般由客户起草,主要描述客户的需求、条件及对项目任务的具体要求。一份完整的需求建议书主要包括满足其需求的项目的工作自述、对项目的要求、期望的项目目标、客户供应条款、付款方式、契约形式、项目时间、项目申请书的要求等。好的需求建议书能让服务商准确把握客户所期待的产品或服务。当然,并非在所有情况下都需要准备一份正式的需求建议书,当某一企业的需求由内部开发项目予以满足时,这一过程似乎变得简单多了,此时更多需要的是口头上的交流和信息传递,而不是把宝贵的时间耽搁在仅仅起到信息传递作用的需求建议书上。例如,某一软件开发公司感到公司原来的财务分析系统已经远远不能适应日益增加的业务需要时,便可直接要求软件开发小组进行开发,这时只需口头把相关的要求传达给软件开发小组即可。
[编辑] 需求建议书的主要内容[2] 需求建议书一般包含以下主要内容:
客户必须搜集大量相关资料准备需求建议书,因为it项目实施者需要按照rfp来准备他们的项目技术方案,并以此参与竞标。rfp中包括项目的目标,也就是用户的期望,也包括客户要求项目的进度计划;对实施商申请书的表格和内容的规定;客户希望潜在的实施商提交投标申请书的最后期限;评价申请书的标准等。一份好的rfp应该包括以下一些内容。
1.工作表述
工作表述就是说明项目的工作范围,概括客户要求开发商或项目团队执行的任务或工作单元,说明项目所涉及的各种事情,哪些必须由开发商或项目团队去完成,哪些由客户自己去做。例如,一个办公自动化软件系统的具体目标。又如建设一个网站,所需设备的采购任务,是由客户自己完成,还是由开发商去完成;企业网站上的页面文字,是客户自己撰写,还是由开发商撰写等。2.任务要求
需求建议书必须要具体规定开发商需要完成任务的规格和特征,如要求涉及大小、数量、颜色、重量、速度和其他开发商提出的解决方案中,所必须满足的物理参数和操作参数。例如,建立一个企业网站,可能要求在1 000人同时访问的情况下不会产生堵塞的感觉,网
站的浏览页面不低于多少;建立一个自动结账和收款系统,可能要求每天能办理12 000次交易的功能和其他特定的功能,如在开出了发票的30天内没有收到账款,就会自动产生催款通知。具体的任务要求,可能会成为将来的验收标准。
3.交付物
交付物就是开发商所提供的实体内容,这在需求建议书中应该说明。例如,对于自动结账和收款系统来说,客户可能要求开发商提供硬件(计算机)、软件(磁盘和一些印刷品)、操作手册和培训课程。交付物也可能包括客户要求开发商提供定期进度报告或终期报告。
4.客户供应条款
需求建议书还应该列出客户的供应条款。例如,客户需要建立一个网j站,可能需要向开发商提供企业内部的组织结构及各部门之间业务关系的详]细说明,包括信息流程的类型、信息流量和发生频率等。5.表述客户对需求的确认
需求建议书不是对客户需求的最后确认。最后的确认应该在对开发商提出的方案进行评估之后。例如印刷宣传手册,可能在开印之前要经过客户审定;局域网的建设,在购买材料和设备之前,客户必须审定开发商的技术方案。这一点在需求建议书中必须向开发商说明。
6.期望的合同类型(1)合同可以按固定价格订立。这样,开发商实际上就是费用包干。客户只给固定的价钱,不管开发商实际工作花费多少。开发商必须保证功能的实现和质量要求,超支的风险由开发商负担。
(2)合同也可以规定开发商不承担风险,即在时间、原材料限制的条件下,不论实际成本多少,都会给开发商特定的报酬,也就是所谓包工不包料。在我国现阶段的条件下,由于质量检验和资信度水平不高,这种合同比]较普遍。在需求建议书中,最好说明客户是希望采用那种类型的合同。7.期望的付款方式
付款方式可以分为一次性付款和分阶段付款;在开始前付款和结束后付款。一般依项目的性质来定付款方式。如网页制作,往往在项目末期付款;而架设局域网,一般在方案确认后,付款30%以便开发商采购,工程结束验收后付满90%,留10%等到使用一段时间以后确认无问题时付清。具体付款方式需要合同双方协商,但在需求建议书中,客户应该先提出自己的期望付款方式。8.要求的进度计划
进度计划的要求可能很粗,如要求在6个月内完成;也可以详细一些,如多长时间内完成方案设计和审定,多长时间内完成硬件选购与安装,多长时间内完成软件研制、测试与安装,最后开发商在系统安装调试后,在多长时间内提交所有的系统文件和操作培训。9.申请书的格式和内容提示
为了便于在几个开发商之间进行比较和评价,申请书应该在形式上采取同一个格式,内容的结构也应该一致。这样对不同的申请者来说比较公平,也能减轻客户在评审时的工作量。客户在需求建议书中可以限定申请书的每一部分采用的文字数量或页数。
10.提交申请书的最后期限
申请书受理的截止日期是必须要交代清楚的。例如,要求开发商在接到需求建议书后多少个工作口之内(如l周之内、1个月之内等)提交申请书,或大家一律在某月某日之前提交申请书。这样做的目的是便于同时对众多的申请者进行比较、评估,也是为了保持公正,不给某些开发商以额外的时间和机会。
11.对申请书的评价标准
要告诉开发商客户将根据哪些准则来评价他提交的申请书。这样做的目的,是指导开发商写好申请书。一般评价标准包括4个方面的内容:
(1)开发商在类似项目中的经验。如他们近期是否在预算内按期完成了类似的项目,客户对他们是否满意?(2)开发商提出的技术方案是否合适。如采用哪种类型的计算机软件?数据库的设计、方法是什么?用来建立管理信息系统的是哪种语言?采用哪些供应商的设备?等等。
(3)进度计划。开发商是否能按照所要求的进度完成项目计划?(4)成本。如开发商的报价是否合理?成本预算中有无漏算的条款?将来在执行时有没有可能出现超支,或有无可能因过于节约而导致质量不能保证?有的申请人为了争取合同,在报价上压低成本,到了执行阶段,或偷工减料,或增加成本,结果导致所建系统的缺陷很多,或使最终成本大大超出原始的估算。对此需要引起注意。
12.资金总量
开发商总是希望了解客户有多少资金可以用于发展拟议中的真t项目,但客户在需求建议书中,往往不愿意透露这个信息。其实,客户暗示大约的数字,告诉开发商他打算花多少钱来办这件事是有好处的,这样可以使开发商能够提交与资金水平相适应的申请书,提高在项目准备阶段的工作效率。
[编辑] 需求建议书的必要性[2] 需求建议书(rfp)是项目客户与开发商建立正式联系的第一份书面文件,也叫招标书。一般由项目的客户自己起草,主要描述客户的需求、条件以及对项目任务的具体要求,向可能的开发商发送。
需求建议书是客户为确保供应商理解项目的需求,并在此基础上提供项目建议书而编制的需求规范。虽然它不能确保客户据此就能获得理想的解决方案,但却可以帮助客户发现那些尽可能接近自身需求的系统准备。其
目的是从客户自身的角度出发,通过全面、详细地陈述,使开发商或项目团队理解客户所希望的是什么,以可行的价格满足客户的已识别的需求。
对于一些预算较少的客户,开发商往往不愿意花精力准备正式的方案建议书,这种情况下,客户的需求建议书就变得很重要。事实上,项目无论大小,都需要编写需求建议书。第一,需求建议书需要描述用户的目标与需求。编制需求建议书的过程也是客户进一步明确自己的目标与需求的过程,并以此建立起客户与供应商进行深人沟通的桥梁。即使因为各种原因使得供应商看不到或不愿响应需求建议书,这种努力也是值得付出的。
第二,需求建议书可节省选型的时间,并使得对各供应商之间的比较变得更容易。客户提供给所有竞标供应商的信息都是一样的,避免了跟各开发商的重复沟通,同时,有需求建议书作为基准,客户可以约束各开发商以一致的格式提交方案建议书,以提高各供应商之间的可比性。
第三,需求建议书可以避免一些潜在的疏漏。在准备需求建议书时,客户往往会因为太过关注具体细节而忽略了一些重要的因素。收到需求建议书后,有的供应商可能会主动对这样的疏漏提出质疑以提醒客户。还有些开发商为了使自己的方案建议书更具有吸引力,甚至会提出一些需求建议书没有涉及的好想法来拓展客户的思路。
[编辑] 编写需求建议书的一般原则[2] 需求建议书应该由用户编写,但各种客观因素的限制,实际上很难做[到。所以,很多时候都是由用户与项目小组共同编写。编写项目需求说明的j过程也是项目小组带领客户进入项目需求启发的过程。编写优秀的项目需求[建议书没有公式化的方法,需要大量的实践经验。以下是编写需求建议书需要把握的几个原则:
(1)需求应该是正确的。每个需求必须精确描述要交付的功能。确定需求内容是否正确,需要用户的代表来参与确认,由他们检查、决定用户需[求的正确性。没有用户的需求检查就会导致很多项目实施中的问题出现。例如用户会说:“这不是我们要的东西”;“你没明白我们的意思”,等等。
(2)需求应该是可行的。项目的需求应该在有限的资源(已知的能力、有限的系统及其环境)下是可实现的。为了避免需求的不可行性,在需求分析阶段应该有核心技术人员参与,检查在技术上什么能做、什么不能做,哪些需要额外的付出等。
(3)需求内容应该是必要的。需求建议书中的每个需求都应该有相应[的出处,即说明什么是客户确实需要的,什么要顺应于外部的需求、接口或标准。如果不能标识出处,则可能这个需求不是真正需要的。
(4)需求内容应该有优先权。优先权是由客户或其代理及项目小组共同商讨后建立的。如果所有的需求都被视为同等重要,那么在开发中遇到预t算削减、计划超时或组员的离开而导致新的需求时,项目经理将无所适从。一般优先权有以下三个级别。
1)高优先权,表明需求必须体现在本阶段项目的成果中或这个产品的版本中。
2)中优先权,表明需求是必须的,但是如果需要可以推迟到晚一些的产品版本中。
3)低优先权,表明有它很好,但我们必须认识到如果没有充足的时间或资源,它可以被放弃掉。
(5)需求内容应该是明确的。需求不该有歧义,要避免使用一些对于拟订项目需求建议书的人很清楚,但对于其他人模糊不清的词汇。如:用户友好性,容易,简单,快速,有效,几个,艺术级,改善的,最大,最小等等。每写一个需要都应简洁、直观地采用用户熟知的语言,而不要采用计算机术语。
[编辑] 需求建议书例子[2] 例:某企业项目管理软件开发项目需求建议书
有关单位:某企业(甲方)由于业务发展的需要,决定采用项目管理的方式进行管理,为了更有效地对项目的执行过程进行控制,该企业决定开发一套项目管理软件以满足这一需要。
1.工作表述
开发商将执行下面任务:开发项目管理软件。
开发项目管理软件的主要功能包括项目及工作信息的录入、项目网络计划图的绘制、项目时间计划的安排、甘特图计划的制定、项目执行信息的录入与分析及各种计划报表的输出等功能。2.要求
开发商应根据国家有关标准,提供开发计划和实施方案。篇五:软件项目管理项目建议书
湖南文理学院实验报告
时间: 2013 年 11 月 18 日
课程名称: 软件项目管理
实验名称:撰写毕业生就业信息管理系统项目建议书
班级: 姓名: 同组人: 无
指导教师评定: 签名:
一、实验目的掌握项目建议书的格式和写作要求,会结合具体项目写作项目建议书。
二、实验要求
1、结合模拟项目—毕业生就业信息管理系统项目写出项目建议书。
2、提交毕业生就业信息管理系统项目建议书(报告)一份。
三、实验环境 1.硬件:计算机 2.操作系统:windows平台。
3.相关软件:microsoft office软件。
四、实验步骤
1、背景介绍
随着internet的迅猛发展和普及,我国高等院校纷纷建立自己的校园网,使高校的办公,教学和管理工作发生了巨大的变化,并具有了新的特点,对教学管理工作提出了新的要求,也使得基于网络的高校毕业生就业招聘成为可能。通过internet,用人单位和就业者利用网络的便利,不直接见面,采用网络交互地就业联系、就业面试,以及就业意向和合同的签订等工作。我国部分高校目前正在尝试通过网络进行毕业生的就业分配工作,但目前使用的就业网站的开发应用,大多功能相对单一,多局限于就业信息的发布,就业信息的静态统计结果的公布及简单的就业信息查询,其实用性和互动性已经不能满足高校就业形势的需要。随着高校毕业生就业体制改革进程的不断深化和毕业生就业市场的逐步建立,高校毕业生在各种就业活动中求职面窄、择业率低、特别是信息量小的问题越来越突出。如何解决这一问题是摆在各级就业主管部门面前的严峻任务。正是在这种情形下,国务院对做好高校毕业生就业工作做出重要指示,即“要充分利用毕业生就业信息网络,沟通行业间、地区间、学校与用人单位间的信息,在毕业生和用人单位之间牵线搭桥。同时,通过信息反馈,优化高等教育结构,合理
利用有效资源,促进高等教育的健康发展”高校就业系统以招聘和求职系统为核心,以用人单位需求和服务为目标。明确了系统的定位,有利于构建优化网上就业服务体系,有利于不断激活毕业生就业市场,有利于网络资源的充分利用,有利于网上动态管理、杜绝虚假信息、拓宽网上就业服务功能。
2、项目的意义和必要性
毕业生就业信息系统和就业服务体系不完善,毕业生就业主要由学校、人才市场举办招聘会等方式获得信息,与需求方见面,信息渠道比较窄。毕业生的就业指导工作极为薄弱,就业指导教师水平参差不齐,专业的、高素质的就业指导教师太少;缺少优质的就业指导教材。所以,必须加强学生择业的政策咨询和信息服务,逐步建立起信息服务网络,建立毕业生就业网络系统,为实行网上求职择业创造条件和提供服务。目前,建设好大学生的就业网站,不仅仅是政府部门应该关心的问题,作为培养大学生的湖南文理学院也有同样的需求。
解决目前高校就业信息管理中存在的一些问题,如信息传递不方便、不快捷,数据分析及就业指导不及时,学生签约必须到不同部门领表、上交等繁琐的操作等。通过本系统可以使湖南文理学院毕业生就业信息管理工作更加合理化、科学化,提高工作的效率,从根本上改变就业管理工作的方式,通过internet,各院系和学生利用网络的便利,可以直接查询和提交就业信息。在这种系统平台下,可以快速、有效、全面的反映最新的用人单位信息、毕业生基本信息和就业趋势,及时提供高校学生工作管理人员对历届用人单位需求信息的分析统计,及时有效地调查分析大学毕业生的择业趋势和引发的心理问题并进行及时有效的就业指导。可以做到信息的规范管理、科学统计和快速查询,从而减少管理方面的工作量。
3、项目产品或服务的市场预测
(由于这个系统不是学院的直接收益产品,这里不做分析。)
4、项目的规模和期限
基于学院的实际情况,这个毕业生就业信息可以初步分为三个阶段来完成。
第一阶段,着重处理学院现有的问题,把系统运行起来,重点放在用户管理方面,分为用户注册、用户审核和用户登录验证三部分。
第二阶段,注重完成学校的就业信息发布,用户在通过系统注册后,可以查询各种信息。
第三阶段,系统管理,管理可以对学生用户和站内信息进行管理。
5、投资估算
具体相信的投资预算,由专业人员进行。这里只能给出对比其他同类学校信息系统的估算,3个阶段全部完成,大概需要5万人民币。这个估算不包括硬件设备的预算。
6、市场前景及经济效益初步分析
这个系统虽然不是学院的直接收益产品,但其带来的间接效益是毋庸置疑。具体可以表现为:
(1)管理决策的科学化。
传统的决策指示凭经验的大致的估算,无法采集到大量的数据,也无法对采集到的数据进行精确的分析,而毕业生就业管理系统通过internet,各院系和学生利用网络的便利,可以直接查询和提交就业信息,比较全面、及时地采集信息数据、并选定合适的管理模式,做出科学的决策,减少决策失误。
(2)管理工作的高效化。
在这种系统平台下,可以快速、有效、全面的反映最新的用人单位信息、毕业生基本信息和就业趋势,及时提供高校学生工作管理人员对历届用人单位需求信息的分析统计,及时有效地调查分析大学毕业生的择业趋势和引发的心理问题并进行及时有效的就业指导。
(3)网上就业服务体系的优化。
毕业生的就业指导工作极为薄弱,就业指导教师水平参差不齐,专业的、高素质的就业指导教师太少;缺少优质的就业指导教材。而毕业生就业网络系统加强了学生择业的政策咨询和信息服务,逐步建立起信息服务网络,为实行网上求职择业创造条件和提供服务。
(4)网络资源的充分利用。
指导老师可以开辟“求职顾问”,“就业指导”的板块,告诉毕业生就业过程中应该注意的问题,帮助学生完善职业形象;了解劳动关系法规;增强自身的保护意识;提高大学生竞争就业意识和能力。
大学生可以利用就业网络内容丰富、全面的就业信息,最新的国家就业政策和规范,了解国家就业形势,更新就业观念,树立正确职业观和就业观。同时,制作个人简历,实现网上的自荐求职,查询自己感兴趣用人单位的资料,来了解用人单位的情况。
用人单位可以浏览学生所在学校的网站来了解学校的概况及专业设置情况,了解学生专业知识结构和综合素质,并且通过学校就业网站来核对电子简历的诚信度。
(5)毕业生与用人单位的良好沟通
大学生通过查询自己感兴趣用人单位的资料,来了解用人单位的情况。对中意的单位可以投递电子简历。用人单位通过浏览学生所在学校的网站,了解毕业生的信息。有意向的双方可以通过网上面试的方式来进行进一步的沟通,提高学生和用人单位接触频率,促进就业工作开展。为企业和学生提供一个交流平台及更为人性化、个性化的服务。
另外需要注意的是,毕业生就业管理系统的效益一般是无形的,只有经过长期运行后的分析统计才能计算其收益,往往越成熟、科学、优秀的毕业生就业管理系统,带给我们的效益就越大。毕业生就业水平提高了,学校知名度也会随之提高,学校的生源也会越来越好。
综上所述,校方认为建立一个毕业生就业管理系统是非常必要的,请上级领导批示。
7、其他需要说明的问题
随着计算机科学与技术学院学院人数不断增加,毕业生的人数也会逐步增长,毕业生就业管理的难度也在不断加大,所有我们认为建立一个计算机科学与技术学院毕业生就业管理系统是在将来的影响和效益是不可估量。