白云小布
如何才能把软件需求分析做好？
我的第一个故事来自大名鼎鼎的东软。
我在2005年接一个项目的时候，听说这个项目之前是东软做的。
当时东软在做这个项目的时候，整个过程经历了10多次结构性的大变更，局部性的调整更是不计其数。
据说某天早上，客户对某个功能不满意，他们不得不对几百处程序进行修改。
之后客户对修改的内容还是不满意，又不得不将几百处修改重新改回来。
最后这个项目导致的结果是，整个这个项目组的所有成员都离开了东软，并似乎从此不愿涉足软件开发领域。
多么惨痛的教训啊！我常常听到网友抱怨客户总是对需求改来改去，但客户对需求改来改去的真正原因是什么呢？当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。
客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。
如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。
记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。
我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。
当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
软件需求要怎么写啊
需求分析，我刚做了个项目就用它，不知道是不是你想要的1引言 21.1编写目的 21.2背景 21.3定义 21.4参考资料 22任务概述 22.1目标 22.2用户的特点 32.3假定和约束 33需求规定 33.1对功能的规定 33.2对性能的规定 33.2.1精度 33.2.2时间特性要求 33.2.3灵活性 43.3输人输出要求 43.4数据管理能力要求 43.5故障处理要求 43.6其他专门要求 54运行环境规定 54.1设备 54.2支持软件 54.3接口 54.4控制 5软件需求说明书的编写提示1引言1.1编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。
1.2背景说明：待开发的软件系统的名称；本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料 列出用得着的参考资料，如：本项目的经核准的计划任务书或合同、上级机关的批文；属于本项目的其他已发表的文件；本文件中各处引用的文件、资料、包括所要用到的软件开发标准。
列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2任务概述2.1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。
解释被开发软件与其他有关软件之间的关系。
如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。
如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
|2.2用户的特点 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。
这些是软件设计工作的重要约束2.3假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
3需求规定 3.1对功能的规定 用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
3.2对性能的规定3.2.1精度 说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3.2.2时间特性要求 说明对于该软件的时间特性要求，如对：响应时间；更新处理时间；数据的转换和传送时间；解题时间；等的要求。
3.2.3灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：操作方式上的变化；运行环境的变化；同其他软件的接口的变化；精度和有效时限的变化；计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3.3输人输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。
对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3.4数据管理能力要求 说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
3.5故障处理要求 列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.6其他专门要求 如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
4运行环境规定4.1设备 列出运行该软件所需要的硬设备。
说明其中的新型设备及其专门功能，包括：处理器型号及内存容量；外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；输入及输出设备的型号和数量，联机或脱机；数据通信设备的型号和数量；功能键及其他专用硬件4.2支持软件 列出支持软件，包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
4.3接口 说明该软件同其他软件之间的接口、数据通信协议等。
4.4控制 说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
计算机毕业论文中需求分析怎么写？
帮你在5173论文网找到一篇，他们网站还有很多资料可以参考的。
下面就是你要的可行性分析： 可行性分析分析 可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。
本网站的可行性分析主要从经济可行性和技术可行性两方面进行说明。
2.1 经济可行性分析 经济可行性分析是对项目的经济效益进行评价，本课件发布网站作为一个毕业设计，无需开发经费，所以本网站在经济上是可行的。
2.2 技术可行性分析 技术上的可行性分析主要从软、硬件两方面分析实现网站开发的可行性。
该教务信息发布网站采用了当前新兴的Browser /Server模式，即浏览器/服务器模式。
B/S模式，是一种从传统的二层CS模式发展起来的新的网络结构模式，其本质是三层结构CS模式。
在B/S模式中，客户端运行浏览器软件。
浏览器以超文本形式向Web服务器提出访问数据库的要求，Web服务器接受客户端请求后，将这个请求转化为SQL语法，并交给数据库服务器，数据库服务器得到请求后，验证其合法性，并进行数据处理，然后将处理后的结果返回给Web服务器，Web服务器再一次将得到的所有结果进行转化，变成HTML文档形式，转发给客户端浏览器以友好的Web页面形式显示出来。
参考资料： http://www.lw5173.com/article/html/678.html麻烦采纳，谢谢！
留言板需求分析怎么写
1需求获取 2用户的权利与义务 3制定调研计划 4准备调研的资料 5访谈用户 6填写调研表（那本书里有很好的例子） 7编写调研报告 8需求的其他来源 9需求分析 10编写需求文档 比如数据流程，软件结构，数据字典等 11需求管理还有开发背景，客户需求，开发工具，项目细节 开发环境，开发语言，还有你的开发流程等等......我知道的就这么多了，希望能够帮到你！
项目需求要怎么写？
1 项目概述 1.1 建设背景 1.2 建设需求 1.3 建设目标 1.4 建设依据 2 网络及硬件方案 2.1 网络方案 2.2 硬件方案 2.3 系统软件方案 3 平台软件建设方案 4 终端管理方案 5 接口 6 项目组织 6.1 项目组织 6.2 项目管理 6.3 问题管理过程 6.4 项目实施步骤 6.5 项目沟通与交流 6.6 项目风险分析 6.7 风险规避 7 实施计划 ----------------------------------只能给你提供一个简单的目录结构，这样估计你也知道该从哪里下手了~不需要的可以更改，有自己的想法可以加进去~做项目需求调研，最需要的是自己动脑去想~
需求分析实例
回答：海底行 神 10月22日 10:37 尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。
从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。
Gause 和Weinberg(1989)提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。
客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”这些回答可以更直接地认识问题，而这是封闭（close-end）问题所不能做到的。
需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。
一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式（Kiel and Carmel 1995）。
与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。
直接聘请用户进行获取需求的过程是为项目获得支持和买入（buy-in）的一种方式。
尽量理解用户用于表述他们需求的思维过程。
充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。
流程图和决策树是描述这些逻辑决策途径的好方法。
在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。
如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。
如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。
当前的范围太小，以致不能提供一个令人满意的产品。
需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。
正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。
这样说虽然很简洁，但似乎过于简单化。
需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。
你可以使用假设“怎么做”来分类并改善你对用户需求的理解。
在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。
把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。
需求获取讨论会中如果参与者过多，就会减慢进度。
人数大致控制在5到7人是最好的。
这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。
相反地，从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。
这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。
最好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。
没有一个简单、清楚的信号暗示你什么时候已完成需求获取。
当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的构思。
你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。
1. 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。
用户总是按其重要性的顺序来确定使用实例的。
2. 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些新的使用实例，这时也许你就完成了收集需求的工作。
这些新的使用实例可能是你已获取的其它使用实例的可选过程。
3. 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。
4. 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。
5. 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。
以上知识大致上讨论需求分析应该如何做，实际上对于需求分析的方法有很多很多，已经形成了一定的理论，当然这种理论比较偏向与方法学，而方法学的应用主要还是要靠个人。
所以，大家在实际应用的时候，不妨结合自己的实际，有选择性的采用一些方法，那你就是成功的。
用例在需求分析中的使用 多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求（McGraw and Harbison 1997）。
Ivar Jacobson(1992)把这种看法系统地阐述成用例（用例）的方法进行需求获取和建模。
虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。
而最重要的，用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。
注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。
用例的重要功能是用画用例图的功能来鉴别和划分系统功能。
它把系统分成角色（actor）和用例（用例）。
角色（actor）表示系统用户能扮演的角色（role）。
这些用户可能是人，可能是其他的计算机一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外。
它们必须能刺激系统部分并接收返回。
用例描述了当角色给...
画图程序需求分析怎么写
软件开发是根据用户要求建造出软件系统或者系统中的软件部分的过程。
软件开发是一项包括需求捕捉、需求分析、设计、实现和测试的系统工程。
软件一般是用某种程序设计语言来实现的。
通常采用软件开发工具可以进行开发。
软件分为系统软件和应用软件，并不只是包括可以在计算机上运行的程序，与这些程序相关的文件一般也被认为是软件的一部分。
软件设计思路和方法的一般过程，包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。
