这妞是个好菇凉
为什么要在做测试计划前对软件需求进行评审和测试？
需求是不断更新的，当客户加上某点或是删去某点功能，需求变更随时都可能发生。
需求的开发是贯穿整个开发过程的，不是做测试计划前就完成。
这是一个不断循环迭代的过程。
需求验证活动可以确保需求符合优秀需求称述的特征，并且符合好的需求规格说明的特征。
因此，在部分需求确定下来时，就对这些已经发现的需求进行评审和测试，尽快开发测试用例，就能够及早发现需求方面的缺陷和问题，这样就可以只用较低的费用解决这些问题。
若是在测试结束后，才发现遗漏了某个重要需求；对于某个不是很重要的需求，开发过程中却将其作为重点等等这些问题，那么这个损失就巨大了，需要开发人员重新开发，甚至于重新回到原点，这样将耗费巨大的人力物力。
平面设计 的需要具备哪些设计要点？
平面设计设计版面构成的四大原则思想性与单一性、艺术性与装饰性、趣味性与独创性、整体性与协调性，是版面构成的四大原则。
一、艺术性与装饰性 为了使版面构成更好地为版面内容服务，寻求合乎情理的版面视觉语言则显得非常重要，也是达到最佳诉求的体现。
构思立意是设计的第一步，也是设计作品中所进行的思维活动。
主题明确后，版面色图布局和表现形式等则成为版面设计艺术的核心，也是一个艰辛的创作过程。
怎样才能达到意新、形美、变化而又统一，并具有审美情趣，这就要取决于设计者文化的涵养。
所以说，版面构成是对设计者的思想境界、艺术修养、技术知识的全面检验。
版面的装饰因素是文字、图形、色彩等通过点、线、面的组合与排列构成的，并采用夸张、比喻、象征的手法来体现视觉效果，既美化了版面，又提高了传达信息的功能。
装饰是运用审美特征构造出来的。
不同类型的版面信息，具有不同方式的装饰形式，它不仅起着排除其他，突出版面信息的作用，而且又能使读者从中获得美的享受。
二、思想性与单一性版面设计本身并不是目的，设计是为了更好地传播客户信息的手段。
设计师以往中意自我陶醉于个人风格以及与主题不相符的字体和图形中，这往往是造成设计平庸失败的主要原因。
一个成功的版面构成，首先必须明确客户的目的，并深入去了解、观察、研究与设计有关的方方面面。
简要的咨询则是设计良好的开端。
版面离不开内容，更要体现内容的主题思想，用以增强读者的注目力与理解力。
只有做到主题鲜明突出，一目了然，才能达到版面构成的最终目标。
主题鲜明突出，是设计思想的最佳体现。
平面艺术只能在有限的篇幅内与读者接触，这就要求版面表现必须单纯、简洁。
对过去的那种填鸭式的、含意复杂的版面形式，人位早已不屑一顾了。
实际上强调单纯、简洁，并不是单调、简单，而是信息的浓缩处理，内容的精炼表达，这是建立于新颖独特的艺术构思上。
因此，版面的单纯化，既包括诉求内容的规划与提炼，又涉及到版面形式的构成技巧。
三、趣味性与独创性 版面构成中的趣味性，主要是指形式美的情境。
这是一种活泼性的版面视觉语言。
如果版面本无多少精彩的内容，就要靠制造趣味取胜，这也是在构思中调动了艺术手段所起的作用。
版面充满趣味性，使传媒信息如虎添翼，起到了画龙点睛的传神功力，从而更吸引人、打动人。
趣味性可采用寓言、幽默和抒情等表现手法来获得。
独性性原则实质上是突出个性化特征的原则。
鲜明的个性，是版面构成的创意灵魂。
试想，一个版面多是单一化与概念化的大同小异，人云亦云，可想而知，它的记忆度有多少？更谈不上出奇制胜。
因此，要敢于思考，敢于别出心裁，敢于独树一帜，在版面构成中多一点个性而少一些共性，多一点独创性而少一点一般性，才能赢得消费者的青睐。
这种独特的版面诉求，能给读者以视觉的惊喜。
四、整体性与协调性 版面构成是传播信息的桥梁，所追求的完美形式必须符合主题的思想内容，这是版面构成的根基。
只讲表现形式而忽略内容，或只求内容而缺乏艺术表现，版面都是不成功的。
只有把形式与内容合理地统一，强化整体布局，才能取得版面构成中独特的社会和艺术价值，才能解决设计应说什么，对谁说和怎么说的问题。
强调版面的协调性原则，也就是强化版面各种编排要素在版面中的结构以及色彩上的关联性。
通过版面的文、图间的整体组俣与协调性的编排，使版面具有秩序美、条理美，从而获得更良好的视觉效果。
教学设计需要掌握哪些要点
教学设计需要掌握的要点： A、教学设计内容与方法 一、主题教案调研（文末要注明教案出处） 1、所调研教案反映出的课堂教学设计特点，包括教学目标、教学重难点的教学处理策略、教学活动过程（导入、讲授新课、练习反馈、小结等环节）的处理、教学媒体、形成性练习的设计特点及其相互关系 2、比较相同主题但不同设计方法的教案，分析其各自的优劣 3、从学科教学法角度考虑如何进行某学科或某类内容的课堂教学设计 4、综合以上调研分析，提出你所设计教学方案的初步设想。
二、运用教学设计系列表格设计一个单元的教学方案 运用教材《教学过程设计》中提供的《课程教学设计表格》、《课堂教学设计表格》系列表格进行针对一个教学单元的课程教学设计及课堂教学设计。
（或者采用最新版本的《教学设计系列表格》） 三、根据教案设计，制作配套的课堂演示软件或相关软件 根据教案设计，制作配套的课堂演示软件或相关软件，同时也便于通过课件直观评价你的课堂教学设计效果。
课件的示范和评价方法如下： 1、在教案设计实践中自觉体会、反思教学设计理论和方法： 2、在你的教案设计中，系统方法如何体现？ 3、在你的教案设计中，教学内容处理是否恰当？如何检验？ 4、在你的教案设计中，运用了哪些学习理论、教学理论？ 5、在你的教案设计中，学习者分析是否充分？并如何影响教学内容、教学策略处理？ 6、在你的教案设计中，如何设计课堂形成性评价？在你的教案设计中，是否用到学习需求分析？ B、备课的方法与形式 但在新课程条件下，随着教师角色的转变和学生学习方式的改变的要求，备课不再是教材内容的简单的诠释、教学过程的简单的安排、教学方法的简单的展示，它的性质、功能、方法已经发生了很大的变化。
它要求教师从新课程理念出发，在落实学生主体学习地位上下功夫，在落实每一个学生自主学习上下功夫，在落实学生合作学习上下功夫，在充分调动每一个学生的学习积极性上下功夫，在防止学生的学习活动流于形式、切实提高课堂效益上下功夫。
因此教师备课已升华为教师教学研究的一个重要内容。
那么如何备课呢？应从以下几方面考虑： 一、准确定位学生学习目标，保底目标和开放目标并重 帮助学生决定适当的学习目标，并确认和协调达到目标的最佳途径，是教师作为学生学习的促进者的重要任务之一。
传统备课中的目标确定是一种知识的预设。
新课堂的特征具有开放性，要求达成学生知识与能力、过程与方法及情感、态度、价值观三维目标。
目标设计上要做到“三个并重”。
即保底目标和开放目标并重，显性目标和隐性目标并重，短期目标和长期目标并重。
保底目标、显性目标、短期目标可理解为本课和本单元知识、能力点要求，从这个角度说，传统的知识点、能力点要求仍然是教师备课中必须重视的。
开放目标、隐性目标、长期目标可以理解。
一是：过程和方法的考虑，必须重视设计每个学生自主思索的平台，必须让每个学生都能用语文的方法思考问题、解决问题；二是：可理解为看不见的方法、情感、态度、价值观要求，主要表现为培养学生热爱科学、勤于思考、善于探索、长于合作、追求真理的学习心理和学习品质。
备课中应考虑两项内容：一是：本课的保底目标、短期目标或显性目标。
这里主要考虑的是知识点和能力点的＂保底＂问题，许多教师怕新课程的＂放＂，担心的是失去音乐的＂命根＂，足见＂保底＂的重要性。
一节课的学习，保底目标、短期目标或显性目标如何定位，怎样实现这个目标，教师应该根据单元学习目标、自读提示、课后练习及三者之间的内在联系来决定。
一般来说教学方面落实教材安排的思考练习内容就可以了，因为那是经过专家研究的一种精心编排，自然具有很强的科学性，不必要去展开，去拔高。
应该首先确定本课元素积累、知识积累和情感的方法准确是考虑学生积极主动学习、积极主动参与合作、积极主动参与交流等开放性、隐蔽性、长期性目标，促进学生积极参与到学习过程中来，培养积极的情感、态度和正确的价值观。
二、改变课堂结构，化教师讲授为学生学习活动 新课程理念认为，课程是经验，课程是人类已有经验和教师、学生个人生活经验的结合，因而新课程强调，教学是教师与学生间、学生与学生间的交流、互动的过程。
在这里师生之间、学生与学生之间分享彼此的思考、经验和知识，交流彼此的情感、体验与观念，在这种交流中生成新的知识，求得新的发展。
所以，备课的第一要务是安排学习活动。
设计学习活动的方法有三。
一是常规法，二是挖掘教材或练习内涵，灵活设计活动，尽可能地寻找学生活动的载体。
第三，咬文嚼字，多向思维，给足学生自由思考的空间，充分安排学生质疑的活动环节，鼓励学生积极大胆思考问题，促进新知识的生成。
教师要想多说也不行，只能做导演。
三、做好组织和引导工作，落实合作和网状学习
需求分析的详细分析
从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解需求分析指需求的分析、定义过程。
需求分析就是分析软件用户的需求是什么。
如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。
如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的（相信大家都有体会）。
比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。
当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。
需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。
在一个大型软件系统的开发中，他的作用要远远大于程序设计。
需求分析阶段的工作，可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。
问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。
这些需求包括：功能需求（做什么）、性能需求（要达到什么指标）、环境需求（如机型、操作系统等）、可靠性需求（不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求（软件运行是所需的内存、CPU等）、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。
分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。
最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型（做什么的模型）。
制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。
请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。
评审通过才可进行下一阶段的工作，否则重新进行需求分析。
需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。
原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。
原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。
但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。
建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。
如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。
以后的目标系统就在原型系统的基础上开发。
原型主要有三种类型：探索型、实验型、进化型。
探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。
实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。
进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
在使用原型化方法时有两种不同的策略：废弃策略、追加策略。
废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改，形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。
系统构造完成后，原来的模型系统就被废弃不用。
探索型和实验型属于这种策略。
追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。
进化型属于这种策略。
客户与开发人员交流需要好的方法。
下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。
如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1、 分析人员要使用符合客户语言习惯的表达 需求讨论集中于业务需求和任务，因此要使用术语。
客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标 只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。
这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。
为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。
如果是切换新系统，那么开发和分析人员应使用一下旧系统，有利于他们明白系统是怎样工作的，其流程情况以及可供改进之处。
3、 分析人员必须编写软件需求报告 分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。
通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人...
软件设计的基本步骤是什么
软件开发是指一个软件项目的开发，如市场调查，需求分析，可行性分析，初步设计，详细设计，形成文档，建立初步模型，编写详细代码，测试修改，发布等。
软件是怎么样开发出来的 第一个步骤是市场调研，技术和市场要结合才能体现最大价值。
第二个步骤是需求分析，这个阶段需要出三样东西，用户视图，数据词典和用户操作手 册。
用户视图 是该软件用户（包括终端用户和管理用户）所能看到的页面样式，这里面包含了 很多操作方面的流程和条件。
数据词典 是指明数据逻辑关系并加以整理的东东，完成了数据词典，数据库的设计就完成了一半多。
用户操作手册是指明了操作流程的说明书。
请注意，用户操作流程和用户视图是由需求决定的，因此应该在软件设计之前完成，完成这些，就为程序研发提供了约束和准绳，很遗憾太多公司都不是这样做的，因果颠倒，顺序不分，开发工作和实际需求往往因此产生隔阂脱节的现象。
需求分析，除了以上工作，笔者以为作为项目设计者应当完整的做出项目的性能需求说明 书，因为往往性能需求只有懂技术的人才可能理解，这就需要技术专家和需求方（客户或公司市场部门）能够有真正的沟通和了解。
第三个步骤是概要设计，将系统功能模块初步划分，并给出合理的研发流程和资源要求。
作为快速原型设计方法，完成概要设计就可以进入编码阶段了，通常采用这种方法是因为涉及的研发任务属于新领域，技术主管人员一上来无法给出明确的详细设计说明书，但是 并不是说详细设计说明书不重要，事实上快速原型法在完成原型代码后，根据评测结果和 经验教训的总结，还要重新进行详细设计的步骤。
第四个步骤是详细设计，这是考验技术专家设计思维的重要关卡，详细设计说明书应当把 具体的模块以最'干净'的方式（黑箱结构）提供给编码者，使得系统整体模块化达到最 大；一份好的详细设计说明书，可以使编码的复杂性减低到最低，实际上，严格的讲详细 设计说明书应当把每个函数的每个参数的定义都精精细细的提供出来，从需求分析到概要 设计到完成详细设计说明书，一个软件项目就应当说完成了一半了。
换言之，一个大型软 件系统在完成了一半的时候，其实还没有开始一行代码工作。
那些把作软件的程序员简单理解为写代码的，就从根子上犯了错误了。
第五个步骤是编码，在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/ 2，通常在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会极大提 高，编码时不同模块之间的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度，让很多程序员因此被迫停下工作等待，这种问题在很多研发过程中都 出现过。
编码时的相互沟通和应急的解决手段都是相当重要的，对于程序员而言，bug永 远存在，你必须永远面对这个问题，大名鼎鼎的微软，可曾有连续三个月不发补丁的时候 吗？从来没有！ 第六个步骤是测试 测试有很多种： 按照测试执行方，可以分为内部测试和外部测试 按照测试范围，可以分为模块测试和整体联调 按照测试条件，可以分为正常操作情况测试和异常情况测试 按照测试的输入范围，可以分为全覆盖测试和抽样测试 以上都很好理解，不再解释。
总之，测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会又不可预料的问题存在。
完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营 状况并持续修补升级，直到这个软件被彻底淘汰为止。
什么是软件开发的核心问题 按照软件工程鼻祖，《人月神话》作者 Brooks 在“没有银弹——软件工程中的根本和次要问题”一章中阐述的思想，软件开发的核心问题就是如何从概念上对一个复杂的业务系统进行建模。
这个建模是含义广泛的，不仅仅包括对象建模，还包括数据建模、算法建模等等一系列的内容。
总而言之是要先找到解决复杂问题的突破口（先要搞明白需要做什么，然后再考虑如何做）。
至于采用什么表示方法（简单文本、UML 图、E-R 图）、采用什么高级语言、是否一定要用面向对象、使用什么开发工具都是次要的问题。
软件开发方法 软件开发方法（Software Development Method）是指软件开发过程所遵循的办法和步骤。
软件开发活动的目的是有效地得到一些工作产物，也就是一个运行的系统及其支持文档，并且满足有关的质量要求。
软件开发是一种非常复杂的脑力劳动，所以经常更多讨论的是软件开发方法学，指的是规则、方法和工具的集成，既支持开发，也支持以后的演变过程（交付运行后，系统还会变化，或是为了改错，或是为了功能的增减）。
关于组成软件开发和系统演化的活动有着各种模型（参见软件生存周期，软件开发模型，软件过程），但是典型地都包含了以下的过程或活动：分析、设计、实现、确认（测试验收）、演化（维护）。
有些软件开发方法是专门针对某一开发阶段的，属于局部性的软件开发方法。
特别是软件开发...
项目需求分析的分析过程
需求分析阶段的工作，可以分为四个方面：问题识别，分析与综合，制订规格说明，评审.问题识别就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准.这些需求包括：功能需求（做什么），性能需求（要达到什么指标），环境需求（如机型，操作系统等），可靠性需求（不发生故障的概率），安全保密需求，用户界面需求，资源使用需求（软件运行时所需的内存，CPU等），软件成本消耗与开发进度需求，预先估计以后系统可能达到的目标.分析与综合逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分.最后，综合成系统的解决方案，给出要开发的系统的详细逻辑模型（做什么的模型）.制订规格说明书即编制文档，描述需求的文档称为软件需求规格说明书.请注意，需求分析阶段的成果是需求规格说明书（好象软考曾经考过这个问题），向下一阶段提交.评审对功能的正确性，完整性和清晰性，以及其它需求给予评价.评审通过才可进行下一阶段的工作，否则重新进行需求分析。
如何做需求分析
一、 我们应当如何做需求分析需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。
这就是敏捷开发倡导的需求反馈。
敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。
只有这样才能及时纠正需求理解的偏差，保证项目的成功。
二、我们应当怎样做需求调研1.初识。
我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。
如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。
这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。
（1）高层领导关心的是宏观的目标，因此软件研发目标、宏观统计报表、决策支持功能，我们应该怎样做需求分析，应当与高层领导谈。
（2）中层领导关心的是具体的效益，即软件给各个部门信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。
他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的操作，以及一些具体业务流程的细节。
（3）基层人员是每一项业务流程的操作者，也是软件今后真正的使用者。
他们是真正了解你所要开发的软件的业务需求的领域专家，是你进行需求调研的重点对象。
但是，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家。
另外 ，他们就是软件今后真正的使用者，让他们参加，会让他们成为今后软件推行的忠实支持者，对其他操作人员的指导者，益处多多。
而他们关心的则是每项操作的细节。
俗话说：万事开头难。
如果你在项目开始的时候总感觉千头万绪不知如何着手，在这里我给大家的三点建议：1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。
随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。
2.拜访。
需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护） 。
在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求 。
不仅如此，技术这东西总有不如意甚至实现不了的地方，我们需要客户的理解与包容，这都需要有良好的客户关系。
尽管如此，我们也不能总是期望客户中的所有人都能与我们合作，很多项目都不可避免地存在阻碍项目开展的人。
3.研讨会。
（1）由于业务人员自身的局限 ，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部分。
划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量；（2）集中式的业务研讨形式和分散式的业务研讨形式；（3）有效抑制个性化差异、分模块组织专项研讨会。
4.业务研讨在需求分析过程中，客户存在的最大问题就是提不出正确的需求，这表现为几种形式：（1）由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。
这类客户在需求讨论过程中，往往只能描述目前自己手工管理的方式是怎样的，不知道计算机会怎样管理。
（2）能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。
这类客户，他们能熟练使用电脑，对信息化管理是清楚的。
他们提出的业务需求从整体上应当是八九不离十的 。
但是，由于没有实物，在软件中的一些具体操作并没有完全想清楚。
（3）能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。
这类客户，参与过很多软件信息化建设，甚至有些还是软件开发的半专业人士。
但是他们提出的业务需求过于具体 ，甚至怎样实现都说出来了，但这些有时候不是最佳设计方案、可能在技术上难于实现，甚至有些就是过于理想化而不可实现。
解决办法：业务领域分析：客户现有的业务流程是什么样的，都有些什么操作？客户在业务中都有些什么事物，什么专用名词，都是怎样定义的，相互之间的关系是什么？客户在每一项操作中的目的是什么，为什么要这样做，他们制作的手工报表都说明了什么问题？（1）我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。
（2）在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求，它们仅仅只能作为我们的一个参考。
（3）还有一些是技术难于实现或者根本就无法实现的需求，我们应当耐心地说服和引导客户，并给他提出一个更加合理的方案。
（4）需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。
只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
5.迭代...
为什么进行需求评审
展开全部 需求评审目的是让项目的参与者（这里主要指研发测试）能够快速理解产品的意图，认可采用的方案。
那作为产品经理，需要注意哪些事情，才能让一个需求评审能够高效的完成呢？ 可以先回忆一下我们评审过程中遇到的一些问题： “这个做了有什么用？” “有没有认真想过？” “唉，你这个做了，之前的XX是不是就没用了” “这个做不了” “有和业务方确认过吗？” “你这个需求这么大，一下子评的完吗？” “我靠，你是不是傻X，哪有这么设计的？” “你是产品经理，你的数据呢？” （欢迎留言补充） 不管是新手上路，还是老司机开车，在需求评审过程中，相信都碰到过上面的情况。
为了让效率更高，目标明确，我们可以在评审前、评审中和评审后做相应的准备： 1、评审前——做好产品基本功 如果是一个商业产品需求，请和你的业务方认真推演产品要解决的问题。
注意要抠出业务方要解决的问题，而不是问业务方“你要不要这个功能？” 作为产品经理，你要相信自己的产品设计能力，业务方提供的产品方案可以作为参考，不能作为指南。
如果一个是工具类的产品或者体验层面的优化，请认真分析各个方案背后的用户心理变化，同时准备好相关数据佐证你的假设。
评审上可能用得到仔细推敲产品方案，是否有考虑过还有其他的方式可以解决问题，不同的方案优缺点各是什么。
提前找到此项目对应的技术负责人，认真的和他们沟通你的方案和想法，技术的小伙伴们不是被动的执行者，让他们参与到你的前期设计中来。
请去掉“我是产品经理，我比你懂市场，我比你懂交互，我比你懂人性”的帽子，很多技术小伙伴真的比你懂。
准备好一份逻辑清晰的需求文档，形式不局限，核心是要表达清楚你的意图。
如果之前评审经常出现表达混乱，说的意思别人不容易懂。
你可以再辛苦点，准备好一份评审大纲仔细review你的需求文档，是否各个细节都考虑到了，尤其是异常的情况，和其他系统有依赖影响的情况。
不然测试的同学会把你问的哑口无言（欢迎补充） 2、评审中——注意表达，注意情绪，控制好节奏 1）参与评审的技术，他们的关注点可能各不相同。
有的擅长剖析你的需求动机业务目标（大部分的技术leader会关心）、有的擅长追求细节（比如测试同学）、有的喜欢带偏话题（在你评审的时候，可能他们会提一个其他的话题）、也有的喜欢用“教导你”的口吻“教你”做怎么产品，还有各种各样 2）需求开始，可以先讲清楚你的业务背景，确保大家理解的前提下再带入你的方案。
然后记得要阐述为什么要用这套方案，而不是其他方案。
这两件事情需要在开始就说的很清楚，讲完后可以停顿让大家提业务背景和方案的问题。
这里要掐断那些喜欢问交互细节，逻辑细节的问题。
这一步骤的重点是要说清楚发生了什么问题，为什么这么干而不是那么干——这样不至于在后续的环节里，又有人提回来质疑你的需求背景 3）复杂的问题，考虑用一些流程图，再结合“总分总”的方式。
可以先说明白整理步骤，先做什么，再做什么，最后做什么。
然后再按步骤细评各个环节的细节，都评完后再阐述一下总的流程。
4）注意话题不要被带偏。
在过程中，出现某个同学说“唉，之前有个XX也是类似的问题，还没解决”。
这个时候作为产品经理，应及时掐住话题源头，可以说这个问题待会私下讨论。
5）新人控不住节奏的时候，可以求助会议上稍微资深的技术大大来控制节奏。
“这个问题好像和本次评审无关，李大大我们会后再聊这个，你看怎么样？”——李大大可能是个技术总监。
6）你也会遇到喜欢爆粗口的技术。
“我操，这有个屁用啊！”“你是不是脑残啊！” 我们要控制好自己的情绪，因为这个粗口的背后，他们想表达的意是：“这样设计是不是不对”？只是加了一个感叹词嘛。
听他们把背后的原因说出来，不建议用“为什么没用啊？”“这样挺好的啊”“我靠，你才脑残”来正面回应他们的感叹词，这会让气氛更尴尬，后面的评审更难进行。
可以问“是有什么问题吗？”“方案哪里不合理？” 7）“这个不好做”、“实现不了的”。
遇到技术们这样的回应时，绝大情况下是背后有一个巨大的开发量。
不建议直接驳斥“这个还这么麻烦啊？”“很简单的啊，这样搞搞就行了啊”。
我们需先权衡是否值得这样的投入？如果的确是一个很重要的业务卡口，可以表达清楚这件事的严重性，就算开发复杂，需要较多的时间也可以接受。
8）做好会议纪要！以便会后讨论和修改 3、评审后——保持持续跟进，反复review 评审结束不代表就等着上线了，接下来要做的是持续的关注。
需要不断的review，确保该表达的细节都有表达需求更新，请维护好更新的记录，在什么时间点更新的，请通知相关的开发测试设计同学，不要藏着掖着跟进开发计划和进度准备二期的内容最后一句，你得让技术感受到你是要做好产品的，不是完成任务的（自行体会）。
希望可以帮到你~
转载请注明出处51数据库 » 软件需求设计评审要点
