sunsen

软件需求是什么？

需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.
关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".
百事通
而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.
需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:
需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.
从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.
任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.
2.需求分析的任务
开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.
目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.
对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?
然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.
近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.
相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.
事实上,需求文档在开发过程中一直起指导作用.

软件需求有哪些

对软件的需求进行的整理需求分为三个层面：用户需求、产品需求和软件需求。用户需求，是产品需求的驱动和源泉，来源有：竞品分析，潜在客户的调研，已有用户提供的资料、调研、建议和投诉、往往由市场人员、销售人员、客服人员收集。有时候，用户需求是不清晰的，因为用户自己也无法描述清楚到底需要什么。产品需求，是从用户需求整理出来的一个需求集合，这个需求集合能够发挥公司的优势或者符合公司的战略发展方向。确定产品需求的时候，必须要承认，企业资源和能力是有限的，不可能让所有人都满意，有所为有所不为，这就是产品经理的工作职责所在。产品需求，是用业务语言表达的，基本是用户可理解的，通常表现为特性需求列表，即feature list。软件需求，是根据产品需求，进行分析，整理，并辅以初步的架构设计。针对每一个需求项目，描述各类用户类型的用户场景，正常过程、可选过程、异常过程及非功能需求。还应包括性能需求和各种质量属性需求、接口需求等。用户需求收集用户需求收集是持续的。产品在任何阶段，都需要持续关注用户需求。不同用户的需求权重是不同的，需求优先级也不同。一般情况是市场或销售会反馈用户的需求，新的竞品也需要研究。用户需求应归拢到产品经理那里，由其组织人员进行需求分析，裁剪需求，确定在哪个版本支持新需求或对已有需求进行变更。还有一类资料来自于客户，但只是技术文档，如接口文档，这类可以直接交给开发团队，作为外部接口文档。用户需求有必要进行管理，如使用知识库之类进行管理。如果公司产品较多，客户、销售或市场一时难以区分归属哪个产品负责，公司也可以安排一个需求收集的产品助理，由其与各产品经理沟通。产品需求分析产品需求分析是软件产品的起点。产品需求分析输入的是用户需求，输出的是产品需求规格书PRD。一个合格的产品经理不是客户需求的简单传递者，而是将各类用户需求综合考虑，再结合公司的战略发展方向和资源优势及限制，产品采用的商业模式，确定产品需求集合。产品经理对目标市场、目标用户了解程度，决定了产品需求分析的质量。产品需求重点考虑下列情况：可用性，不会因为某些功能缺失或者性能障碍导致用户实质上无法使用产品产品有哪些类型的用户，不同类型的用户诉求是什么？现状情况有哪些痛点？竞争产品的哪些优点必须保留，能否进一步强化不要轻易去改变用户的使用习惯，如果需要，哟准备付出市场教育的成本特色功能的价值论证要充分，提高特色功能的易用性研究有哪些商业模式，对软件产品的需求会有什么影响产品需求可行性分析对用户需求进行裁剪，分析整理出产品特性需求，即feature list针对每一条产品特性需求，应说明：用户类型是什么？提供什么价值或解决什么问题？需求的优先级有何限制条件实现是否有技术障碍实现代码多大？是否有专利、监管等法律风险必要时，产品经理可组织预研工作，以验证技术可行性，消除技术障碍。