郑州软件为您详解软件开发之需求分析

       郑州软件公司认为在软件开发过程中，需求分析是最开始的工作，需求分析如果出现偏差或者错误，往往会给项目带来灭绝性的灾难。因此如何保证需求分析的正确性，不偏离用户的需求就成了决定软件项目成败的关键。

       需求验证试图发现并纠正需求工程阶段出现的错误，是在开发方和用户共同参与下的活动。理想的情形是，经过双方验证的需求规格说明书无歧义地定义了系统的行为，是双方对需求达成共识后做出的书面承诺，具有商业合同效果的文档。

       通常有两种手段来检查需求的正确性，分别是需求评审和需求测试。

       1．需求评审

       郑州android开发认为需求评审可以分为正式评审与非正式评审，在需求规格说明书完成后，需求分析人员必须自己对需求做非正式评审。在对需求规格说明书进行检查后，才会将需求规格说明书提交给评审组正式复审。

       复审通常涉及一个小组，小组的成员通常由经验丰富、技术好的人来担任。当然参加评审的人中间还应该有项目经理、QA人员、测试人员、架构师，他们仔细阅读需求规格说明书，并针对自己将要开展的工作内容进行检查，并提出问题。

       正式评审是最后一关，如果正式评审通过了，将进人系统设计阶段，如果在系统设计阶段再跨里程碑来修改需求的话，所花费的代价将极大地增加。因此正式评审将是一个“鸡蛋里挑骨头”的过程，只有所有的人都认为需求已经没有什么可挑剔评审才能通过。

       2．需求测试

       可以认为需求评审也属于需求测试范围，但是这里提的需求测试和评审不同，它是测试部门来测试需求是否符合用户的要求。需求测试不等同于后面阶段集成测试或者系统测试，后面的测试都是软件已经编写完成的条件下，判断软件是否会出错。而需求测试，只是验证需求是否真的是用户的。

       郑州安卓软件开发认为对于需求的测试，可以建立原型、用例等，用户通过操作原型来确定需求是否跟他的期望相同。对于不合理的用户需求，测试人员要和用户核对，确定用户的真实需求。可以说需求测试是需求测试人员和用户共同来执行的。

       需求测试和需求评审是相互补充的，可以并行进行。需求评审是项目的各方干系人共同进行的检查工作，评审工作关注的焦点是分散的，很难将偏离用户的需求检查出来，并且涉及的人很多，因此不可能耗费太长时间。需求测试执行的时间比评审时间长，有专门的关注方面，能够检查出不合理的需求分析。

       郑州苹果软件开发认为需求验证是针对规格说明书的质量进行的，高质量需求叙述和说明具有几个特性。因此，牢记这些特性，有助于编写出更好的需求，生产出更好的产品，也有利于指导需求验证阶段的工作。

       高质量需求叙述和说明的特性如下。

       （1）正确：每个需求必须精确描述要交付的功能。正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的。

       只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的“这是没意义的”“这可能是他们的意思”等众所周知的猜测。

       （2）可行性：在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，在抽象阶段应该有市场人员参与。这个开发人员应能检查在技术上什么能做什么不能做，哪些需要额外的付出或者其他的权衡。

       （3）必要性：郑州ios开发认为每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。跟踪每个需求回溯到出处，如用例、系统需求、规章，或来自其他用户的意见。如果不能标识出处，可能需求只是个镀金的例子，没有真正的必须。

       （4）优先权：为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求、特征，或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优先权。如果所有的需求都被视为同等重要，那么由于在开发中，预算削减、计划超时或组员的离开导致新的需求时，项目经理将不能起到作用。优先权的作用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。

       郑州plc开发认为优先权的级别可以定义3种，高优先权、中优先权和低优先权。高优先权表明需求必须体现在下一个产品版本中；中优先权表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中；低优先权表明有它很好，但如果没有充足的时间或资源，它可以被放弃掉。

       （5）明确：需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。自然语言极易导致含糊。要避免使用一些对于SRS作者很清楚但对于读者不清楚的主观词汇，如用户友好性、容易、简单、快速、有效、几个、艺术级、改善的、最大、最小等。每写一个需要都应简洁、简单、直观地采用用户熟知的语言，不要采用计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部分预期的特性。

       （6）可证实：看是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确地实现。如果需求是不可验证的，决定需求是不是正确地实现就成了判断的事。需求之间不一致、不可行、不明确也能导致不可证实。任何需求如果说产品将要支持什么也是不可证实的。

       （7）完整：不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发现缺少的信息很难。在SRS中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。

       （8）一致性：一致性需求就是不要与其他的软件需求或高级别的系统（商业）需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎，如果只审定修改的部分，没有审定与修改相关的部分，就可能导致不一致性。

       （9）可修改性：郑州erp软件认为当每个需求的要求修改了或维护其历史更改时，分析人员必须能够审定SRS，也就是说每个需求必须相对于其他需求有其．单独的标示和分开的说明，便于清晰地查阅。通过良好的组织可以使需求易于修改，如将相关的需求分组、建立目录表、索引，以及前后参考。

       （10）可追踪：应能将一个软件与其原始材料相对应，如高级系统需求、用例、用户的提议等。也能够将软件需求与设计元素、源代码、用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标识、细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。

       转载请注明出处：郑州知网软件  http://www.nwisdom.com