精华内容
参与话题
问答
  • 软件需求说明书 编写实例

    万次阅读 2006-02-17 18:51:00
    一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大,但客户会很重视,所以说明必须得到赞同。 现在你正在设计其中的一个特性,已经发现了需求的一些问题。你可以用多种不同的方式解释...
    你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大,但客户会很重视,所以说明必须得到赞同。   现在你正在设计其中的一个特性,已经发现了需求的一些问题。你可以用多种不同的方式解释需求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中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读,但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新,避免不一致性。   如果你遵从了这些方针,你能够尽早地经常正式或非正式的审查需求,这些需求对于产品的构造,系统测试以及最后的客户满意,都会成为好的奠基石。并且要记住,没有高质量的需求,软件就象一盒巧克力,你永远不知道你会
    展开全文
  • 软件需求规格说明书范例

    万次阅读 多人点赞 2019-07-24 10:11:21
    文章目录 一、 引言 1.1 定位与目标 ...1.3 软件需求分析理论 1.4 软件需求分析目标 二、 需求概述 2.1 项目背景 2.2 需求概述 2.3 系统结构 三、 系统功能需求 3.1 功能总览 3.2 业务流程图 3.3 数据流...

    完整版(包括图片表格,请访问 http://www.omegaxyz.com/2019/07/23/software-specification/

    本软件需求规格说明书范例对应的软件测试计划请参照:
    http://www.omegaxyz.com/2019/08/02/software-testing/

    PDF文档及更多软件测试内容请参考:https://github.com/xyjigsaw/software-testing

    文章目录

    一、 引言
    1.1 定位与目标
    1.2 对象
    1.3 软件需求分析理论
    1.4 软件需求分析目标
    二、 需求概述
    2.1 项目背景
    2.2 需求概述
    2.3 系统结构
    三、 系统功能需求
    3.1 功能总览
    3.2 业务流程图
    3.3 数据流分析
    3.4 数据字典
    3.5 E-R图
    四、 软硬件及外部系统接口需求
    4.1 用户界面
    4.2 硬件需求
    4.3 运行环境
    五、 可靠性与可用性需求
    5.1 性能需求
    5.2 安全性需求
    六、 参考文献

    一、 引言

    1.1 定位与目标

    计算机技术高度发达的今天,利用信息技术对大量复杂的信息进行有效的管理成为一种普遍而实用的手段。一方面,这极大的减少了簿记和人力的开销,另一方面,现代计算机强大的计算能力和网络的普遍部署,大大简化了大量信息的处理和流动。学生在线考试系统是评测学生能力的一个重要组成部分,他对教师的工作效率有很大的提高,它不但可以降低对纸质试卷的要求,同时也体现了节约型社会的要求。该系统涉及了学生在线程序能力测评考试,学习成绩插询,以及很多相关信息的综合处理。为了方便配合教师对学生成绩的进一步了解,开发学生在线考试系统是当务之急。学生在线考试系统把试题、电脑改卷、成绩查询的部分管理工作集成到一个统一的平台,各管理人员分工协作、相互配合,及时了解学生编程水平。同时,也可以方便教师针对学生个体不同情况进行分层次指导。

    1.2 对象

    本《软件需求规格说明书》的预期读者是:

    程序教学平台开发经理
    技术部经理
    项目组所有人员
    测试组人员
    SQA 人员
    开发公司授权调阅本文档的其他人员

    1.3 软件需求分析理论

    软件需求分析是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求, 建立可确认的、可验证的一个基本依据。软件需求分析是一个项目的开端, 也是项目实施最重要的关键点。 据有关的机构分析结果表明, 设计的软件产品存在不完整性、 不正确性等问题 80%以上是需求分析错误所导致的,而且由于需求分析错误造成根本性的功能问题尤为突出。因此,一个项目的成功软件需求分析是关键的一步。

    1.4 软件需求分析目标

    对实现软件的功能做全面的描述,帮助用户判断实现功能的正确性、一致性和完整性,促使用户在软件设计启动之前周密地、全面地思考软件需求。了解和描述软件实现所需的全部信息,为软件设计、确认和验证提供一个基准。

    为软件管理人员进行软件成本计价和编制软件开发计划书提供依据。

    需求分析的具体内容可以归纳为六个方面: 软件的功能需求, 软件与硬件或其他外部系统接口,软件的非功能性需求, 软件的反向需求, 软件设计和实现上的限制,阅读支持信息。

    软件需求分析应尽量提供软件实现功能需求的全部信息, 使得软件设计人员和软件测试人员不再需要需求方的接触。 这就要求软件需求分析内容应正确、 完整、一致和可验证。此外,为保证软件设计质量,便于软件功能的休整和验证,软件需求表达无岔意性,具有可追踪性和可修改性。

    二、 需求概述

    2.1 项目背景

    将要开发的软件名为《计算机程序能力在线测评系统》,本项目的提出者是安徽大学计算机科学与技术学院,而开发者是16级安徽大学软件工程班负责,主要用户是安徽大学本科生级研究生, 该软件独立于其他系统,自成一个完整的系统,应用方便。

    2.2 需求概述

    下面就对算机程序能力在线测评系统的设计进行需求分析。

    首先,因为考试是面向特定的某些对象的,所以考试者进入系统应该进行身份验证。考试者进入考试系统后,应该能根据自己的需要选择考试能力水平,所以该 系统还应具有考试难度选择(分为顶级、甲级、乙级)的功能。为了在线考试做到规范,对于每个应试者来说,试卷的试题和题量都应是相同的,但试题并不相同。在线考试基于网络环境,试卷应该从服务器的数据库随机抽取试题后动态生成的。另外,系统还应该对考试时间进行控制,时间到了会要求考试者交卷。考试者选择答案提交后,应该由计算机自动判卷,得到成绩后显示出来。考试完毕后,可以返回登录界面或查询成绩与排名。

    2.3 系统结构

    图2.1 系统结构

    三、 系统功能需求

    3.1 功能总览

    表 3.1 功能总览

    3.2 业务流程图

    完整版(包括图片表格,请访问 http://www.omegaxyz.com/2019/07/23/software-specification/)

    该系统是基于网络技术的一种在线测评系统,管理员通过网络对题库进行维护,添加试题、修改试题、删除试题等操作;考生通过系统完成考试、分数查询等操作;系统自动组卷并且完成试卷的批阅、分数的统计等操作。

    图3.1 业务流程图

    3.3 数据流分析

    学生登陆系统后从试题库中选出一套试题,然后开始答题,答题完后提交给系统,由系统完成对试卷的批阅统计出成绩,学生可以登陆查询。 管理员登陆系统后对系统进行维护更新。

    图3.2 数据流图

    3.4 数据字典

    数据项条目,用于标识实体。数据字典是数据库的重要部分,它存放有数据库所用的有关信息,对用户来说是一组只读的表。它是关于数据信息的集合。它是数据流图中所有要素严格定义的场所,这些要素包括数据流、数据流的组成、文件、加工小说明及其他应进入字典的一切数据,其中每个要素对应数据字典中的一项条目。其中,对引用的一些关键字进行说明 : PK(主键 ),FK(外键 ), Check(检 查的范围约束),Not null(不为空值)。

    完整版(包括图片表格,请访问 http://www.omegaxyz.com/2019/07/23/software-specification/)

    表3.2 考生信息表

    编号 字段名称 字段含义 字段类型 字段长度 是否主键 默认值
    1 uuid 考生考号 Varchar 10 √
    2 name 考生姓名 Varchar 14
    3 gender 性别 Bool 1
    4 password 密码 Varchar 20 123456
    5 mail 邮箱 Varchar 40
    6 phone 电话 Varchar 12
    表3.3 试题难度系数表

    编号 字段名称 字段含义 字段类型 字段长度 是否主键 默认值
    1 idl 难度编号 Varchar 3 √
    2 dsl 难度描述 Varchar 30 NULL
    表3.4 题目信息表

    编号 字段名称 字段含义 字段类型 字段长度 是否主键 默认值
    1 idq 题目号 Varchar 10 √
    2 idl 难度编号 Varchar 3
    3 nameq 题目名称 Varchar 10
    4 des_q 题目表述 Varchar 100 NULL
    5 index_q 索引编号 Varchar 20
    6 pass_n 通过人数 Longint 16 0
    7 att_n 提交次数 Longint 16 0
    表3.5 试卷信息表

    编号 字段名称 字段含义 字段类型 字段长度 是否主键 默认值
    1 idp 试卷号 Varchar 10 √
    2 score_t 总分 Int 8 100
    3 nameq 题目名称 Varchar 10
    4 des_p 试卷表述 Varchar 100 NULL
    5 start_p 开始时间 Date 16 Date()
    6 end_p 结束时间 Date 16 Date()
    表3.6 管理员信息表

    编号 字段名称 字段含义 字段类型 字段长度 是否主键 默认值
    1 uuid_a 工号 Varchar 10 √
    2 name_a 姓名 Varchar 8
    3 password_p 密码 Varchar 20
    4 mail_p 邮件 Varchar 40
    5 phone_p 联系电话 Varchar 12
    表3.7 考场信息表

    编号 字段名称 字段含义 字段类型 字段长度 是否主键 默认值
    1 uuid_s 考场号 Varchar 10 √
    2 name_s 考场名称 Varchar 20
    3 des_s 考场描述 Varchar 100

    3.5 E-R图

    完整版(包括图片表格,请访问 http://www.omegaxyz.com/2019/07/23/software-specification/)

    图3.3 试题E-R图

    图3.4 考生E-R图

    图3.5 成绩单E-R图

    四、 软硬件及外部系统接口需求

    4.1 用户界面

    用户界面是程序中用户能看见并与之交互作用的部分,设计一个好的用户界面是非常重要的,本设计将为用户提供美观,大方,直观,操作简单的用户界面。

    4.2 硬件需求

    移动终端硬件配置应遵循如下原则:具有高的可靠性,可用性和安全性。【描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间的交流的数据和控制信息的性质以及使用的通信协议。】

    4.3 运行环境

    Web 浏览器:0+、Chrome、Opera、Safari、Firefox及任何支持HTML5标准的浏览器。
    标准分辨率:1024768、19201080、2K
    五、 可靠性与可用性需求

    5.1 性能需求

    处理能力
    由于是在线测评系统,其处理能力主要考虑系统能承载的最大并发用户数,按照实际情况的规划,系统至少能承载的最大并发用户数要求达到全校学生总人数*φ,φ为0至1的常数,随服务器容量而定。

    响应时间
    为了能够快捷地提供在线测评服务,系统应该能够快速地响应在线测评请求。用户最终得到结果的响应时间除了与系统响应速度有关外,还与网络状况有关。因此对Web服务器端需要较高的要求。

    表 5.1 相应时间分析

    完整版(包括图片表格,请访问 http://www.omegaxyz.com/2019/07/23/software-specification/

    5.2 安全性需求

    传输的数据都采用高强度的加密算法加密 (DES),使得数据即使泄漏、被截获后,也无法识别相关的数据内容,确保数据安全。对于客户端与服务器交互的数据,使用安全套接子层 (SSL,SSL 加密传输主要是针对 WEB的数据传输,基于重要信息的传输安全考虑而设计的) 进行信息交换,并在客户移动终端和服务器之间重要的信息的交换。

    六、 参考文献

    [1] 卢正鼎, 张照, 周裕强,等. 面向工程设计应用的数据库管理系统EDDBMS[J]. 计算机研究与发展, 1997(s1):328-332.
    [2] 蔡长安, 王琪. 基于B/S模式的学生信息管理系统设计与实现[J]. 计算机工程与设计, 2006, 27(14):2585-2587.
    [3] 李文新, 郭炜. 北京大学程序在线评测系统及其应用[J]. 吉林大学学报:信息科学版, 2005(S2):170-177.

    更多内容访问 omegaxyz.com
    网站所有代码采用Apache 2.0授权
    网站文章采用知识共享许可协议BY-NC-SA4.0授权
    © 2020 • OmegaXYZ-版权所有 转载请注明出处

    展开全文
  • 【软件工程】——软件需求说明书

    千次阅读 2018-11-19 08:21:24
    软件需求说明书上是需求分析的一个文档,是对软件目标及范围的求精和细化,深入描述软件功能及软件的约束范围,使用户和软件开发者对该软件的初始规定有个大概的了解,有利于对项目的开发和后期的维护。 读者:开发...

    1引言

    1.1编写目的

    软件需求说明书上是需求分析的一个文档,是对软件目标及范围的求精和细化,深入描述软件功能及软件的约束范围,使用户和软件开发者对该软件的初始规定有个大概的了解,有利于对项目的开发和后期的维护。
    读者:开发人员与用户代表

    1.2背景

    a. 待开发的软件系统的名称:机房收费系统
    b. 项目的任务提出者:米新江教授
    c. 项目的任务开发者:齐智
    d. 项目的任务的用户:廊坊师范学院全体在校职工及老师
    e. 实现该软件的计算中心或计算机网络:廊坊师范学院的服务器及网络设备
    f. 该软件系统同其他系统或其他机构的基本的相互来往关系。:廊坊师范学院信息技术提高班做技术支持。

    1.3定义

    一般用户:GeneralUser
    学生查看余额:StuInquiryBalanceMenu
    学生查看上机记录:StuInquiryLineRecordMenu
    学生充值记录查询:StuInquiryRechargeRecordMenu
    学生上机状态查看 StuInquiryLineStateMenu
    修改密码:ModifyPwdMenu
    退出:ExitMenu
    操作员:Operator
    注册:RegisterMenu
    充值:RechargeMenu
    退卡:Backscreen
    收取金额查询:InquiryCollectMoneyMenu
    金额返还信息查询:InquiryRefundInfoMenu
    学生基本信息维护:BasicInfoMaintainMenu
    学生上机统计信息查询:InquiryLineSumInfoMenu
    操作员工作记录:OpWorkRecordMenu
    管理员:Admin
    结账:AccountMenu
    添加或删除用户:AddorDeleteUserMenu
    基本数据设定:BasicDataSetMenu
    正在值班教师:TeacherOndutyMenu
    日结账单:DayBillMenu
    周结账单:WeekBilMenu
    帮助:HelpMenu
    说明:InstructionMenu
    关于:AboutMenu
    查询:InquiryMenu
    显示全部:ShowAllMenu
    上机管理:LineManageMenu
    所有学生下线:AllOffLineMenu
    选中学生下线:ChoseOffLineMenu
    退出:ExitMenu

    1.4参考资料

    a. SQL Server视频 耿建玲 浙江大学
    b. SQL Server入门经典
    c. 软件开发工具张洪志 哈尔滨工业大学
    d. 项目需求说明书(GB8567——88)

    2任务概述

    2.1目标

    软件开发的意图:为了机房管理更加方便、减轻教师负担,和不必要的资源消耗。
    应用目标:为了提高学生上机管理的规范化,减轻老师的工作压力以及降低不必要的消耗。
    作用范围:以廊坊师范学院为代表的高等学校的计算机教育实验室
    读者说明:本软件产品是一项独立的软件,而且全部内容自己包含。

    2.2用户的特点

    操作人员:计算机专业的在校老师完全可以胜任。
    维护人员:廊坊师范学院信息技术提高班学习满一年以上的学院均可

    2.3假定和约束

    开发经费限制:5000元以内
    开发期限:截至到2018年11月1日
    软件运行约束:需要win7及其以上版本的操作系统。

    3需求规定

    3.1对功能的规定

    在这里插入图片描述

    3.2对性能的规定

    3.2.1精度

    软件的输入:数值不超过10位,汉字不超过5分,限制禁止输入特殊字符
    输出数据精度的要求:禁止输出特殊字符,禁止输出小数,禁止输出无效字符。

    3.2.2时间特性要求

    a. 响应时间;0.5s
    b. 更新处理时间;0.5s
    c. 数据的转换和传送时间;1s

    3.2.3灵活性

    a. 操作方式上的变化;分为管理员端和学生端,一些操作学生可以通过学生端进行自主操作。
    b. 运行环境的变化;可在win7及其版本的操作系统上运行
    c. 同其他软件的接口的变化;链接校园卡系统进行机房费用充值和退卡。
    d. 计划的变化或改进:降低处理时间,提高容错率。

    3.3输人输出要求

    登陆界面:
    用户名:9位,数字和字符
    密码:10位,数字字符和符号
    上下机界面:
    卡号:10位,只能输入数字
    学生余额查询:
    卡号:10位,只能输入数字
    查看学生上机记录:
    卡号:10位,只能输入数字
    学生充值记录查询:
    卡号:10位;只能输入数字
    修改密码:
    旧口令:11位,只能输入数字字符和符号
    新口令:11位,只能输入数字字符和符号
    确认新口令:11位,只能输入数字字符和符号
    注册:
    卡号:10位;只能输入数字
    学号:9位,只能输入数字
    姓名:5个,汉字和字符
    系别:5个,数字,汉字或字符
    年级:5个,数字,汉字或字符
    班级:5个,数字,汉字或字符
    备注:25位,数字,汉字和字符以及特殊符号
    金额:4位,只能输入数字
    充值:
    卡号:10位,只能输入数字
    充值金额:6位,只能输入数字
    退卡:
    卡号:10位,只能输入数字
    学生基本信息维护:
    要查询的内容:11位,字符,数字,汉字
    学生上机统计信息:
    要查询的内容:11位,字符,数字,汉字
    操作员工作记录:
    要查询的内容:11位,字符,数字,汉字
    添加用户:
    用户名:10位,字符和数字
    姓名:5个,汉字或字符
    密码:10位,数字字符和符号
    确认密码:10位,数字字符和符号
    基本信息设定:
    固定用户一小时费用:2位,只能输入数字
    临时用户每小时费用:2位,只能输入数字
    递增单位时间:2位,只能输入数字
    至少上机时间:2位,只能输入数字
    最少金额:2位,只能输入数字

    3.4数据管理能力要求

    A. 用户信息存储:将系统所涉及的不同级别的用户登陆验证信息,包括对数据的增删改查
    B. 基本数据的设定:设定合理的基本数据,保证机房收费系统的正常运转
    C. 财务管理:定期按照规定的时间进行结账,保证信息的安全性和保密性准确性。

    3.5故障处理要求

    软件故障:软件可能出现兼容性问题,如有问题,请及时联系开发人员。
    硬件故障:可能因为断电、磁盘损坏以及病毒入侵造成信息不完整,请及时联系开发人员。

    3.6其他专门要求

    A.单位保密要求:系统管理员需要由良好的信用和职业道德习惯,能做到对系统信息的保密。
    B.软件的可维护性:出现运行错误需要找专业人员进行维护。
    C.软件的易读性,可靠性:要求用户按照要求合法输入,不得随意对软件的相关空间做非法操作。

    4运行环境规定

    4.1设备

    a. Server要求内存在256M以上,CPU频率在2.0HZ以上
    b. Clinet内存在128以上,CPU奔腾III以上,最大支持20台式机链接到主机上

    4.2支持软件

    操作系统:windows7及其以上版本的操作系统。
    数据库管理系统:SQL Server 2014

    4.3接口

    接口提供:将向用户提供、修改和取消三大命令选择,对应的系统的不同功能实现
    外部接口:键盘,数据,打印机,网线
    内部接口:数据库接口采用SQL链接

    4.4控制

    该系统的主要输入设备是键盘和刷卡机,输出的主要设备是显示器和打印机。

    感谢您的阅读,希望对您有所帮助!

    展开全文
  • 软件需求说明书

    千次阅读 2019-06-24 21:30:16
    软件需求说明书的编写提示 注意:软件功能规格说明书,需要确定用户对软件的需求,要作到明确、无歧义。不涉及具体实现方法。用户能看得明白,开发人员也可据此进行下面的工作(概要设计) 1引言 1.1编写目的 说明...

    软件需求说明书的编写提示

    注意:软件功能规格说明书,需要确定用户对软件的需求,要作到明确、无歧义。不涉及具体实现方法。用户能看得明白,开发人员也可据此进行下面的工作(概要设计)   

    1引言

    1.1编写目的

    说明编写这份软件需求说明书的目的,指出预期的读者。

    1.2背景

    说明:

    a. 待开发的软件系统的名称;

    b. 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;

    c. 该软件系统同其他系统或其他机构的基本的相互来往关系。 

    1.3定义

    列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

    1.4参考资料

    列出用得着的参考资料,如:

    a. 本项目的经核准的计划任务书或合同、上级机关的批文;

    b. 属于本项目的其他已发表的文件;

    c. 本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。

     

    2任务概述

    2.1目标

    叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|

    2.2用户的特点

    列出本软件的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长,以及本软件的预期使甩频度。这些是软件设计工作的重要约束

    2.3假定和约束

    列出进行本软件开发工作的假定和约束,例如经费限制、开发期限等。

     

    3需求规定 

    3.1对功能的规定

    用列表的方式(例如IPO表即输入、处理、输出表的形式),逐项定量和定性地叙述对软件所提出的功能要求,说明输入什么量、经怎样的处理、得到什么输出,说明软件应支持的终端数和应支持的并行操作的用户数。

    3.2对性能的规定

    3.2.1精度

    说明对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。

    3.2.2时间特性要求

    说明对于该软件的时间特性要求,如对:

    a. 响应时间;

    b. 更新处理时间;

    c. 数据的转换和传送时间;

    d. 解题时间;等的要求。

    3.2.3灵活性

    说明对该软件的灵活性的要求,即当需求发生某些变化时,该软件对这些变化的适应能力,如:

    a. 操作方式上的变化;

    b. 运行环境的变化;

    c. 同其他软件的接口的变化;

    d. 精度和有效时限的变化;

    e. 计划的变化或改进。

    对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

    3.3输人输出要求

    解释各输入输出数据类型,并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。

    3.4数据管理能力要求

    说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作出估算。

    3.5故障处理要求

    列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

    3.6其他专门要求

    如用户单位对安全保密的要求,对使用方便的要求,对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。

     

    4运行环境规定

    4.1设备

    列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能,包括:

    a. 处理器型号及内存容量;

    b. 外存容量、联机或脱机、媒体及其存储格式,设备的型号及数量;

    c. 输入及输出设备的型号和数量,联机或脱机;

    d. 数据通信设备的型号和数量;

    e. 功能键及其他专用硬件

    4.2支持软件

    列出支持软件,包括要用到的操作系统、编译(或汇编)程序、测试支持软件等。

    4.3接口

    说明该软件同其他软件之间的接口、数据通信协议等。

    4.4控制

    说明控制该软件的运行的方法和控制信号,并说明这些控制信号的来源。

     

    需求分析针对对象为用户,设计业务 。

    展开全文
  • 软件需求规格说明书模板(超详细)

    千次下载 2018-02-02 16:59:36
    很详细规范的实例软件需求说明书,标准规范,自用参考
  • 软件需求规格说明书

    2017-09-13 10:14:33
    《xx管理系统》是为了解决xxxx公司关于低值易耗品管理提出的新的工作要求,规范低值易耗品采购、使用等流程,加强低值易耗品审批控制、对各单位低值易耗品的费用统计分析等需求而建设的一套管理系统。
  • 说明: a.待开发的软件系统的名称; b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络; c.该软件系统同其他系统或其他机构的基本的相互来往关系。
  • 软件需求规格说明书模板

    万次阅读 2017-03-13 16:51:39
    软件需求规格说明书模板 软件需求规格说明书是软件开发过程需求分析阶段需要产出的文档,是为了使用户和软件开发者对软件的规格有一个共同的理解而撰写的,软件需求规格说明有标准的模板 ...
  • 如何撰写《软件需求规格说明书

    万次阅读 多人点赞 2011-11-02 10:47:01
    指出编写《需求规格说明书》的目的。下面是示例: 编写此文档的目的是进一步定制软件开发的细节问题,希望能使本软件开发工作更具体。为了使用户、软件开发者及分析和测试人员对该软件的初始规定有一个共同的理解,...
  • 考虑了软件需求规则说明的方方面面的一种模版描述,相信我,很直得。
  • 软件需求规格说明书模板(通用版),内容详实,示例清晰规范。物超所值,是参考的优质范本。共包括五章内容,涵盖引言、需求概述、系统功能需求、软硬件或其他外部接口需求、其他非功能需求等。共计27页,超1万字。
  • 软件需求规格说明书示例,英文版。可以自行翻译一下进行参考,非常不错
  • 软件需求规格说明书——学生成绩查询系统

    千次阅读 多人点赞 2016-10-06 15:05:13
    软件需求规格说明书——学生成绩查询系统
  • 带有范例的软件需求规格说明书,比较好用,在书写软件需求规格说明书的时候,有范例的参考比只是需求要求要来的直观
  • 华为的软件需求规格说明书模板,帮助你写一个结构清晰、完整、高可读性的需求文档,里面还有些填写范例,具有很大的参考价值
  • 软件需求规格说明书_范例

    千次下载 热门讨论 2009-06-29 16:46:30
    收集的软件需求规格说明书_范例,对需要编写软件需求规格说明书是不错的文档
  • Price+Book+项目需求规格说明书,同大部分的华为业务部使用的文档需求差不多;
  • 掌上苏科 软件需求规格说明书 作者:戚春阳时间:2018-3-20目录一、 引言 11.1 编写目的 11.2 项目背景 11.3 定义 11.4 参考资料 2二、 项目概述 22.1 产品描述 22.2 产品功能 22.3 用户特点 4三、 具体需求 43.1 ...
  • 如何写《软件需求规格说明书

    万次阅读 2018-11-28 16:13:48
    自己维护一个终端一年多,今天主管突然要求补写一下《软件需求规格说明书》,有些傻眼。自已可是一个转行来的非正规军程序员,根本没有经验写过这个。没办法,从网上下载一个模板吧,必须标准些,没商量!下载模板...
  • 该文档首先给出了整个系统的整体网络结构...该文档详尽说明了这一软件产品的需求和规格,这些规格说明是进行设计的基础,也是编写测试用例和进行系统测试的主要依据。同时,该文档也是用户确定软件功能需求的主要依据。
  • 这是一份标准版的软件需求规格说明书(SRS)模板,是我们走上程序员的最重要的一步,收藏它绝对超值!
  • Requirements Level Classification(需求的分类) To deal with the diversity in requirements types, Sommerville (2005) suggests organizing them into three levels of abstraction: ...
  • 本标准于1988年首次发布。本标准自实施之日起代替被废止GB/T9385—1988。本标准给出了软件需求规格说明的编制要求,描述了其内容和质量,并给出了提纲示例。本标准适用于编制软件需求规格说明
  • 软件需求规格说明书格式

    千次阅读 2018-07-26 12:56:09
    文档介绍 1、文档目的 2、文档范围 3、读者对象 4、参考文档 ...5、术语与缩写解释 ... 产品的功能性需求 ...2、功能性需求分类 ...4、用户(功能需求) ...产品的非功能性需求 ...1、用户界面需求 ...2、性能需求...
  • 需求规格说明书,介绍在线音乐平台。已经是成品,可用来参考,造福大众
  • 软件需求规格说明书模版

    千次阅读 2009-05-19 15:57:28
    这样的定义称作系统规格说明,并且它在用户和开发人员之间充当合同。 在问题分析阶段分析人员的主要任务是:对用户的需求进行鉴别、综合和建模,清除用户需求的模糊性、歧义性和不一致性,分析系统的数据要求,为.....
  • 软件需求规格说明书样例

    千次阅读 2006-07-03 20:18:00
    1. 引言1.1 编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体.1.2 项目背景1.2.1项目委托单位:**...
  • 软件需求规格说明书--文档模板

    千次阅读 2010-12-30 10:51:00
    软件需求规格说明书
  • [软件需求]软件需求规格说明书样例

    千次阅读 2007-07-13 00:48:00
    1 目的规范化软件开发过程中的《需求说明书》的编写,使之成为整个开发工作的基础。2 适用范围本规范适用于集团开发项目的(软件)《需求说明书》的编写。3 编写内容提示1 引言3.1.1 背景说明说明被开发软件的名称,...

空空如也

1 2 3 4 5 ... 20
收藏数 120,050
精华内容 48,020
关键字:

软件需求说明书