缘生缘灭缘如水
需求分析在软件开发中的重要性
展开全部 对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。
怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。
软件开发的意义也就在于此。
而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。
--- 经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。
通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。
另外，我们也得为政府部门提供关于商品营运的报告。
”-- -分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。
”-- -经理觉得奇怪：“我不是刚告诉你我的需求了吗？”-- -分析员：“实际上，您只说明了整个项目的概念和目标。
这些高层次的业务需求不足以提供开发的内容和时间。
我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。
”-- -经理：“业务人员都在招商。
他们非常忙，没有时间与你们详细讨论各种细节。
你能不能说明一下你们现有的系统？”--- 分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。
我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。
我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。
”--- 经理坚持道：“行了，行了，我们没有那么多的时间。
让我来告诉您我们的需求。
实际上我也很忙。
请马上开始开发，并随时将你们的进展情况告诉我。
”--- 风险躲在需求的迷雾之后- --以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。
在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。
这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。
这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。
若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。
因此可见——需求分析奠定了软件工程和项目管理的基础。
-- -拨开需求分析的迷雾--- 像这样的对话经常出现在软件开发的过程中。
客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。
那么，我们就拨开雾影，分析一下需求的具体内容：-- -·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
--- ·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
--- ·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
-- -·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
--- ·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。
“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
--- 前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。
其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。
--- 下一层次需求——用户需求，必须从使用产品的用户处收集。
因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。
例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。
--- 经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。
用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。
如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。
--- 在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。
除非遇到的需求极为简单；否则不能这样做。
如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。
--- 优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。
只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。
--- 由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。
-- -客户的需求观-- -...
为什么需求分析是软件发展的第一步
我想提问者可能想问的是：需求分析是软件开发的第一步。
。
。
估计是英文单词 development 翻译的问题。
。
从软件工程和需求工程的角度来讲，需求分析并不是第一步，而且也不可能是第一步，为什么这么说呢？做任何事之前需要先知道做什么，这个对软件开发来讲就是需要先知道客户需求！那么获取客户需求就是必需的，然后通过对客户需求进行“翻译”并且进行 规格化编写后 成为开发人员（如设计人员和代码编写人员）以及测试人员能够理解的软件需求规格说明书来用。
那问题来了，怎么获取客户需求呢？从大的角度来讲两个方面：1 做好需求获取准备，包括客户初步需求的研究（合同）、用户模型（哪些人会使用开发的产品）的搭建、调研人员和被访谈人员的选定和协调、类似产品的了解 2 调研客户的策略和制定规范化的问卷， 这些步骤都非常关键！！！为什么这么说呢？ 因为对于软件应用开发来讲，目前最大的问题是需求质量低下问题！需求质量低下体现在不断的需求变更上。
然后对齐分析发现：其中引起需求变更最大的三个来源就是：需求不完整、需求描述不清晰 和需求丢失，分析这三个来源背后的主要原因有：准备工作不足、不会调研进行需求、不会分析需求、不会描述客户需求和不会规格化软件需求，从而导致需求变更的非常频繁，结果就是项目组靠不断的加班来赶进度和降低成本。
所以从这个角度来讲，需求准备工作或者需求开发是软件开发的第一步。
希望能对你有帮助。
到底什么是软件开发的需求
需求分析，我刚做了个项目就用它，不知道是不是你想要的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控制 说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
软件开发的需求分析说明书是谁做给谁看的
展开全部 软件需求的定义：（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。
实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。
需求工程的定义：需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。
需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。
这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。
需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
需求开发与管理的一些方法：（1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
（2）可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
（4）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。
。
（5）图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。
它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。
这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
（6）数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。
在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。
需求管理的方法主要包括以下一些方面：1）确定需求变更控制过程。
制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。
2）进行需求变更影响分析。
评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。
通过这些分析将有助于需求变更控制部门做出更好的决策。
3）建立需求基准版本和需求控制版本文档。
确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。
每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
4）维护需求变更的历史记录。
将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。
为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。
5）跟踪每项需求的状态。
可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。
6）衡量需求稳定性。
可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。
过多的需求变更＂是一个报警信号＂，意味着问题并未真正弄清楚。
4.需求分析评价标准（1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。
例如尽量采用主语+动作的简单表达方式。
需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。
除了语言的二义性之外，注意不要使用行话，就是计算机术语。
需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。
（2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。
但实际情况是，需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。
要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。
（3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。
在需求过程中，开发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。
严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。
（4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。
实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。
这就要求需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。
