需求文档

什么是软件工程？这是一个值得我们软件工程专业的学子们思考的问题。 百度百科上早已给出笼统的定义：软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及程序设计工具、数据库、软件开发工具、系统平台、标准、设计模式等方面。 那么我们自己的软件工程又是什么。我们应从软件和工程两个词来剖析：软件和工程。软件，software，我们每天都用到的抖音，微信等等都是软件，那么软件和程序又有什么区别的，或者说软件就是程序呢。 答案肯定是否定的。软件=程序+文档，是包含程序的有机集合体，程序是软件的必要元素。 而工程是科学和数学的某种应用是以最短的时间和最少的人力、物力做出高效、可靠且对人类有用的东西。顾名思义，软件工程则是应用程序和文档，在适当的外力助力下完成促进社会发展的软件。 首先进行调研，根据人们的不同需求来设计相应程序，第二阶段进行软件开发，程序员们将第一阶段程序的设计转换成计算机可以接受的系统编码。当完成系统编码后，便开始进行软件的测试，希望可以以更小的代价发现尽可能多的错误，避免软件危机的发生。完成一系列工作后便是软件的维护，根据软件的运行情况和新的需求添加，进行不断的完善软件，并增添说明。 总的来说，软件工程并不单单的是一门工程，从Ada Lovelace设计了第一个程序开始后，几十年过去，软件经历了一系列重要的变化与发展，软件开始越来越符合人们的思维模式

可能造成需求不明确的原因有许多，有些需求在最后一刻之前都是无法明确的； 同样的，需求文档缺乏也是常见现象，但是缺乏的 原因却是多种多样 的。 首先，您 处于什么位置 ？您是项目在技术方面的主要负责人吗？还是重要模块的主要负责人？ 您在团队中的位置是第一个重要的要考虑的因素。如果您是 一个大团队的一员 ，并且其他团队成员有同样的困惑，我的建议是暂时 只能按照原来的节奏去展开工作 ，已经发生的问题不可能立刻得到解决，而大型团队一般进行的是较为大型的项目，手头的工作也不是说停下来就能停下来的。 如果您是 团队的重要成员 （即使不是首席技术负责人），负责许多重要模块的研发工作，那么我就要建议您好好的和项目经理坐下来交流一下，但是就我们的经验，直接点出“缺乏明确的需求”是不会有效的。我的建议是，如果您能 就已经完成的工作和项目经理展开讨论 ，用事实说明在项目中遇到的需求困难，以及这种困难已经造成的麻烦，那么 即使不能解决问题，至少大家能建立起一个达成共识的平台 ，不至于在讨论工作量及规模的问题时互相扯皮。 不同系统的 需求特征是不同 的，依据需要完成的 系统的不确定性 （应该从客户及用户对需求的理解程度、开发团队对需求的理解程度、市面上有无成熟的同类产品这三个角度分别去分析） 的大小 ，来确定需求是否有可能在开始时就被明确下来。假设您现在正在开发一个创新的产品或系统

学习网址：http://kb.cnblogs.com/page/107713/ 最近一段时间以来，很多人开始谈论敏捷开发、研究敏捷开发，那么究竟什么才是敏捷开发呢? 　　简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测 试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在 通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。 　　敏捷开发(agile development)概念从2004年初开始广为流行。Bailar非常支持这一理论，他采取了"敏捷方式"组建团队：Capital One的"敏捷团队"包括3名业务人员、两名操作人员和5～7名IT人员，其中包括1个业务信息指导(实际上是业务部门和IT部门之间的"翻译者");另 外，还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过"敏捷开发"的培训，具备相关的技能。 　　每个团队都有自己的敏捷指导(Bailar聘用了20个敏捷指导)，他的工作是关注流程并提供建议和支持

简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。 　　敏捷开发(agile development)概念从2004年初开始广为流行。Bailar非常支持这一理论，他采取了"敏捷方式"组建团队：Capital One的"敏捷团队"包括3名业务人员、两名操作人员和5～7名IT人员，其中包括1个业务信息指导(实际上是业务部门和IT部门之间的"翻译者");另外，还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过"敏捷开发"的培训，具备相关的技能。 　　每个团队都有自己的敏捷指导(Bailar聘用了20个敏捷指导)，他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段，团队人员密切合作，开发有规律地停顿--在9周开发过程中停顿3～4次

简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。 　　敏捷开发(agile development)概念从2004年初开始广为流行。Bailar非常支持这一理论，他采取了"敏捷方式"组建团队：Capital One的"敏捷团队"包括3名业务人员、两名操作人员和5～7名IT人员，其中包括1个业务信息指导(实际上是业务部门和IT部门之间的"翻译者");另外，还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过"敏捷开发"的培训，具备相关的技能。 　　每个团队都有自己的敏捷指导(Bailar聘用了20个敏捷指导)，他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段，团队人员密切合作，开发有规律地停顿--在9周开发过程中停顿3～4次

简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。 　　敏捷开发(agile development)概念从2004年初开始广为流行。Bailar非常支持这一理论，他采取了"敏捷方式"组建团队：Capital One的"敏捷团队"包括3名业务人员、两名操作人员和5～7名IT人员，其中包括1个业务信息指导(实际上是业务部门和IT部门之间的"翻译者");另外，还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过"敏捷开发"的培训，具备相关的技能。 　　每个团队都有自己的敏捷指导(Bailar聘用了20个敏捷指导)，他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段，团队人员密切合作，开发有规律地停顿--在9周开发过程中停顿3～4次

一、瀑布开发 定义 ：瀑布开发模型以文档为驱动，它的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据。 开发流程 ： 需求分析：对于需求进行详细的分析和评估，形成需求分析文档； 设计：技术评估，规划时间节点，形成技术文档以及时间规划； 开发：按照时间规划，进行开发，每个阶段完成一定的内容； 测试：开发完成后，进行测试，有问题就修改，直到可以用为止。 特点 ： 最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。 优点 ： 1、步骤清晰明确； 2、文档完整，开发过程中可以作为参考。 缺点 ： 1、瀑布开发是从工业发展过来的，不适合计算机软件的开发； 2、开发周期长，花大量时间去编写文档，耗费时间、人力； 3、客户只有在整个项目完成时才可以看到成果，会导致信任问题； 4、风险大，在开发过程中并不能明白最后的结果，同时不能适应变化； 故事场景 ： 1、客人到餐馆来点菜（新项目）； 2、不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）； 3、根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）； 4、后厨开始准备（项目启动）； 5、根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）； 6、半个小时了，菜还没上桌，客人饿极了

敏捷有些时候，不仅仅是一个流程，很多时候，还要涉及到心态的变化，从产品研发的角度来说，就需要相关角色转变思想不能还是停留在瀑布的思想上。 1.需求的心态 A）我写完了，你们们慢慢做吧，有问题问我。 ====》需求，研发，测试是一体的，需求人员需要随时关注产品状态，进行确认。产品的质量是大家的责任。 B）这么多的东西，我哪能那么快的写完，你们再等等吧。 ====》沟通比文档重要，当文档造成瓶颈的时候，要明白文档的作用就是交流沟通，那么可以暂时放弃文档，进行沟通，后续补充相关文档。 2.研发的心态 A）需求文档还没出完呢，着啥急。 =====》研发与需求一样，都是要对产品负责的，要抱有需求也会随着迭代的思想,不要向以前一样，还是期盼着文档的大而全的出来才进行了解研发。 B）需求就是这样写的 ====》需求不光是需求人员负责，研发人员也需要对需求进行负责，需要给与需求反馈，需要验证需求文档是否合理。 C）后面有测试呢，差不多就得了。 ====》对于质量也是如此，不能总是依靠测试进行保证，作为研发人员本身也需要提高质量意识，达到每次交付的可交付状态。 3.测试的心态 A）需求文档啥时候出啊？ ====》不能依赖瀑布式心态，等待需求文档完全出完，才能进行测试计划，可以与需求一起进行迭代，需求出多少，就进行多少的测试计划安排。 B）研发必须在XXX时点结束，不然测试时间不足。 =====

一篇不错的文章 http://www.zhihu.com/question/19886426 BRD ：BusinessRequirementsDocument ，商业需求文档。这是产品声明周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。 MRD：Market RequirementsDocument，市场需求文档。获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有MindManager的思维图，Excel的Feature List等。 PRD：Product RequirementsDocument，产品需求文档。进步一细化，这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（usecase）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo

酒店预订管理系统需求分析 一 引言 1.1编写目的 本文档根据酒店管理管理系统的设计要求，提供-个整体的框架结构和设计方向，同时也明确了本系统的部分需求，供使用单位确认系统的功能和性能。 1.2背景 在高节奏生活的今天，人们整天在各个城市穿梭忙碌着，在过去跑到哪个城市后才能进行预定客房，现在看来是香显得太麻烦,目前很多酒店都已经开始使用通过互联网进行客房预订系统。这样进行酒店的管理就显得更加的轻松，能提高工作的效率，为了方使对酒店和酒店大量资源信息的合理，高效的进行组织和管理，同时应酒店的要求，而编写的酒店预订管理软件。 1.3市场定位分析 随着电子计算机和通信技术的发展。人类已经逐渐地进入信息化社会。信息和材料、能源-样成为.种社会的基本生产资料，在人类的社会生产活动中发挥哲乘要的作用。同时人们对信息和数据的利用与处理也已进入自动化、网络化和社会化的阶段..追求高效率、高品质、高安全性的软件产品是广大商家的选择。本次酒店预订管理系统就是针对酒店村酒店庞大、繁农的预订信息等资源的管理面出现的。酒店预订管理系统可用于现在市场上的各种大小型酒店的管理，使得酒店管理人员的工作进一步地高效、简单。 1.4定义 B/S不需婴安装客户端程序。直接采用浏览器( Browser)即可以访问服务器系统。JSP动态网页脚本HTML超文本标记语言MySQL数据库管理系统。 1.5 项目设计原则 1