在需求开发阶段发现的一个错误平均只需要30分钟就可以修复，如果在系统测试中发现，需要5到17个小时才能修复。在产品投入使用后发现的一个需求缺陷，要比在需求阶段纠正这个错误的成本高100倍左右。因此，需求管理作为软件项目管理的重要组成部分，贯穿于项目实施的整个生命周期。俗话说，万事开头难。作为软件开发的第一步，其重要性不言而喻。市场上有很多需求管理的相关理论和书籍，但大多停留在理论层面，实用性不强。
1。与用户充分沟通
通常与用户沟通前的准备时间要比正式见面时间长很多。一般来说，用户跟你聊两个小时就会失去热情和耐心，这是大多数人的共同特点。因此，充分的准备是必不可少的。准备工作包括熟悉项目整体环境的准备工作和具体业务调查前的准备工作。对项目整体环境的熟悉需要了解项目的背景、目的、利益相关者，从而对当前项目的整体情况有一定的了解。具体业务调研的准备工作包括:需求调研问题的准备，需求调研模板的设计，需求调研的日程安排。要充分重视用户的时间，尽量避免因准备不充分而与用户重复预约，给用户留下效率低下的印象。一旦出现这样的错误，以后可能很难和用户见面。需求获取的核心内容是通过调查掌握软件项目的实际需求，从而指导整个项目的实施。需求获取的主要方法有:用户访谈、问卷调查、现场观察、头脑风暴等。在实际的项目操作过程中，可以采用相对固定的需求获取方式，如:问卷调查等。，对于相对明确的需求。当需求比较模糊或者用户无法明确表达自己需要什么的时候，我们可以采用更灵活的方式，比如用户访谈、现场观察等。需求的类型主要包括:业务需求、用户需求和功能需求。在需求获取的过程中，无论采用哪种方法，都需要自上而下或者自下而上的了解用户的真实想法。业务需求主要从客户的高层领导那里获取。众所周知，项目的发起、实施和最终成败很大程度上取决于高层领导。我们需要采访他们，以了解高层领导的公司战略和发展方向，更重要的是，了解他们对将要开发的软件系统的期望，以及他们对系统在解决现有业务问题和支持公司整体战略方面的期望。帮助我们更好地理解系统的宏观概念。在掌握了业务需求之后，我们需要对中层管理人员进行调查。核心问题是在宏观战略目标实施的层面，或者说指标细化落实的中观层面，找出他们对软件系统的期望和实际需求。他们要么希望这个系统能给自己的工作带来便利，要么希望这个系统能实现精细化管理，等等。但他们都是具体业务部门的负责人，对自己的业务以及系统对业务的推动有着深刻的理解。最后，我们需要在掌握业务需求和用户需求的基础上，通过调查IT管理部门和关键运营商的需求或根据我们对需求的理解，细化系统的功能需求。这个要求是最底层的要求，也是一个层层落地的过程。
2。积极了解客户业务及相关知识
我们在技术上可能很专业，但具体的用户业务可能不是很清楚。这个项目对用户是否有帮助，某个系统功能是否有用，某个流程是否合理，在不了解用户业务的情况下，我们将很难做出判断。所以，只有在了解业务的基础上，才能和用户有共同的沟通语言和业务理解，才能真正理解系统应该具备什么功能。在经销商管理系统调研过程中，由于财务知识有限，对经销商财务部门调研中的一些问题没有特别的了解。虚心向用户请教，调查后及时补充自己的金融知识。应用领域的知识是无限的。在各种项目的调研过程中，需求分析人员对某一领域知识的缺乏肯定会影响需求分析的准确性和顺利进行。遇到这类问题，需求分析师要虚心向用户求教，同时要及时补充应用领域的知识。最好在调研前做好充分的准备。
3。引导用户充分表达自己的想法
在与用户的交谈中，如何引导用户说出自己的需求是非常关键的。恰当的提问会让用户滔滔不绝，充分表达自己的意见和建议。不恰当的问题可能导致用户无法回答或给出敷衍的回答。提问可分为封闭式提问和开放式提问。封闭式问题的目的很明确。比如现在的送货单是手工填写还是电脑打印？然而，过度使用封闭式问题会导致无聊的对话，并让用户感觉好像在接受审问。开放式提问是要求对方进一步解释某件事，可以使谈话达到一定的深度和广度。比如你觉得现在的工作有哪些可以改进的地方？开放式提问的缺点是容易使谈话偏离主题。因此，在谈话过程中，应该采取封闭式和开放式提问相结合的方式。从简单的问题和用户熟悉的东西开始。一次只问一个问题，集中在一点上，多问少猜。并且尽量避免使用一些IT相关的术语，让用户能够很好的理解我们的表达。
4。正确分类用户
组织中的用户在许多方面都是不同的，如使用系统的频率和程度、计算机系统的知识、业务流程、个人素质和偏好等。用户可以根据他们的特征进行分类。对用户进行分类并总结其各自的特点，详细描述其性格特征和任务状态，将有助于获取和分析需求。不同的问题需要由不同的人来问。对于运营细节，要和实际负责运营的用户沟通，对于关系全局的问题，要和相应的管理用户沟通。
5。现场了解用户的工作流程
观察用户在现场执行业务任务的过程。知道用户什么时候获取什么数据，如何使用，业务处理时需要处理哪些单据，用户需要关联哪些角色。这将有助于定义产品的功能需求。经验证明，采访人如何完成任务有很多局限和不准确的地方，可以通过任务观察法直接解决。尤其是对于一些组织中普遍接受的规则和方法，用户认为你理所当然应该知道，却从来不提。用户的需求确定后，将用户的需求逐项列出，每个需求形成一个需求开发任务。借助软件项目管理平台，直接推送给需求分析师，需求分析师的分析结果可以通过平台导出成格式化的需求规格说明书。一旦需求说明书编写任务完成，管理平台直接将需求评审任务推送给相关人员。后续的设计、编码、测试和其他任务以类似的方式集成到流程中。
6。分析需求的可行性
我们不做不挣钱的事；不要做挣钱却买不起的事情；如果你有钱，你买得起，但是没有可靠的人选，你不会做这样的事。可行性分析主要是根据某种需求来决定做与不做。一般可行性主要考虑两个因素:技术和人。技术方面主要是分析在给定的时间内能否实现所需的功能，满足产品的质量要求和其他相关指标。很多时候，用户的想法在实际执行过程中是不切实际的。一味的追求完美，一味的跟随用户的假设，会给项目的后续工作带来很大的风险。所以在需求分析中要尽量避免包含难以实现的功能。在我负责的一个项目中，用户要求新的管理系统实现和管理系统的数据接口，以方便这些系统中的数据通向新的管理系统。承诺提供系统的数据接口会给新系统的成功实施带来很大的风险。因为熟悉这些系统需要时间，开发与之接口也需要时间，而且这些商业系统有很多不同的版本。因此，与外部系统接口的可行性被定义为不可行。对于复杂的项目，还应该考虑经济和环境方面。经济主要从投入、收益、短期和长期利益等方面进行分析。环境主要考虑市场环境和政策因素。需求的变更对大型IT开发项目的成败有着重要的影响。我们不能拒绝客户所有的变更要求，也不能一味迁就客户。因此，在实施需求变更之前，必须做好控制工作。变更控制的目的不是控制变更的发生，而是管理变更，保证变更的有序进行。
7。确定需求的优先级
当客户期望很高，开发时间很短，资源有限时，设置需求的相对优先级将有助于项目经理解决冲突，安排分阶段交付，并进行必要的权衡。确定每个需求的重要性有助于规划软件的构建，并以最小的成本提***品的最大功能。特别是对于渐进式的项目，优先级的设置更为重要，因为在这些开发中，项目进度极其紧迫，交付日期无法更改，所以一些低优先级的需求需要推迟到后续版本或者直接取消。当多个用户在公共场合因期望不同而难以就某些需求优先级的设定达成一致时，需求分析师可以通过指出成本、难度、技术风险或其他与需求平衡相关的具体指标，客观地评估每个需求的优先级。
8。正确理解需求分析文档确认
需求分析是一项繁琐枯燥的工作，需要和用户一起讨论、确认、反复。但是大多数用户并不只是做这份工作，尤其是当他们陷入许多其他事情的时候。在需求分析文档上签字确认通常被认为是用户同意需求分析内容的标志。然而在实践中，签名确认工作并没有得到用户的足够重视。“他们让我签需求文档，我就签了，不然开发人员就不开始编码了。”用户的这种态度可能会给项目带来潜在的风险，比如不断变化的需求。对于需要用户确认的需求分析文档，最好在用户确认之前向用户说明文档的内容，以确保用户完全理解并认可文档中的内容。如果用户对文件中的内容有任何修改意见，修改后将与用户确认，直到用户完全认可文件中的内容。为了对项目有一个全面准确的了解，需求分析的内容通常要大于项目范围。
所以要让用户明白，有些功能的讨论并不代表很快就会在系统中实现。需要向用户明确的是，需求分析文档的签字确认是建立一个需求基线，通过项目定义的变更过程，可以在这个基线上进行进一步的变更。需求的确认将为双方的前期需求开发工作划上一个清晰的句号，并有助于在用户和需求分析师之间形成持续良好的关系，为项目的成功打下坚实的基础。将知识从一个地方转移到另一个地方并不是一件简单的事情，最初的需求通常是以不完整的形式呈现的。可能只是存在于一个现有系统的用户头脑中，有时候甚至用户自己都没有意识到自己知道什么。同时，需求分析工作者也要在日常工作中加强学习，不断总结，使自己的需求分析能力不断提高。软件需求管理之所以重要，是因为大部分项目的失败主要是由于对需求缺乏了解，对需求的变更缺乏有效的控制。因此，这就要求我们在获取、分析和变更软件项目的需求方面做出更大的努力，并结合项目管理的相关理论，如PMBOOK、CMMI等。，并在项目实践中不断总结经验教训做好需求管理工作。
本文来自枯萎○还行投稿，不代表舒华文档立场，如若转载，请注明出处：https://www.chinashuhua.cn/24/521593.html
微信扫一扫 
