软件开发设计规书的撰写
大家好！下午的课讲关于软件开发设计规书的撰写，一些设计撰写的提纲、解释，在微软我开发了几个产品，具体规书包括什么容给大家看一下。
首先讲定义，作为我们开发管理人员，程序经理，开发管理企业的领导等等，到底是应该写什么样的容，怎么样用它作为指导，帮助我们写软件。写作计划，到底是在撰写开发计划书开发过程中间，到底要做什么样的工作。撰写的提纲，大家也知道，做任何事情提纲就好象一份参照表似的，有这样的参照表写作的时候相对来说容易的多，让所有的员工写的时候都按照规来写。然后讲一下自己写的实例，最后做一些问答，做一个双向的讨论。
整个软件开发过程是一个相当复杂的流程，并不是简单的靠几个设计工程师自己在那边写软件就完，而是要有从头到尾，包括很多人，不同专家，不同的专业，不同的知识放在一起，最后才造成一个完善的软件产品。从决定开始，到计划、设计，最后到写程序、执行，然后还有测试、纠错、保证稳定、发行、部署、调试，整个过程是一个相当长的过程，并不是一个简单的程序。要为了保证软件的质量，能够达到客户满足和满足市场的要求，很要紧的工作，早期工作做的越是完善、仔细，避免后面的工作，由于前面不完善造成的返工，造成的浪费，起到关键性的作用。大家可能在网上读到在美国软件项目管理的权威，写过很多关于软件管理方面的书，很有名一个理论就是说他做过很多研究和调查，发现早期的工作要是没有做好，而造成后面工作的返工，带来的浪费是巨大的。有类似这样的图表，他做出的结论，如果在设计阶段出现了问题，在设计阶段如果你没有及时找到和纠正的话，到执行阶段才发现，你会看到三条不同的曲线，越是早期的错没有发现，最后由于要返工而造成的代价费用越来越高，如果前面没有问题，到最后只是发现半个纠错，花费的代价相当低，因为你是纠错，然后重新测试就完了。可是如果执行的时候，程序编程编错了，后来重新编，重新测试，这个费用相对来说就要高。如果是设计的时候出现错误，由于对需求管理没有管理好，客户和市场的要求都错了，开发出来的东西完全到后面重新执行、重新纠错的话，会看到这个曲线，几乎是几何形上升的，成倍的费用的增加。能够保证控制产品开发过程中间的费用增加，早期工作完善，做设计的时候，越早做的越完善，对控制后面的消耗起的作用是非常大的。
从这个方面讲，我早上举的例子造房子一样，造房子的蓝图，对盖一个房子的重要性，对早期设计的完善作用也是一样的。
什么是设计规书。大家听过很多不同的名称，叫法也不一样，到底是什么东西。首先它是总结一个软件功能和性能、使用方案的总结书，是描述一个产品，到底该为客户提供什么服务，起到什么样的作用，到底可以完成什么任务，从这个角度对软件产品做一个总结,是提供软件功能和性能以及使用方案的总结。也就是说，他应该包括的容是向开发人员很详细的描写清楚，这个软件到底应该怎么工作，他使用方案的总结，他的功能性的总结，而不应该包括产品具体的设计的构架，到底怎么执行，怎么设计，这方面容其实是有不的文档或者文件去总结的。早上也提到，作为开发团队人员，当设计经理、项目经理把软件功能定完以后，真正产品怎么开发，是应该由设计团队人员去做。在微软有的比较大型的团队，我们有所谓的设计师，具体开发也开发团队的领队和开发人员，他们每个人根据功能的描写总结出来具体设计的执行方案，这个其实是不应该写在设计规书里的，所以要理解清楚，设计规书是描写产品对客户怎么用，而不是描写这个产品具体开发逻辑怎么执行，这个是和开发有关
系的。作为设计规书是项目经理的工作，就是要把这个产品的功能描写清楚。它该包含的容和不该包含的容不要搞混乱。
影响设计规书的因素很多，首先最重要的是功能需求，客户对使用软件有它一定的要求，这个软件应该提供什么样的服务，该完成什么样的任务，这方面就叫做功能需求。其实是有不同的好几个因素来影响整个功能需求的，对市场竞争的分析，我们竞争的对手他的产品有什么样的功能，从而得出我们产品应该也有什么样的功能，甚至功能比他更好，这是对功能需求的起影响因素的。还有客户之间的回馈，他说我这个产品为我的行业做工作，这个和明显是客户具体的要求。还有就是用户解决问题的要求，比如说他说我不在乎你这个产品怎么开发，不管你以前的产品，或者你开发的产品以前有什么功能，由于要解决新的问题，必须加进这样的功能。还有用户所谓的使用方案，他真正解决问题，使用的方案流程是怎样的，由于他商业之间运行有直接关系，如果客户商业流程决定是这样的运作的顺序，你软件设备也应该要配合客户使用方案设计。所有这些是最关键的因素影响功能需求，功能需求也是第一个最要紧的影响到设计规书该描述清楚的，解决的什么样的问题。
除此之外是性能需求，光描写说我这个软件按一个键可以写一个数字还不够，如果是客户要求我按一个数字，在0.3秒之写出来，或者是我按键以后印出五百万字来，他显示数据的速度怎么样，他的要求也是影响到设计规书的。他包括整个系统的要求，如果大型的软件，运行的系统，什么样的硬件，什么样的存存什么样的网络，所有这些对性能的需求都起到影响。他的运行的环境，到底是有没有兼容不同的操作平台，不同的操作平台之间不同。对软件的功能也是起到影响的，还有安装部署，特别是大型的系统，因为我在搞工业控制很多年也知道，安装部署的要求，软件在实验室完成跑到真正大型的工厂里，完全是另外一回事。环境的安装部署要求，在很脏的环境里，边上有各种干扰的因素，在这样的运行这样的软件，性能是不是有保证，保证不会死机，数据不会出现什么错误，或者出现错误有什么样的反应，这些都会影响到开发软件的要求。还有是质量要求，有一部分是能解决的，还有一部分是不能解决的，中间的质量要碰到什么情况能够对付，碰到什么情况怎么应付，这些不同的用户都会有详细的要求，这些都是规设计书应该总结的容。
除了这些以外，还有非功能的要求，但是在设计的时候非得考虑到，包括地区、行业，甚至国家在某一个行业里的标准。象在欧美市场上，每个行业都有自己的标准。如果你是设计软件，为某一个行业设计，里面软件设计接口标准，可能使用数据规，对于很多标准，如果你是对那些不熟悉，或者是不了解，甚至是用错的话，开发出来不符合那些客户要求就要改。这些和真正产品的功能毫无关系，可是要为了保证在以后产品开发出去避免这样的错误，由于这样的错误重新返归，就要把这些要求了解清楚。技术还有技术开发的局限，你想这样开发，你想提供这样的功能，但是首先得了解，目前客户所用的设备的硬件，或者他的运作的操作系统环境，有没有某些局限，你想开发性能的时候他没有办法达到，把这些事情弄很清楚的话，避免和客户讲不清楚的争论。在描写功能的时候，这个功能有什么样的能力，没有什么样的能力，描写的很清楚。
还有对时间的依赖，对外在因素的依赖，这里面是需要时间的。项目管理上所谓三角形的定理，有这么多时间，你有这么多资源只能开发出这么多功能。如果把你的时间砍掉一半，其他因素不变的情况下，绝对不能按时间、质量研发出来。这些都会影响到你设计规书的撰写，你要写得很清楚，软件开发哪些能力我是可以完成的，哪些是不可以完成的。还有可用性的需求，软件为了要赢得客户的心，赢得市场的心，很要紧的一点，不光是把软件开发出来大家可以用，客户用了不会觉得很混乱，还是很闹心，还是用起来很顺手，这里面的可用
性，这些东西也是很重要。什么因素决定可用性，用户的特点，不同的用户，不同的使用者，也会决定软件开发应该按照适合他们的要求。开发出来的软件是给一些专门的设计人员用的，那些人受过高等教育，都是很熟悉的，和你开发出来给爷爷奶奶用，这里边不同的客户，都有专门的特性，所以在微软把不同的使用者，分成不同类型的组群，这里的要求怎么回事。所有这些都是影响到可用性需求。整个设计规书在描写完善的软件过程，这些都要考虑到。你不考虑的，不在乎的就去写软件，等你开发出来这些搞错的话，一定影响软件最后的质量。
软件规书的读者，规书是干什么的，为谁而写？作为开发管理人员项目经理到底做什么工作。第一个是给开发团队用的，构架设计、开发执行的计划。开发团队是第一位读者，需要拿这个来盖房子。除此以外，测试团队，在定测试计划的时候，也是根据你对功能的描述。所以如果一个软件里调出一千多个功能，就要定一千多，甚至三千、五千相对应的测试方案。测试团队也是设计规书的读者。文档团队，要让客户能够很方便的了解、熟悉你这个软件的产品，很要紧一点你要有所谓的专门使用手册，如果软件是推向市场的，给爷爷奶奶用，从来没有用过这个软件的，看一个说明书怎么样可以帮助这些没有技术水平的人在很短的时间用这些软件。文档协作很重要，编辑的人也不懂计算机，只能描述这个产品，他们所需要的容也是从这里来的。可用性团队，他们要用产品找一些客户到部进行调查，他们怎么设计测试，可用性的案例？他们也是要根据设计规书的容决定。最后就是市场营销团队，当你有一个完整的设计规书，营销产品的时候，当产品完了以后向市场进行推销的时候，营销人员会比较清楚的了解，这个产品到底有什么样的功能，可以完成什么样的任务，然后向广大市场描写这个产品有什么好处。所以你看到设计规书一般是为这么多团队，这么多人服务的。还有给客户领导，在你产品还没有开发之前，在你和客户交流的时候，我们在某一个产品，为他们专门设计的软件，在开发之前，并不是签一个协议，告诉我写一个东西，然后就开发了。开发之前如果有一个很完整的规书，让客户从头到尾把我整个开发的计划了解清楚，开发的容，我要提供的功能，能够提供的，不能提供的写的很清楚的话，他看了以后就会知道符不符合他的要求。帮助客户了解整个开发的计划，他给你进行回馈，帮你做调整，领导可以根据这个对整个项目进行跟踪。如果你都写清楚了，作为企业的领导，可以从高层次领导整个开发的计划，跟你原来的计划，定的时间表可以知道什么时候可以完成。所以起一个很好的交流作用，帮助团队和领导之间保持一致。
在写规书通常要经过什么样的步骤，做什么事情可以达到最后的结果？在你正在写之前，首先需要确定你要解决的问题，最要紧的是从市场需求来了解，我这个软件到底该做什么，这个软件是为什么样人服务的，做什么样的事情。定出你所要的功能之前，首先先要了解使用方案，三步法，知道客户的使用方案，从那个得出你的需求到底是怎样的。然后根据体的需求总结，定出你要设计的功能到底是哪些。由这些需求、总结定出这些功能，最后根据三步法设计功能。这样你设计的功能都是为了解决客户具体的使用方案，而不是设计的功能是毫无作用的。你不按照这样的方法做，常常让开发工程师自己随意开发出一些功能，功能开发出来看起来很不错，我们叫做很酷，可是不在客户的使用方案里起到具体的作用，可以在某一个软件的菜单上按一下可以做一些什么事情，可是客户根本用不着这个，这种开发出来是一个很大的浪费。让功能的建立设计在了解使用方案的基础上，由此得出的需求上就能避免浪费。这样每个开发出来的功能都是有目的的。
写之前，在很多比较大型的、复杂的系统上，开发团队希望能够有一定的时间做一些技术可行性的调查，先写一个样品。设计经理认为我应该有这样的功能，可是这个开发团队认为说，你设计的功能可能不见得达到你这样的要求，我要看在我现行的平台上，用我现行的技术，可不可以设计出你所要的技术。在之前先做一个简单的调查，看是不是可行。样品做
出来了，团队花时间写最后的规书之前，在四面围着玻璃窗的房间里，把客户请来，做调查。整个使用方案的流程，按这个键可以灌入这个数字，可以起这个效果，你把这个不是真正的软件，是一个虚假，甚至用图象拼起来的，先把这个东西让客户用一下，看一下是不是符合你的要求。他用了说很不错，你就知道你的设计方案是对的，如果有50%认为不符合自己的要求，你就知道你的设计方案出问题了。最后你才定下来写规书。规书不是写完一次就完了，也是好几个回复，我们先写一个出版，把开发团队人员叫来，开发团队的领队，测试师、工程师都叫来，大家一起审核，设计这个东西是不是合理的。第一次出稿回来以后马上推翻了，开发团队说完全是不合理的东西，没有办法开发，一定要重新设计。先有出版，做审核，然后再写正版。有一个回复，可以完了以后这边再倒回去，这是一个流程。我这边写出来重点，非常要紧一点，作为我们项目开发的领导，你会看到每一个具体工作都是要时间的，都需要人去做。要定一个项目开发计划都没有算时间，如果要来回走五遍，可是你只有一遍的时候，你的计划一定要出错。最后写正版，然后审核，全部通过大家签字，说这是我们可以开发的。在某些情况下让客户签字，客户也同意了说你这个设计完全符合我的想法。如果前面的事情都做到家了，对你后面的事情是起到很大的作用。
提纲的容，通常在微软一般包括先写一个前沿，或者梗概，用非常简单的一小段解释这是给领导看或者是给客户看。你对产品开发高层次的理解是不是很清楚，总结你所开发的产品软件到底怎么做，有什么功能。你对一个产品的功能理解，是不是能够精简到几句话，不光你作为一个项目经理可以说出来，让你开发团队所有成员都能够明确无误的说出来，这是非常要紧的。特别是客户要求，你这个文件给他读的时候，可以很清楚的知道，对客户要求的理解是不是很清楚。等规不完的时候，最后回去做对照。看一下我原来定的总结是要完成这些任务，最后设计完以后，回去对照是不是跟原来的计划一样的。从高层次帮你指导整个开发方向应该是怎样的。
除了简单开头以后，要有一个比较详细的总结，整个文档的总结。不光是描述规书的容，其实还要帮助很多第一次读规书的读者，能够有效的读你的规书。有的规书很长，很复杂，有各种各样的符号标记，怎么样理解你用的这些符号。一般的总结包括作者、日期、版本，有时候好几个版本放到部中，你可以告诉他，应该看第三版，而不是第二版。这些容都是帮助读者了解，设计规书中的版本改动的历史是非常要紧的，因为在整个版本改动过程中，虽然全部完了，定稿大家签字了，在真正实行的发现有些功能漏掉的，最后还要去加。你的产品开发完了以后，发现有问题，让你的设计要改，作为设计规书要回去重写。改动的部分要很明确的标出来不同的，在前面的总结加一些版本该都历史。这样追踪整个软件在开发历程过程中，什么时候发生什么问题，都会起一个很好的参照作用。很大一个产品，并不是一个设计规书可以解决的，有时候是好几个、十几个设计规书，好几个不同的项目经理一起来做的，作为一个客户，光读一本可能是不够的，你要做一套，好几本设计规书，规书之间他们相互的联系，你读之前可能参照那本，或者读这个以后，再读那本，之间的参照的容也要写在规书里。所以在文档总结里，把这些容写在里面。
这个项目重要成员，项目总结，包括开发团队的成员，开发团队或者测试团队联系方法。发现问题不知道该找谁，特别是团队的领队都要写在前面，联系方法。还有时间表的总结，你总的产品开发，大的里程碑，几月几号完成怎么样。还有对外部团队的依赖因素，很多开发可能都要靠好几个团队向你提供一部分功能，最后整合起来。在你产品做的时候，9月3号要完成的东西，但是8月30号我要让别的团队向我提供这些东西我9月3号就能完成，如果不能提供我9月3号就完不成。全都写清楚了，你才能知道。
在很多情况下可能要写一个开发的理由，为什么要开发这个软件？特别是作为一个公司开发很多不同的软件下，作为别的团队或者领导，或者是市场营业经理，可能先要了解你这个软件是干什么的，在整个企业的战略情况下，整个战略方向为企业起什么作用。很多产品在开发，技术可能是相互交错的，要讲清楚为什么这个团队花这么多钱、这么多精力，开发这个技术，为什么不用别的团队已经有的技术，或者类似的技术，他们要按照什么样的建议开发，所有的东西都要写出来。一般的容，我们做如下的解释，开发的理由，如果我不开发这个，或者我用别人的，或者我的功能不开发，对公司长期企业的效果起什么影响，对我们市场竞争能力带来什么影响。如果我们不开发，我们的竞争对手六个月之后开发出来，我们的市场可能从第一位降到第五、第六，领导看了以后就会感觉不一样，你要用具体的数字帮你们证明，为什么要开发这样的功能。还有所需要的资源、消费，和不开发带来费用比较也是很要紧的。我要开发什么东西，我要花这么多、精力、人和资源的消费，可是我如果不开发，我市场损失是什么，这就帮助领导或者客户做决定，什么情况下多少钱、多少功能你该做的。对成功企业的影响，对整个市场的影响，要开发不开发，或者现在开发几个月后开发，这个时间是不同的。在描写具体功能之前，先要讲为什么要开发这些东西。要很清楚你开发的目标，我们叫做远景目标。开发的目的是干什么，到底是开发什么样的。为什么要开发，你要讲清楚开发什么样的软件。这是总结和列出来你要开发的远景目标，归根到底要完成什么任务，达成什么目标。
撰写容，首先对公司企业战略上的影响，市场上的影响，技术上、功能上，所有的东西从这些层次来描写，我们该完成什么样的任务。你在开发前把目标定义清楚，后来帮助你做解决，什么情况下开发时用什么技术，如果符合我的目标就做，如果不符合我的目标，到那时候做决定，有全面目标做了到那时候起到很大的作用。
如果是为单个客户开发产品相对来说容易的多，一般情况下你的产品是成千成万人用。这时候就要考虑到，要照顾到不同的用户，他们使用的产品能力不是一样的。对于不同层次的人使用者，对他们要达到的目标是什么，都要写清楚。你对这些做了总结，帮助你在后来做设计的时候，比较容易做出决定，你这个设计功能该怎么样设计。往往这些功能写和不写没有太大区别，最后软件不起到什么关键影响，可是由于做了这些工作，你作为设计人员，项目经理，逼迫你去思考这些问题，如果事先这些问题都没有想过，希望后来设计的软件都能达到前面的功能是不可能的。如果你事先做了，做了思考，跟开发团队商量了，做的这些都是有目的的。
前面讲的是比较高层次的总结，在你描写真正开发的功能之前，就会讲到很要紧的总结使用方案。客户是如何用你的软件解决他的问题的，谁来用，是什么样的人，他们怎么用法，他们使用软件顺序是怎么样的，描写清楚。通常我们是用讲故事的方法，长三来上班，大概机器灌入一个数字，存了文档，交给四，四存了文档，这样用讲故事的方式来描写。还有很要紧的一点，你这样的描写，对测试团队起到一个巨大的帮助。他测试的时候，部测试团队人员可以把自己想象成一个客户，可以按照你所描写的使用方案，测试团队来测试这个软件。按照你所描写的使用方案，按照顺序进行测试。这个是对测试团队设计他们的测试的方案起到很大的作用。
从客户使用软件具体的使用方案总结出你的功能需求，他是这样用的，因为三打开机器要先按这个键，应该有一个输出、输入栏，灌数据，按了以后生成文档，正因为有这样的使用流程，你的需求功能非得有这个键，有数个数据栏、有功能生成文档。前面描写的故事怎么使用的，后来设计总结这些需求功能是符合你这个故事的，保证你设计出来的功能是能够
满足客户按照这个步骤执行他的方案。我们在微软部按照三步法开发软件，其实是有他的道理的，他要避免你开发出来的功能是和前面使用方案毫无关系的，开发的时候造成浪费。满足具体的使用方案，从使用方案总结出来，因为长三按这个键关入数字是这样的工作，做功能描述的时候才描述细节，但首先要有这个键、数据栏。对可有可无的功能要把它的优先顺序写持续。我们所有的功能都有P1、P2、P3，定出来哪些东西是对客户来说是赢得市场最要紧的，非要开发，哪些是可有可无，哪些是可以放到下一代产品再开发。开发之前把这个事情都做好。
有了这些以后，你才描述具体的功能。这里描写如何使用，前面先讲为什么要开发，如何开发，讲了这个软件为什么用，最后来讲这个软件是如何被客户使用的。这部分对所有的功能，所有的界面设计做一个详细的叙述。对这部分容可以按照使用方案，从头到尾把你使用的功能用图象画出来，可以用文章总结。使用大量的图象很要紧，因为你图象化以后，帮助测试人员怎么样测试，帮助开发人员开发出来的功能是要符合你设计的图象。你画出图象，可以让可用性的工程师，根据这个造样品，然后找客户做使用性的调查。这些东西帮助管理整个使用功能控制操作和质量。
除此以外，还有很要紧的一点，在设计过程中间，常常有很多还没有解决的问题，在设计功能中间，并不是说什么东西解决了就可以开发了，产品已经在开发了，可是还有很多东西没有解决。某些技术性的问题，我等别的团队告诉我，或者有些技术性问题我等着调查，或者有些技术问题不知道，我买了硬件以后，做了平台以后做调试才知道，所谓这样都不能遗漏，为了防止这些问题都忘记，把这些问题也写到规书里，有一个表格全部列到里面，有这样的方法就知道，整个开发过程中，让你可以随时回去看，这些没有解决的问题是不是已经被解决了，几月几号该被解决，哪些还要被调查，哪些还要被进一步决定。把没有解决的问题列出来，做个总结，谁对这个问题负责，比如某个技术调查问题是开发团队来做的，把这些该负责的人名字写在里面。目前他的状态到底有没有解决，有的已经解决或者是已经正在调查，在一个表里列出来，分成三档。有这样一个总结很明显的帮助你追踪没有解决的问题，在开发过程中状态是怎样的。如果项目过大的话，甚至可以把这个容拿出来，专门再写一个额外的文件，一个专门的文档专门来总结这样的东西，给别的团队的人看，不见得一定在设计规里，但是这些容帮助你把该解决的问题记下来，帮助事后追踪管理这个过程。
怎么写？我们有这个提纲容，真正写提纲一般是这样的，首先是你组织容材料，写之前保证我该写的容写在里面，就象每一节对照提纲，把你的各种想法写出来。刚开始是用倾斜的方式，不见得写的非常完善，但是保证该写的容在里面，然后回去慢慢再改。很注意要明确你读者的类型，刚刚提到规书是由设计工程师、测试工程师看的，文档编辑要看，他们对设计规书有他们的期望，他们了解的容，你在写的时候要保持在脑子里，写的时候一定要把这些不同读者的容写进去。最后写你的容，把容尽量写的清晰、简短，用大量的图象描述你软件开发的思路，比你用千万的句子来写更好，有一幅画定千万字的说法。
增进版本的设计规书，有时候我写一个规书，并不是一个新的版本，我们公司已经有这个产品了，已经在市场上。我们现在这个公司正在做一个增订型的，做下一个版本，这个时候在以前已有的产品基础说我要做什么样的改变。要解决以前没有解决的问题，为什么现在开发，要解决以前没有解决的问题，我用什么样的设计，改变上一代的设计没有解决的问题。如果写崭新的产品就不会有这个问题，但是很多情况下我们的产品已经有了，我们只是要不停的增进，这种情况下要写这个容。还有一点，设计界面的操作行为，不光是有一个图画，有一个键、数据栏、图象，还要很清楚的描述这个键我按了以后会发生什么情况，数字灌进
去会发生什么情况，有时候用鼠标控制的，鼠标到底是左键按下去发生什么情况，右键按下去发生什么情况，这些都要列在里面。你盖一栋房子，描写的很清楚，用什么样的砖、瓦盖这个房子，用什么样的门窗、玻璃描写很清楚，盖出的房子一定是你所需要的，如果你画的是很大的很粗糙的草图，你盖的房子可能不是你所需要的。还有不要忘记一些基本的文章的结构不要忘记，包括标题、日记、版本数，还有页数，前面的目录、章节，不同的章节用什么标记表明的。别人读两三百页厚的设计版本会不会头脑发昏，怎么样让读者理解你的东西，都要写在里面。还有公司项目部名称，如果公司项目很多的话，有时候项目有代号，代号太多可能读者搞不清楚，对项目容做一个解释。很多情况下文档是部使用，作为公司的，不能流传出去。你作为项目经理要写的很清楚，告诉团队成员，这个产品开发不能把这个文档公开给别人。在写一个完整的设计文档的时候，这些规书里都要写在里面。
软件设计规书的图示，我们现在正在开发的软件，有一个图象表示里面各种软件组成部分是什么东西，除此以外会看到，用标记来标出来具体使用界面的元素到底是干什么的，按了这个键以后，每个键起什么作用。我现在做的设计，我觉得是把已有的软件拿来，配上画图的软件，把已有的软件使用界面的元素拼凑起来，设计出来的软件看起来好象真的一样。虽然现在没有这样的软件，但是已经有这样的图象，拿这个给测试人员、测试团队或者项目文档编辑人员看，他们就一目了然，知道这个软件怎么回事。但是这样的做法很多人觉得很麻烦，我不会画图。还有一个方法，微软里有一个使用界面设计的模板，这不是一个真的软件，但是画出来和真的差不多。描述每一个具体的功能里面到底做什么。
需求总结，比较简单的方法就是用一栏，用数字，分成几个大的档次，比较通用的我们叫做第1，有这个数字可以比较容易，当设计有问题了，当和别人谈话的时候，读我的需求规总结去读我的1A等等，可以找到。有菜单，上面有什么选择全在上面，菜单下面都有一个横杠，当时设计的时候没有这个，当时测试团队找我抱怨，说没有把这个标清楚，开发团队也没有测出来，我测试的时候也没有办法测试。所以我现在学会了，我都写的很清楚。某个菜单按右键，都写的很清楚。在早期设计的时候到后来的时候确定是错误的，需要去掉的。测试人员测试的时候看到原来设计是有的，后来决定没有，全部写在里面，让测试人员看得很清楚。然后描写所有使用界面，软件启动的时候看到怎么回事，详细的功能也会看到。储标键怎么用会有详细的描述，如果没有详细描述的话，测试人员不知道，有了这样功能详细的描述，对规书进行审核的时候，大家都会了解，你这个设计原来是这样的，这个是合理或者是不合理的。每个软件使用界面的元素，都是用一个表格进行总结的。首先是干什么用的，很重要的一点他的行为是什么，然后把他的行为全部列出来，因为这些是帮助开发、测试团队测试开发出来的功能，能不能达到，行为能不能适合符合标准。抓放的过程在什么样的情况下发生什么情况，描述的很清楚。所有使用界面里元件是怎么样的，改用什么字标全部列出来。光标是什么形状，该用什么颜色，设计完以后，开发团队通过开发人员按照这个开发，就不会争论不清楚，不下来以后就避免理解的混乱。整个软件功能规描述用很多图象标出来的话，就省得你花很多时间进行字的描述，但是关键的行为描述出来，关键的图象开发人员就可以轻松的按照你这个图象去开发。
密级：用户需求说明书模板 软件开发项目xx组 二О一六年八月二十七日文件修订记录
目录 1. 概述 (4) 1.1编写目的 (4) 1.2用户简介 (4) 1.3项目的目的与目标 (4) 1.4术语定义 (5) 1.5参考资料 (5) 1.6设计与实现的限制 (5) 2. 现有系统的描述 (6) 2.1组织机构与职责 (6)
2.3作业流程 (7) 2.4报表 (7) 2.5存在的问题 (7) 2.6可能的变化 (8) 3 功能需求 (8) 4 界面与接口需求 (9) 4.1用户的界面需求 (9) 4.2外部的接口 (10) 5 性能需求 (10) 5.1时间要求 (10) 5.2空间与数值性能 (10) 6 其他需求 (11) 6.1系统的安全性 (11) 6.2系统的可靠性 (11) 6.3系统的灵活性 (11) 6.4其他 (11) 7 非功能需求 (12) 7.1用户特点 (12) 7.2法律法规、版权 (12) 7.3兼容性 (12) 7.4联机帮助信息 (12) 7.5购买组件 (12) 8 系统约束 (12) 9用户验收标准 (13) 9.1验收标准： (13) 9.2功能验收标准可依据以下方面制定： (13) 9.3性能验收标准： (13) 附录A ××× (16) A.1××× (16)
附录B ××× (16) B.1××× (16) B.2×××161. 概述 1.1 编写目的 为了使用户与开发人员之间相互了解，对用户需求进行明确定义，使之成为整个开发工作的基础，并提供一个软件系统度量和遵循的基准。该文件可作为用于确认软件产品是否满足给定需求的验收标准。 1.2 用户简介 在本章节中要将用户的基本情况描述清楚，以便于分析人员划定系统范围，进行关于功能与进度、成本、性能等方面的平衡决策。 基本情况举例： ?企业性质 ?规模（员工数量、经营业绩等） ?业态 ?地理位置与布局 ?产品或服务的种类 ?管理模式 ?用户使用计算机系统的经历 ?…... 1.3 项目的目的与目标 项目目的是开发本系统的意图的总概括，目标是将目的细化后的具体的描述，项目目标应是明确的、可度量的、可以达到的,项目的范围应能确保项目的目标可以达到。
保密级别：S 资料编号：SRS-[产品代号] -[序列号] 版本：V[*].[*] [产品型号名称（二号字体）] [部件型号名称（可选、小二号字体）] 软件需求分析说明书 共11页 编制： 审核： 审定： 会签： 批准： XXXXXXXXXX公司 [****]年[**]月[**]日
文档修改记录
目录 1引言 (2) 1.1编写目的 (2) 1.2范围 (2) 1.3定义、首字母缩写词和缩略语 (2) 1.4参考资料 (2) 2项目概述 (3) 2.1产品描述 (3) 2.2产品需求 (3) 2.2.1功能需求 (3) 2.2.2性能需求 (4) 2.2.3可服务性需求 (4) 2.3用户及用户特点 (4) 2.4一般约束 (5) 2.5假设和依据 (5) 3用例描述 (5) 3.1用例1 (5) 3.2用例2 (6) 3.3用例n (6) 4外部接口需求 (7) 4.1用户接口 (7) 4.2硬件接口 (7) 4.3软件接口 (7) 4.4通信接口 (8) 5设计约束 (8) 5.1其他标准的约束 (8) 5.2硬件的限制 (8) 6属性 (8) 6.1可用性 (8) 6.2安全性 (9) 6.3可维护性 (9) 6.4可转移＼转换性 (9) 6.5警告 (9) 7其他需求 (9) 7.1数据库 (9) 7.2操作 (10) 7.3场合适应性需求 (10) 8附录 (10)
[说明：本模板中的蓝色字体与橙色字体为说明性文字，在最终提交的文档中请删除这些说明性的文字。] 1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者范围。 1.2 范围 说明： a．待开发的软件系统的名称； b．说明软件将干什么，如果需要的话，还要说明软件产品不干什么； c．描述所说明的软件的应用。应当： 1）尽可能精确地描述所有相关的利益、目的、以及最终目标。 2）如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。 1.3 定义、首字母缩写词和缩略语 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4 参考资料 列出要用到的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
企业费用管理系统 用户需求说明书 编写：日期：2009-6-18 审核：日期： 批准：日期： 受控状态：是 发布版次：2.0 日期： 编号：
变更记录 签字确认
目录 1概述 (5) 1.1目的 (5) 1.2背景 (5) 1.3范围 (5) 1.4术语定义 (6) 1.5参考资料 (7) 1.6任务概述 (7) 1.6.1目标 (7) 1.6.2用户的特点 (7) 1.6.3假定和约束 (9) 1.7运行环境 (9) 1.7.1软件环境 (9) 1.7.2硬件环境 (9) 1.7.3接口 (10) 1.7.4控制 (10) 1.8需求规定 (11) 1.8.1对功能的需求 (11) 1.8.2对非功能性的需求 (19)
1概述 1.1目的 本说明书目的在于明确说明系统需求，界定系统实现功能的范围，指导系统设计以及编码。 本说明书的预期读者为：用户代表、项目组成员。 1.2背景 a)拟开发的软件系统的名称为：企业费用管理系统。 b)本项目由中软卓越重庆培训中心提出，指派给技术规划部进行开发。 c)本项目以中国内资企业的一般费用管理制度为依据。 d)本系统为一个独立运行的系统，暂不考虑和其它系统的连接关系。 1.3范围 本系统的目标是管理企业费用的计划和使用过程。 系统包括企业的费用预算和报销两项基本管理工作； 系统包括为了开展上述工作而作的组织结构设置、费用体系设置、管理角色设置、审批体系设置。 系统还包括为了监控、分析各项基本管理工作而编制的各项统计报表。
1.4术语定义 【费用】本文中，费用指企业生产经营活动中产生的各项费用。例如人员工资、福利费、办公费、差旅费等管理费用，又如原材料采购、仓库租赁等生产费用。 【预算】用数字编制未来某一个时期的计划，也指经企业决策部门批准的企业在一定时期的收支预计。企业的各项支出只能在预算范围内审批，有利于控制企业的费用支出。在本系统中，预算仅指在支出预算。 【报销】指个人因处理公司的事务或受公司指派执行公司的某项公务而发生的费用，由经办人或申请人按公司的规定，依据业务发生的原始单据(发票)向公司报销费用，领取现金或银行存款的一项经济活动。 【审批】指预算和报销中的审核、批准操作。审批控制操作时，一般由费用发生部门业务人员提出申请，经有关管理人员审批后执行。审批一般遵循归口分级管理原则。 【归口管理】即按照管理职能安排企业内部各部门、各单位在期间费用上的权责制，调动各部门、各单位管理好相关费用的积极性。比如，管理费用主要由行政管理部门管理，销售费用由销售部门管理，财务费用由财务部门管理，进货费用由进货部门管理，进一步说，管理费用的报销事项要由行政主管领导批准、销售费用的报销事项要由销售主管领导批准。 【分级管理】各管理部门应当根据各项费用的具体情况，将费用控制责任层层分解，层层落实，让归口管理部门的所属单位和个人都对相关费用控制和管理负有责任，从而加强对费用的控制。比如，销售部经理负责确认销售费用的发生情况属实，销售总监负责确认销售费用的发生是必要的，财务经理负责确认每一笔报销是在预算范围内的支出。 【统一管理】财务部门作为综合管理部门，应对费用进行统一管理。所有预算由财务部统一初审。所有费用开支都由财务部门统一办理报销手续。
用户需求说明书模板文档标识：当前版本： 当前状态：草稿 发布日期：发布 修改历史 日期版本作者修改内容评审号变更控制号
目录 1引言 (3) 1.1 编写目的 (3) 1.2 项目背景 (3) 1.3 术语定义 (3) 1.4 参考资料 (3) 2综合描述 (3) 2.1 产品介绍 (3) 2.2 目标范围 (3) 2.3 用户特性 (4) 2.4 约定假设 (4) 3用户需求（可剪裁） (4) 3.1 总体需求（可剪裁） (4) 3.2 内容需求（可剪裁） (5) 4功能需求 (5) 4.1 数据需求（可剪裁） (5) 4.2 接口需求（可剪裁） (5) 4.3 权限控制需求（可剪裁） (6) 4.3.1 系统安全要求（软硬件） (6) 4.3.2 用户角色 (6) 4.3.3 角色权限控制 (6) 5非功能需求 (6) 5.1 用户界面需求（可剪裁） (6) 5.2 性能需求（可剪裁） (7) 5.3 压力需求（可剪裁） (7) 5.4 主流技术应用需求（可剪裁） (7) 5.5 安全需求（可剪裁） (7) 5.6 故障处理需求（可剪裁） (7) 5.7 环境需求（可剪裁） (7) 5.8 产品质量需求 (7) 5.9 其他需求（可剪裁） (8) 6需求优先级 (8) 7附加说明（可剪裁） (8)
1引言 1.1编写目的 本节描述编写该用户需求说明书的目的，并指出预期的读者。 1.2项目背景 本节描述用户需求说明书中所定义的产品的背景和起源，以及同其他系统或其他机构(行业里兄弟或对手单位)的基本相互关系等。当在已有的系统上进行特性开发时，如果新特 性与已有系统的特性之间存在关系，则应在本节说明其相互之间的关系。 1.3术语定义 本节可列出本文件中用到的专门术语的定义、外文首字母组词的原词组等。 1.4参考资料 本节列举编写用户需求说明书时所参考的资料或其他资源，这可能包括用户合同、公司 规范、技术书籍等。在这里应该给出详细的信息，包括资料名称、版本号、作者、日期、出 版单位或资料来源，以方便读者查阅这些文献，可用以下格式表示： 资料名称版本号作者日期出版单位/资料来源备注 2综合描述 2.1产品介绍 本节简要描述产品的特性。 2.2目标范围 本节简要描述产品的应用目标、作用范围等。
软件项目名称软件需求规格说明书 拟制: 审核: 批准:日期: 日期: 日期:
文件修改记录
目录 1 范围 (4) 2 总体概述 (4) 2.1 产品描述. (4) 2.2 软件功能. (4) 2.3 一般约束. (5) 2.4 假设和依赖. (5) 3 具体需求 (5) 3.1 功能需求. (5) 3.1.1 功能需求.................... 1 5 3.1.2 功能需求.................... 2 6 3.1.n 功能需求n (7) 3.2 外部接口需求. (7) 3.2.1 用户接口 (7) 3.2.2 硬件接口 (7) 3.2.3 软件接口 (7) 3.2.4 通讯接口 (7) 3.3 性能需求. (7) 4 设计约束 (8) 4.1 标准的约束. (8) 4.2 硬件的限制. (8) 4.3 技术的限制. (8) 5 软件质量属性. (8) 5.1 安全性. (9) 5.2 可维护性. (9) 5.3 可移植性. (9) 6 其他需求 (9) 6.1 数据库. (9) 6.2 本地化. (10) 7 待确定问题 (10)
模板使用说明： [1] 注明可选的部分，可以根据实际情况选择是否填写；如果不必说明，请保留相关的章节标题，同时在该可选章节的内容中填入“无” ；未注名可选的，则必须描述；如果有些设计此模版中没有合适的地方填写，则补充在最后的其他栏目中 [2] 模版中斜体字相当于撰写指南，最后文稿请将本模板中所有的斜体字部分全部删除。 [3] 模板里并不说明设计技术和方法，而只是说明应包含哪些内容，以及如何描述、组织这些内容。
需求说明书 目录 1. 引 言 ........................................................................................................................................... ...................... 4 1.1 编写的目 的 ........................................................................................................................................... 4 1.2 背 景 ........................................................................................................................................... ............ 4 1.3 项目专用术 语 (4) 1.4 参考资 料 ........................................................................................................................................... . (4) 2. 任务概 述 ........................................................................................................................................... .............. 5 2.1 目 标 ........................................................................................................................................... ............ 5 2.2 运行环 境 ........................................................................................................................................... .... 5 2.3 条件与限 制 (5) 2.4 工作流 程 ........................................................................................................................................... . (5)
{ ****系统} 用户需求说明书
版本历史
目录 0. 文档介绍 (4) 0.1文档目的 (4) 0.2文档范围 (4) 0.3读者对象 (4) 0.4参考文档 (4) 0.5术语与缩写解释 (4) 1. 产品介绍 (5) 2．产品开发背景 (5) 3. 产品面向的用户群体 (5) 4. 产品应当遵循的标准或规范 (5) 5. 产品的功能性需求 (5) 5.0功能性需求分类 (5) 5.1系统功能模块图 (6) 6. 产品的非功能性需求 (6) 6.1用户界面需求 (6) 6.2软硬件环境需求 (6) 6.3产品质量需求 (7) 6.4其它需求 ..................................................................................... 错误！未定义书签。 附录A：用户需求调查报告 ................................................................. 错误！未定义书签。 A.1用户界面需求............................................................................. 错误！未定义书签。 A.2软硬件环境需求 ......................................................................... 错误！未定义书签。…A.3产品质量需求.......................................................................... 错误！未定义书签。 附录B:用户提供参考资料 .................................................................... 错误！未定义书签。
在与客户交流、查阅业务资料等一系列需求获取和分析工作后，有必要及时整理用户需求，并建立需求文档。本文结合笔者的实践和相关资料给出了一个需求说明书的格式模板，希望能够起到抛砖引玉的作用，同大家作进一步探讨。 XXXX项目用户需求说明书 关于文件的其他属性还可以根据需要添加诸如需求认可负责人、涉及的产品版本号、关联文档编号等内容。 版本历史 目录 0. 文档介绍 (4) 0.1 文档目的 (4) 0.2 文档范围 (4) 0.3 读者对象 (4) 0.4 参考文档 (4) 0.5 术语与缩写解释 (4)
1. 产品介绍 (5) 2. 产品面向的用户群体 (5) 3. 产品应当遵循的标准或规范 (5) 4.同类产品 5. 产品的功能性需求 (5) 5.0 功能性需求分类 (5) 5.n 功能（特征描叙） N (6) 5.n.x 功能N.x (6) 6. 产品的非功能性需求 (6) 6.1 用户界面需求 (6) 6.2 软硬件环境需求 (6) 6.3 产品质量需求 (6) 6.N 其它需求 (6) 附录A: 0. 文档介绍 0.1 文档目的 0.2 文档范围 0.3 读者对象 0.4 参考文档 提示：列出本文档的所有参考文献（包括非正式出版物），格式如下：[序号标识符] 作者，文献名称，出版单位（或归属单位），日期 例如： [P1-MF] Author，计量开发规范，机构名称，日期
0.5 术语与缩写解释 1. 产品介绍 产品介绍主要说明产品特征、用途，项目背景等 2.产品用户群体 （1）描述本产品面向的用户（客户、最终用户）的特征， （2）说明产品对他们的用处，带来的利益，用户可能的购买比例 3.同类产品情况 作为参考依据 4. 产品应当遵循的标准或规范 阐述本产品应当遵循什么标准、规范或业务规则 5. 产品的功能性需求 5.0 功能性需求分类 提示：将功能性需求先粗分再细分，下表中的 Feature A, Function A.1等符号应当被替换成有含义的名称。
电子商务项目需求说明书（范本） 新蛋信息技术（中国）有限公司 二○一一年月日
文档修改历史记录
目录 1概述 (3) 1.1引言 (3) 1.1.1 软件项目名称 (3) 1.1.2软件项目开发背景和目的 (3) 1.1.3软件项目应用范围 (3) 1.2参考资料 (3) 1.3术语定义 (3) 2 系统功能 (3) 2.1功能分解一 (4) 2.1.1定义 (4) 2.1.2功能表述 (4) 2.1.3性能要求 (4) 2.1.4相关表单 (4) 2.1.5流程图 (4) 2.1.6特殊要求 (4) 2.2功能分解二 (5) 3 附录 (5)
1概述 1.1引言 （本需求说明书的编写目的以及阅读对象） 1.1.1 软件项目名称 （说明软件项目全称和简称） 1.1.2软件项目开发背景和目的 （简述软件项目开发背景和目的以及实现了哪些大的功能） 1.1.3软件项目应用范围 （叙述软件项目主要使用的范围、使用者等） 1.2参考资料 （本需求说明书的参考资料，包括法律法规、政策文件、国家标准、制度规范等）1.3术语定义 （逐个定义重要术语，没有可以不写本条） 2 系统功能 （定义本软件项目实现的一级功能及其内涵，一个软件项目由多个一级功能组成）
2.1.1定义 （说明功能分解一的含义以及实现过程） 2.1.2功能表述 （逐一列出对本功能分解一的各项功能表述，每项功能均需详细描述，并使读者没有歧义，描述方式可以为：输入什么、输出什么、需要系统如何加工等） 2.1.3性能要求 （详细列出对本功能分解一的系统性能要求，如：系统数据校验、缺省项判断、系统反应时间、操作的便捷性、错误或故障的处理、系统的接口等） 2.1.4相关表单 （详细列出本功能分解一涉及的相关表单） 2.1.5流程图 （功能分解一实现过程的流程图） 2.1.6特殊要求 （详细列出功能分解一的特殊要求，如无，可以不列）
项目名称 用户需求说明书
文档修改摘要
目录 1文档简介 (4) 1.1 文档目的 (4) 1.2 范围 (4) 1.3 名词定义 (4) 1.4 参考文件 (4) 2系统概述 (5) 2.1 系统介绍 (5) 2.2 系统目标 (5) 2.3 系统范围 (5) 2.4 系统面向用户群体 (5) 2.5 遵循的标准与规范 (5) 3功能需求 (6) 3.1 系统总体功能 (6) 3.2 功能需求1 (6) 3.3 功能需求2 (6) 4非功能需求 (7) 4.1 用户界面需求 (7)
4.2 软硬件环境需求 (7) 4.3 接口需求 (7) 4.4 性能需求 (7) 4.5 品质需求。 (7) 4.6 安全与保密需求 (8) 4.7 扩展性需求 (8) 4.8 其他需求 (8) 5需求优先级 (9) 6附录 (10) 1文档简介 本章将简要地说明用户需求说明书(以下简称本说明书)的目的、范围、读者对象、名词定义和参考文件 1.1 文档目的 本说明书的目的在于阐明XXXXXX系统(以下简称本系统)的用户需求。 本说明书为编制其它有关文件提供基本依据。 本说明书收集和整理了客户的需求，并提供作为与客户讨论和确认需求的依据。
1.2 范围 本用户需求说明书的内容涵盖了客户提出的业务、非功能需求等。 本说明书的阅读、使用者包括： 项目管理人员 软件设计人员 编程人员 软件测试人员 软件质量控制人员 软件维护人员 用户代表（需求方、需求部门主管） 1.3 名词定义 提示：准确地解释本说明书所涉及的字头词和缩写词 1.4 参考文件
组态建模工具需求规格说明书 西安电子科技大学 2011/5/19
目录
1概述 编写目的 指出编写《需求规格说明书》的目的。下面是示例： 编写此文档的目的是进一步定制软件开发的细节问题，希望能使本软件开发工作更具体。为了使用户、软件开发者及分析和测试人员对该软件的初始规定有一个共同的理解，它说明了本软件的各项功能需求、性能需求和数据需求，明确标识各项功能的具体含义，阐述实用背景及范围，提供客户解决问题或达到目标所需要的条件或权能，提供一个度量和遵循的基准。具体而言，编写软件需求说明的目的是为所开发的软件提出： a)软件设计总体要求，作为软件开发人员、软件测试人员相互了解的基础。 b)功能、性能要求，数据结构和采集要求，重要的接口要求，作为软件设计人员进 行概要设计的依据。 c)软件确认测试的依据。 编写依据 指明该《需求规格说明书》的依据。一般可以写依据XXX软件的方案书，策划书等。术语和缩略词
2软件概要 软件总体描述 从总体上描述该软件的情况，包括软件的形式（网站，运行时系统，插件等）和软件的主要的功能，使读者对该软件有一个整体的认识。一般一两段话即可。 软件设计约束及有关说明 软件设计的约束以及有关说明如下所示。 ●开发环境： ●编程语言： ●遵循的规范：软件的设计和开发过程需要严格按照合同要求，根据软件的设计方 案来进行。软件开发过程应遵循软件工程规范，对过程和版本进行管理和控制。 ●测试环境：可以写明在什么单位测试，测试单位使用的软硬件环境。 ●软件交付形式： ●软件交付日期： ●其他：见合同。 使用者特点 指明软件的使用者具有的特定。示例： 本软件主要在甲方工作环境中使用，使用者包括项目管理人员，开发人员及工程师等，使用者在计算机的应用、使用上不存在障碍，都在计算机的操作和使用方面得到过相关的培训。
专 组号：小组成员： 完成时间：
目录 1.系统概述 (3) 1.1. 系统功能简介 (3) 1.2 系统用户角色 (3) 2.理由 (3) 3.项目范围 (3) 4.系统假设 (3) 5.系统定义 (4) 6.用户场景 (5) 7.用户用例 (5) 7.1 用户用例步骤 (5) 7.2系统需求 (9) 7.2.1 功能需求 (9) 7.2.2 非功能需求 (12) 8.文档历史 (14)
1.系统概述 1.1. 系统功能简介 教务处工作人员根据设置的用户名和密码，登录到学生信息管理系统，并对学生提交的信息修改进行审核,,系统优先级高; 档案管理员添加、查看、删除、修改学生的基本信息, 系统优先级高; 老师查看自己所管班级的学生的信息, 系统优先级高; 学生修改、查看自己的某些信息, 系统优先级高; 1.2 系统用户角色 2.理由 由于现在的学校规模在逐渐的扩大，设置的专业类别、分支机构及老师、学生人数越来越多，对于过去的学生信息管理系统，不能满足当前学生信息管理的服务性能要求。本报告对于开发新的<<学生信息管理系统>>面临的问题及解决方案进行初步的设计与合理的安排，对用户需求进行了全面细致的分析，更清晰的理解学生信息管理系统业务需求，深入描述软件的功能和性能与界面，确定该软件设计的限制和定义软件的其他有效性需求，对开发计划进行了总体的规划确定开发的需求与面临困难的可行性分析。 3.项目范围 学生信息管理系统是典型的信息管理系统，其开发主要包括后台数据库的建立、维护以及前端应用程序的开发两个方面。对于前者要求建立起数据一致性和完整性强、数据安全性好的数据库。而对于后者则要求应用程序具有功能完备，易使用等特点。学生信息管理系统对全校学生实行统一的管理，可以方便的进行增添、查询、修改、删除学生信息的工作。为了使本系统成功达到用户的要求，需要在2012.12.28之前完成本系统的开发测试，并写提交相关的技术文档。通过与用户的沟通，及时获得用户的最新需求以便于本系统的完善。 4.系统假设 本项目的开发时间为2012.9.9—2012.12.28 开发人员人数：3人 技术文档写作人员人数3人
XXX项目 软件需求规格说明书 ---------------------------------------------------------------------合肥安慧软件有限公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
1.引言.................................................... 错误!未定义书签。 . 项目背景............................................. 错误!未定义书签。. 编写目标............................................. 错误!未定义书签。. 建设目标（可选）..................................... 错误!未定义书签。. 系统范围............................................. 错误!未定义书签。. 定义/术语/缩写....................................... 错误!未定义书签。. 参考资料............................................. 错误!未定义书签。. 文档阅读指南（可选）................................. 错误!未定义书签。 2.总体说明................................................ 错误!未定义书签。 . 产品介绍............................................. 错误!未定义书签。. 假设和依赖（可选）................................... 错误!未定义书签。. 局限性和排斥性（可选）............................... 错误!未定义书签。 3.功能描述................................................ 错误!未定义书签。 . 业务描述............................................. 错误!未定义书签。. 用户说明............................................. 错误!未定义书签。. 基本配置及运行环境................................... 错误!未定义书签。. 用户场景............................................. 错误!未定义书签。 用例总览......................................... 错误!未定义书签。 详细用例说明..................................... 错误!未定义书签。 4.非功能性需求............................................ 错误!未定义书签。 . 性能要求............................................. 错误!未定义书签。. 可靠性（可选）....................................... 错误!未定义书签。. 安全性（可选）....................................... 错误!未定义书签。. 可移植性（可选）..................................... 错误!未定义书签。. 设计限制（可选）..................................... 错误!未定义书签。. .电源、工艺结构要求（可选）.......................... 错误!未定义书签。. 逻辑数据库需求（可选）............................... 错误!未定义书签。. 其他需求............................................. 错误!未定义书签。 5.接口说明................................................ 错误!未定义书签。 . 用户界面............................................. 错误!未定义书签。. 硬件接口............................................. 错误!未定义书签。. 软件接口............................................. 错误!未定义书签。. 通信接口............................................. 错误!未定义书签。 6.需求变更流程............................................ 错误!未定义书签。 7.设计描述（可选） ........................................ 错误!未定义书签。
佳怡集团知识产权 未经允许，不得擅用 仓储管理系统 用户需求说明书 (V1.0) 佳怡集团物流与信息技术事业部 2016年02月15日
参与人员： 承担人王雨雨 负责人王雨雨 参与人王雨雨、王玉青、刘先坤 相关部门： 佳怡集团物流与信息技术事业部 点点储运配送有限公司 版本历史： V1.0 2016-02-15 王雨雨起草
目录 用户需求说明书................................................................................................................................. I 1引言 . (1) 1.1目的 (1) 1.2背景 (1) 1.3项目概述 (1) 1.4术语 (1) 2部门组织结构 (2) 2.1组织结构 (2) 2.2部门设置和人员职责 (2) 3业务需求 (3) 3.1概述 (3) 3.2功能性需求 (3) 3.2.1部门工作范畴 (3) 3.2.2主要业务 (4) 3.2.2.1主要业务概述 (4) 3.2.2.2业务关联图 (4) 3.2.3.1干线运输作业 (5) 3.2.3.5入库作业 (5) 3.2.3.10上架作业 (7) 3.2.3.15盘点作业 (7) 3.2.3.20拣货作业 (8) 3.2.3.25出库作业 (9) 3.2.3.30库内管理 (11) 3.2.3.38客户管理 (11) 3.2.3.42计费管理 (12) 3.2.3.44报表管理 (12) 3.2.3.47客户下级店管理 (13) 3.2.3.52计量单位管理 (14) 3.2.3.56入库单打印 (14) 3.2.3.58出库单打印 (15) 3.2.3.60库存调整表 (15) 3.2.3.62入库储位统计表 (16) 3.2.3.64异动盘点表 (16) 3.2.3.66通盘盘点表 (17) 3.2.3.68分拣单 (17) 3.2.3资料提供情况 (17) 3.3非功能性需求 (18) 3.3.1资源需求 (18) 3.3.2性能需求 (19)
软件需求规格说明书 文件编号： QMS—PROC－RD02 版本：1.0 受控签章
修改历史
目录 1引言 (2) 1.1目的 (2) 1.2背景 (2) 1.3术语 (2) 1.4预期读者与阅读建议 (2) 1.5参考资料 (2) 1.6需求描述约定 (2) 2.项目概述 (2) 2.1系统功能 (2) 2.2业务描述 (2) 2.3数据流程描述(可选) (2) 2.4用户的特点 (2) 2.5运行环境要求 (2) 2.6设计和实现上的限制 (2) 3.功能需求的描述 (2) 4.非功能需求 (2) 4.1系统性能要求 (2) 4.2系统安全及保密要求 (2) 4.3系统备份与恢复要求 (2) 4.4系统日志 (2) 5.外部接口说明 (2) 6.其他需求 (2) 7 需求变更识别 (2) 8.功能列表 (2) 9.附件 (2)
1引言 1.1 目的 说明编写这份软件需求规格说明书的目的，如：通过本文档定义ＸＸＸ产品的需求，以求在项目组员与相关成员之间达成一致的需求描述。 1.2 背景 描述系统产生的背景，包括： a．需开发的软件系统的名称，和英文缩写（可选），项目编号（可选）； b．列出此项目的任务提出者、开发者 c．软件系统应用范围、用户。 d．产生该系统需求的原因或起源，如社会背景、市场发展、政策趋势、原有系统局限性 1.3 术语 列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。 1.4 预期读者与阅读建议 描述本文档的主要读者，以及这些读者在阅读时的阅读重点与建议。可用列表的方式列 1.5 参考资料 列出有关的参考资料，如： a．本项目经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 d．行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
软件需求规格说明书(案例) 1. 引言 1.1编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体. 1.2项目背景 1.2.1项目委托单位:****公司 1.2.2开发单位:***公司 1.3定义 1.4参考资料 2. 任务概述 2.1目标: <1> 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示 <2>提高效率:利用软件进行管理,避免人工管理的失误以及延迟性,从而实现高效率的管理. 2.2运行环境: <1> 硬件方面:Pentium级处理芯片 1兆显存的兼容显卡 256色,800*600的兼容显示器 标准兼容打印机 <2>软件方面: WIN95操作系统 2.3条件与限制: 编程用计算机一台 完成期限2000/7/1 无资金供给 3. 数据概述 数据流程图如下: 3.1静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据 3.2 动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间 3.3数据库描述: 人事管理数据库:公司内人员的个人详细信息,包括档案信息 销售管理数据库:当日销售记录及以前的销售统计,用于销售分析 财务管理数据库:公司内部账目及收支情况详表 技术管理数据库:公司所需各技术档案的详细记录(包括文档) 3.4 数据字典: <1>数据流词条描述: 1.数据流名:登录信息 来源:用户的输入 去向:系统内部检验部分 组成:用户名,密码 流通量:每次登录输入一次 2.数据流名:登录结果 来源:系统 去向:用户
精心整理需求规格说明书(ISO标准版) 编者说明： 当需求调查、分析工作告一段落时，你就需要将这些需求进行规格化描述，整理成文，即软件需求规格说明书，也就是SRS。这是在软件项目过程中最有价值的一个文档。ISO所提供的标准虽然已经时间久远，但还是颇具参考价值的。 1．引言 1.1编写的目的 [ [ [ 2 解 [ 3 3.2.2时间特性要求 [说明对于该系统的时间特性要求。] 3.2.3灵活性 [说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。] 3.3输入输出要求 [解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对系统的数据输出及必须标明的控制输出量进行解释并举例。] 3.4数据管理能力要求（针对软件系统） [说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。]
3.5故障处理要求 [列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。] 3.6其他专门要求 [如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。] 4．运行环境规定 4.1设备 [列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括： a. 处理器型号及内存容量 b. 外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量 c. 输入及输出设备的型号和数量，联机或脱机； ] 典型的优势是产品会增加组织在市场上的价值，减少运作成本，或提供更好的客户服务。这个优势应该是可度量的，这样才能够让您确定交付的产品是否达到目标。] 2.客户、顾客和其它风险承担者 2.1客户是为开发付费的人，并将成为所交付产品的拥有者 [这一项必须给出客户的姓名，三个以内是合理的。] [客户最终将接受该产品，因此必须对交付的产品满意。如果你无法找到一个客户的姓名，那么也许你就不应该构建该产品。] 2.2顾客是将花钱购买该产品的人 [也给出姓名和相关的信息] 2.3其它风险承担者
软件需求规格说明书模板 分步阅读 软件需求规格说明书是软件开发过程需求分析阶段需要产出的文档，是为了使用户和软件开发者对软件的规格有一个共同的理解而撰写的，软件需求规格说明有标准的模板 方法/步骤 1.第一章是引言。
描述软件需求规格说明书的纵览，帮助读者理解文档如何编写并且如何阅读和理解，包含五个部分： 1.1 编写目的 //对产品(项目)进行定义，在该文档中详尽说明这个产品的软件需求，包//括修正或发行版本号。如果这个软件需求规格说明书只与整个系统的一//部分有关，那么只定义文档中说明的部分或子系统。 1.2 文档约定 //描述编写文档时所采用的标准或排版约定，包括正文风格，提示区或重//要符号。例如，说明高层需求的优先级是否可以被所有细化分需求所继//承，或者每个需求陈述是否都有优先级。 1.3 读者对象和阅读建议 //列举软件需求规格说明书所针对的不同读者，例如开发人员、项目经理、 //营销人员、用户、测试人员等。描述文档中剩余部分的内容及其组织结 //构。提出最适合每一类读者阅读文档的建议。 1.4 项目范围 //提供对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业//目标或业务策略相联系。可以参考项目范围文档，而不是将其内容复制到//这里 1.5 参考资料 //列举编写软件需求规格说明书时所参考的资料或其它来源。可能包括用户//界面风格指导、合同、标准、系统需求规格说明书，用户需求、相关产品//的软件需求规格说明书。这里应给出详细的信息，包括标题名称、作者、//版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。
2.第二章是总体描述。包含六个部分： 2.1 产品前景 //描述软件需求规格说明书中所定义的产品的背景和起源。说明该产品是否//是产品系列中的下一个成员，是否是成熟产品所改进的下一代产品，是否//是现有应用程序的替代品，或者什邡市一个全新的产品。 //如果软件需求规格说明书定义了大系统的一个组成部分，那么就要说明这//部分软件是怎样与整个系统相关联的，并且要定义出两者之间的接口。建//议使用系统结构图或者实体关系图表示 2.2 产品的功能 //概述产品所具有的主要功能，详细内容在第4节描述，所以这里只需要概括//总结，例如用列表的方法给出。很好地组织产品的功能，使每个读者都易//于理解。用图形表示主要的需求分组以及它们之间的联系。 //建议使用数据流程图（DFD）的顶层图或者类图来实现图形化 2.3 用户类及其特征