软件需求分析与管理

软件需求分析与管理1.需求工作涉及到哪些内容首先需求包括了产品需求，用户需求，软件需求。产品需求关注的是产品的标准化和通用化，会对收集到的用户需求进行分类和优化，结合业界标准系统模型进行抽象并通用化。用户需求反映的是用户面临的问题域，根据问题域用户期望的能够达到的解决效果;而对于软件需求则是用软件工程的语言结构化和文档化的对用户需求和产品需求的描述。需求工作涉及到需求开发和需求管理。需求开发涉及到需求调研，需求收集，需求分析，需求开发等工作，其中的重点有业务流程，数据字典，业务规则，界面原型。对于基于面向对象的开发方法则涉及到业务用例，系统用例(涉众，基本流，扩展流，业务规则，界面，操作)等诸多内容。需求管理工作涉及到需求的状态管理，变更管理，需求的跟踪，需求的验证和确认等重要内容。在我们需求分析和开发中，最容易忽视的主要有两点，一个就是缺乏需求分析和开发的过程，把用户需求直接作为了软件需求，没有需求建模和抽象的过程。另外一点就是对于性能，安全，易用性，可维护性和扩展性等非功能性需求没有考虑，导致开发出来的系统是一个不好用的半成品。CMMI把需求管理放到2级，需求开发放到3级，实际上真正的提高需求人员的需求分析和开发能力才是解决需求问题之道。需求分析开发做不好，需求变更或追踪管的再好也没有用处，在这点上一定不能本末倒置。2.做好需求分析需要具备哪些知识需求分析岗位主要承担的是系统分析员的工作，做需求分析的人员要有软件工程基础知识的积累，而且最好有一定的软件开发经验积累。自己做过设计开发工作的才能够体会到如何才能够把系统做好，如何更好的把软件需求和后续实现更好的衔接起来。有一本《软件需求》的书讲的很系统，从事需求工作的都值得仔细阅读。对于采用面向对象的需求开发和分析方法的，一定要熟悉RUP统一过程和用例分析和建模。对于管理软件都离不开其涉及到的业务领域，因此要做好需求分析工作必须要熟悉管理软件所涉及到的业务领域，对业务领域相关的标准模型进行分析和研究，对业界的一些标准和最佳实践进行熟悉。比如做供应链管理系统和软件应该熟悉业界标准的SCOR模型，做ERP的应该结合现在的业界比较大的厂商的ERP产品进行学习，对于研发管理系统可以结合PACE和IPD等等。只有熟悉了业务领域才可能在需求调研和分析的时候提供很多有建设性的意见，或者说需求分析人员不是被用户牵着走，而是真正的可以引导用户。3.需求分析的步骤和输出有哪些开始首先是需求的收集，需求收集可以通过调查表，访谈，业界标准，会议讨论沟通等多种方式进行。需求收集第一是要能够很好的描述现状，第二是要搞清楚用户的期望。同时一定要弱化用户期望系统怎么做，因为用户并不熟悉系统实现和内部原理，我们的软件需求不仅仅考虑的是功能的实现，还需要考虑需求复用，业务抽象，可扩展和配置等多方面的问题。收集回来的需求就需要开始进行分析工作，分析包括了动态行为分析和静态数据分析。动态行为分析涉及到用例分析，业务流程和活动输入输出的分析，数据流分析，业务操作规则分析。静态数据分析设计到业务对象建模，数据字典，组织结构，权限等分析。在这一个阶段的重点就是需求的系统化和结构化，最好要体现到规范的文档中。在软件开发过程中我们最强调的需要文档化的输出就是需求文档和总体设计方案文档。需求分析阶段还有一个重点的产出就是原型和DEMO，为了更好的和用户沟通并挖掘需求，我们需要将我们理解后的想法更加形象的讲述给用户，所以原型就显得额外重要。不管是否是抛弃的原型，都需要客户看到的原型和最终实现的系统基本一致，因此原型开发需要投入一定的时间，并根据客户反馈的信息不断修正。在原型中多投入些时间，就会多减少一份后期需求变更引起的返工时间。软件原型是降低需求变更风险的有效方法。4.需求的抽象和建模体现在哪些方面首先要理解需求分析和设计的目的在于满足现状并适应变化。要想适应变化则业务建模和需求抽象就是必须的。当我们了解到业务的组织结构和流程经常面临变动和调整的时候，我们就需要考虑引入标准的组织结构模型，权限模型和工作流模型。这些模型的引入使业务和需求的变动变化为通过系统的灵活配置来适应。软件系统要适应变化不是从设计阶段开始的，而是我们的软件需求本身就需要适应变化。需求的抽象包括了对业务对象模型的抽象，对业务规则的抽象，对流程的抽象。其中最重要的就是由业务对象抽象形成的概念模型，由流程抽象形成的数据交互模型。对于一些快速软件开发平台理解到的对象建模，流程建模，组织结构和权限建模，业务规则建模，BPEL业务流程编排恰好就是需求抽象的最主要内容。要做好需求抽象必须具备两方面的知识，第一是真正的对所涉及到的业务领域及其标准模型足够理解，其二是对软件系统分析和架构设计有较多的经验积累。只有同时具备这两方面知识才能够做好需求建模工作。5.需求的验证和确认包括哪些事情我们可以再简单理解下验证和确认的区别，对于判断最终开发出来的系统是否和用户想要的东西是一致的过程叫确认，对于你理解和描述的需求和我当初的想法是否是一致的过程叫验证。需求的验证包括了很多的内容，涉及到软件开发中上下游相关人员的参与。首先你结构和文档化后的需求需要用户来验证是否和他们的想法是一致的，是否把用户的真实意图描述清楚了，以保证需求本身的正确性。对于后续设计开发阶段的人员也需要对需求进行评审以保证需求的可实现性，确认需求描述是否清楚，是否是可以实现的，对于业务对象，流程和规则是否存在不可实现的模糊描述词语。对于测试人员，则主要是确认需求是否是可测试的，是否在需求描述中引入了较多的易用，较好，应该等不确定和不可测试的词语。对于大型的软件项目，如果有专门的产品化标准和UI组的话，还需要对需求的易用性和产品交互等方面进行评估，以评价整个软件系统的产品化。确认主要是软件系统已经开发完成后交付给用户后验收的时候，用户确认系统是否实现了当初的需求。为了保证确认过程的顺利，就必须重视需求验证的过程，需求验证不仅仅是需求阶段对需求文档的评审，还需要关注设计，开发等各阶段对需求的实现情况的验证。6.为什么要做需求管理，需求管理包括哪些工作?需求管理就是IT项目中的范围管理，需求管理是整个IT项目的源头，IT项目的估算，计划，后续的跟踪控制，验证和确认等各项工作都是跟需求密切相关的。因此为了保证项目的进度，质量和成本的目标的顺利实现，保证项目计划的严肃性和可执行性;为了保证软件系统最终开发的产品正是客户期望的产品，必须要做好需求管理工作。需求管理工作应该是需求全生命周期的管理，从用户原始需求的提出，到最终形成软件产品后用户对需求实现情况的验证以形成闭环流程。因此我们需要跟踪和了解到需求状态的演变过程。大型的项目软件生命周期模型较为复杂，一个需求的实现会经过用户需求，软件需求，总体设计，详细设计，开发和单元测试，集成测试，系统测试和验收测试多个环节，在这个过程中需要建立需求追踪以确认需求和中间阶段产生的工作产品的一致性。另外变更管理是需求管理的另外一个重点，需求在经过评审确认后需要基线并受到控制，当出现需求变更的时候必须进行相应的需求影响分析以确认对需求变更的处理方式，当变更工作量影响较大的时候还需要调整并重新基线项目计划。对于整个需求调研，分析和需求开发，评审确认的过程也需要进行管理。在这个过程中的一个重点就是对需求输出的文档需要得到用户，项目组设计开发人员的共同确认和承诺。7.需求变更管理重要性体现在哪里?有哪些具体的内容用户不断的提交需求修改，项目进度无任何保证不断延期;由于一次需求的修改导致原来本来稳定的系统出现各种原来没有想到的错误和异常;这些都是需求管理存在缺陷的表象。需求管理的重要性就体现到项目计划的严肃性和可执行性，以保证项目目标的实现。通过引入了需求变更管理后，使软件需求文档成为一份大家都共同承诺和作为依据参考的文档，这个文档需要在设计，开发，测试等多种角色之间充分传递和共享。另外通过需求管理工作，使每个人意识到变更对项目的影响和变更的代价，反向去促进需求开发质量的提高。需求变更管理包括了变更请求的提出，CBB委员会对需求进行影响分析确认是否变更，设计开发负责人确认需求变更将影响到的模块和代码和具体修改方法，开发人员对变更进行修改和测试，最后再有变更请求人对需求变更满足情况进行验证。对于变更的影响分析一般需要项目组的开发负责人进行，大型项目可以依靠需求管理中建立的需求追踪进行分析，但根据实践需求追踪在影响分析中的作用还不明显。8.需求是否必须要文档化，其意义体现在哪里?SRS需求文档是整个软件开发过程中最重要的一份文档，无论项目的大小个人的意见是关于需求文档都需要考虑规范化和文档化。这份文档是用户，项目经理，需求，设计开发，测试人员多方沟通的基础，使大家对需求有一致的理解并依据该文档开展各项工作。即时是对于敏捷软件开发，我们也需要对用例场景描述，CRC卡片等文档化下来以方便沟通。再次强调沟通，特别是面对面的沟通是信息传递最高效方式，但是当一个信息是需要在软件开发整个生命周期的不同阶段，由不同角色人员多次使用的时候，就必须文档化。而需求文档恰好属于这种类型。9.中小型软件开发团队需求开发和管理工作的重点在哪里?对于中小型的项目团队一定要使用轻量级的方法论和过程，过程是为了实现目标服务的，过程的目的是为了解决现在的问题和可能的问题。不在这个范围内做的过程，规则或工作都不会产生价值和意义。对于中小型团队首先是要意识到需求工作的重要性，制定需求文档和DEMO界面规范，对需求进行文档化和结构化。其次是对开发完成的需求需要得到用户，实现人员，测试等多方的评审和认可。最后是需求文档化后该工件需要通过各种配置管理工具进行管理，需求完成后及时归档和受控，需求的变更需要受到管理而不是随意的。10.需求优先级的作用，如何评估需求优先级?需求优先级的作用在于项目管理和用户满意度提升的需要。一个系统上线后经常出现情况就是往往经常使用的功能都集中在20%的功能上很多功能使用很少。需求优先级让我们更好的把握重点和分配资源，真正的把20%最重要的需求，经常使用的需求做好做精，只有这样才能够真正的提高用户满意度和达到项目目标。需求优先级对于用户往往最有发言权，但当一个系统涉及到多个业务部门和组织结构的时候，难免出现各个用户都站在自己的立场来看待需求的优先级和紧急程度的问题。但是一个需求究竟对效率提升，成本的减少，相关周期的缩短起到了多大的贡献和作用却没有衡量。因此对需求优先级的评估应该考虑引入价值工程的概念，一个需求的优先程度应该体现在需求实现后能够产生的价值和节约的成本。