如何系统分析用户需求？
需求的定义包括从用户的角度(系统的外部行为)和从开发人员的角度(一些内部特征)解释需求。
关键问题是编写需求文档。我曾经目睹过所有的开发人员在一个项目中被更换，客户被迫和新的需求分析师坐在一起。系统分析师说:“我们想和你谈谈你的需求。”客户的第一反应是“我已经把我的要求都告诉你前任了，现在我要的就是给我编一个系统。”。
自称无所不知的人
其实UGGs，需求是没有文档化的，所以新分析师得从头开始。所以如果只有一堆邮件、会议记录或者一些零碎的对话，你就确定你已经了解了用户的需求，这完全是自欺欺人。
需求的另一个定义是需求是“用户需要并能触发程序或系统开发的描述”。一些需求分析专家对这个概念进行了扩展:“一个系统满足用户的特性、功能和属性可以从系统外部找到”。这些定义强调产品是什么样的，而不是产品是如何设计和构造的。以下定义进一步从用户需求转移到系统特性:
需求是指明必须实现什么的规范。它描述了系统的行为、特征或属性，是开发过程中对系统的约束。
从这些不同的定义中，我们不难发现，并没有一个明确的、模棱两可的术语“需求”。真正的“需求”其实是存在于人的头脑中的。这个人主要是指客户，但一般情况下，用户无法描述自己的需求，只需要系统分析师根据自己的语言描述整理出相关需求，然后与客户核对。系统分析师和客户需要确保所有的项目涉众都用那些术语来描述需求。
任何文档化的需求(比如下面描述的需求规范)都只是一个模型和描述。
2.需求分析的任务
开发一个软件系统最困难的部分是准确地解释要开发什么。最困难的概念性工作是写出详细的技术要求，包括用户、机器和其他软件系统的所有接口。同时，这也是一旦做错最终会给系统带来巨大损害的部分，后期修改难度极大。
目前国内产品很多，一个企业可能有几个系统并行运行。它们之间的接口是系统开发人员最头疼的。
对于商业最终用户应用程序来说，企业信息系统和软件显然是作为一个大系统的一部分的产品。但是对于我们开发人员来说，我们并没有写出客户认可的需求文档。我们怎么知道项目什么时候结束？如果我们不知道什么对我们的客户是重要的，我们如何满足他们？
然而，即使是非商业目的的软件需求也是必要的。例如，库、组件和工具由开发团队内部使用。当然，在没有文档的情况下，您可能偶尔会同意其他人的观点，但更常见的是重复返工的不可避免的后果，重新编程代码的成本远远超过重写一个需求文档的成本。这些血淋淋的教训正发生在国内软件开发者身上。
最近，我遇到了一个开发团队，他们开发了一套供内部使用的计算机辅助软件，其中包括一个代码编辑器。遗憾的是，当他们开发完这个工具后，发现这个工具无法打印源代码文件，用户当然想要这个功能。结果，团队不得不手动复制源代码文档进行代码检查。这说明，即使需求是清晰准确的，如果我们不写文档，软件也只能怪自己没有达到预期的目标。
相反，我看到一个简单的界面被集成到“错误跟踪系统”写一页的要求。然而，操作系统管理员发现一个简单的需求列表在处理脚本时非常有用。当他们根据需求对系统进行测试时，系统不仅清晰地实现了所有必要的功能，而且没有发现任何错误。
事实上，需求文档在开发过程中一直起着指导作用。
3.需求分析过程
将软件需求工程的整个研究领域分为需求开发和需求管理更为合适，如图4-1所示:
图4-1需求工程领域的层次分解图
需求开发可以进一步分为四个阶段:问题获取、分析、规格编写和验证。这些子项包括软件产品中的需求收集、评估和文档编写等所有活动。需求开发活动包括以下几个方面:
确定产品的预期用户类别。
获取每个用户类的需求。
理解实际的用户任务和目标，以及这些任务所支持的业务需求。
分析来自用户的信息，以区分用户任务需求、功能需求、业务规则、质量属性、建议的解决方案和附加信息。
系统级需求被分成几个子系统，部分需求被分配给软件组件。
理解相关质量属性的重要性。
讨论实施优先级的划分。
将收集到的用户需求编译成文档和模型。
评审需求说明书，确保用户的需求以同样的方式被理解和认可，在整个开发团队接受说明书之前，把所有的问题都搞清楚。
需求管理需要“在软件工程中建立和维护与客户的合同”。这样的契约包含在需求文档和模型中。客户接受只是需求成功的一半，开发人员必须能够接受需求，并真正将需求应用到产品中。通常的需求管理活动包括:
定义需求基线(快速制定需求文档的主体)。
审查提议的需求变更，并评估每个变更的可能影响，以决定是否实施它。
以可控的方式将需求变更纳入项目。
根据需求调整当前项目计划。
估计需求变化的影响，并在此基础上协商新的承诺，这些承诺体现在项目解决方案中。
让每个需求与其对应的设计、源代码、测试用例关联起来，实现跟踪。
在整个项目中跟踪需求的状态及其变化。
以上解释是我总结了项目成功实施后系统分析师的经验，也是根据国内外其他系统实施的成功经验总结出来的。
4.需求类型
以下定义是需求工程中常用术语的定义。
软件需求包括三个不同的层次:业务需求、用户需求和功能需求(包括非功能需求)。
1.业务需求反映了组织或客户对系统和产品的高级目标需求，这些需求在项目视图和范围文档中进行了描述。
2.用户需求文档描述了用户在使用产品时必须完成的任务，在用例文档或方案脚本描述中有解释。
3.功能需求定义了开发人员必须实现的软件功能，以便用户完成任务，从而满足业务需求。
软件需求规范(SRS)中描述的功能需求充分描述了软件系统应该具有的外部行为。软件需求规格在开发、测试、质量保证、项目管理和相关项目功能中起着重要作用。对于大型系统，软件功能需求可能只是系统需求的一个子集，因为其他需求可能属于子系统(或软件组件)。
作为功能需求的补充，软件需求的规格说明还应包括非功能需求，非功能需求描述了系统呈现给用户的行为和操作，包括产品必须遵守的标准、规范和契约。外部接口的具体细节；性能要求；设计或实现的约束和质量属性。所谓约束，是指开发者对软件产品的设计和构造的限制。质量属性从多个角度描述产品的特性，从而反映产品的功能。对于用户和开发者来说，从各个角度描述产品是极其重要的。
让我们以文字处理器为例来说明不同类型的需求。业务需求可能是:“用户可以有效地纠正文档中的拼写错误”，产品包装盒的封面可能表明这是一个符合业务需求的拼写检查器。相应的用户需求可以是“找出文档中的拼写错误，并通过所提供的备选列表来选择替换拼写错误的单词”。同时，拼写检查器也有许多功能需求，例如查找并突出显示拼写错误的单词。显示一个对话框，提供替换词，实现整个文档范围的替换。
从上面的定义可以发现，需求不包括设计细节、实现细节、项目规划信息或测试信息。需求与这些无关，重点在于充分说明你真正想开发的东西。项目还有其他需求，比如开发环境或者发布产品并移植到支持环境的需求。尽管这些需求对于项目的成功也是至关重要的，但它们并不在本书中讨论。
5.需求分析的原则
不关注需求过程的项目团队将承受后果。需求工程中的缺陷会给项目的成功带来很大的风险。这里的“成功”是指推出的产品能及时以合理的价格在功能和质量上完全满足用户的期望。下面将讨论一些需求风险。
需求流程不当导致的一些风险:
1.没有足够的用户参与。
客户往往不理解为什么要花这么大的力气去收集需求，保证需求的质量，开发人员可能也不重视用户的参与。原因如下:第一，开发者觉得和用户一起工作不如写代码有趣；二是因为开发者觉得自己已经了解了用户的需求。在某些情况下，很难直接接触到实际使用产品的用户，客户也不太了解他们的真实需求。但代表用户要在项目前期直接参与开发团队，共同体验整个开发过程。
在实践过程中，系统人员也有一些感受，如果一个公司项目的实施没有足够多的用户参与，系统人员得到的需求是片面的、不完整的，这样系统会在需求之初就埋下风险。
2.用户日益增长的需求
如果在开发过程中不断补充需求，项目将会变得越来越大，超出其计划和预算的范围。计划并不总是与项目需求的规模和复杂程度、风险、开发生产率以及需求变化的实际情况相一致，这使得问题更难解决。其实问题的根源在于用户需求的变化和开发者对新需求的修改。
为了最小化需求变更的范围，项目视图、范围、目标、约束和成功标准必须在开始时被清楚地解释，并且这个描述应该被用作评估需求变更和新特性的参考框架。描述包括分析每项变更的影响因素的变更控制过程，有助于所有利益相关者理解业务决策的合理性，即为什么要进行一些变更，以及在时间、资源或特性上相应的权衡。
产品开发的不断变化会使其整体结构日益混乱，补丁代码会使整个程序难以理解和维护。插入补丁代码会使模块违背强内聚、松耦合的设计原则，特别是在项目配置管理不完善的情况下，会带来撤销变更、删除特性的问题。如果你尽早分辨出这些可能带来变化的特征，你就可以开发出更健壮的结构，更好地适应它。这样，设计阶段的需求变化就不会直接导致补丁代码，同时，
3.模糊的需求
模糊性是需求规格说明中最可怕的问题。它的第一个意义是指许多读者对需求规格说明有不同的理解；另一个意思是一个读者可以用多种方式解释一个需求陈述。
模糊的需求会让不同的涉众有不同的期望，会让开发人员在错误的问题上浪费时间，会让测试人员与开发人员的期望不一致。一位系统测试人员曾经告诉我，她的测试小组经常误解需求，以至于不得不重写许多测试用例，再次进行许多测试。
处理模糊需求的一种方法是组织团队，负责从不同的角度审查需求。简单的浏览需求文档并不能解决歧义问题。如果不同的评审人员从不同的角度对需求进行解释，但是每个评审人员都真正理解了需求文档，那么这种歧义要到项目的后期才会被发现，并且要花费很大的代价才能纠正。
4.不必要的功能
“画蛇添足”是指开发人员试图添加一些“被用户欣赏”但不在需求说明书中涉及的新功能。经常会出现用户觉得这些功能不是很有用，所以花在上面的努力就“白费”了。开发者要为客户构思解决方案，为他们提供一些创新的思路，具体提供哪些功能要在允许的时限内，在客户需要的和开发者的技术可行性之间平衡。开发者应该努力使功能简单易用。
同样，客户有时可能会要求一些看起来“很酷”但缺乏实用价值的功能，而这些功能的实现只能是耗费时间和成本。为了最大限度地减少“画蛇添足”的危害，你应该确定你明白为什么要包含这些功能，以及这些功能的“来龙去脉”，这样需求分析过程就始终专注于那些使用户能够完成业务任务的核心功能。
5.过于简洁的规格
有时候客户不理解需求分析的重要性，只做一个简要的规格说明，只涉及产品的概念性内容，然后让开发人员在项目的进展中完善。结果很可能是开发人员首先建立产品的结构，然后完成需求描述。这种方法可能适用于前沿的研究产品或者需求本身非常灵活。但在大多数情况下，它会给开发者带来挫折(使他们处于不正确的假设和极其有限的状态下)
6.忽略用户分类
大多数产品的使用人群不同，使用特点也不同，使用频率也不同，用户的受教育程度和经验水平也不同。如果在项目前期不能将这些主要用户全部分类，部分用户会对产品失望。比如菜单驱动的操作对于高级用户来说效率太低，但是模糊的命令和快捷键会让不熟练的用户很难操作。
7.不准确的规划
据统计，在需求过程中导致软件成本估算不准确的原因主要有五个:需求变更频繁、需求缺失、与用户沟通不够、需求规格说明书质量不高、需求分析不完善。
对于需求不准确的问题，正确的回答是“等我真正理解了你的需求，我再告诉你”。基于信息不充分和考虑不周的不成熟的需求估计很容易受到一些因素的影响。做估算的时候，最好给出一个范围。毫无准备的估计通常是作为猜测给出的，但听者认为这是一个承诺。所以要尽量给出可实现的目标，并坚持下去。
6.需求分析师和用户之间的合作
优秀的软件产品基于优秀的需求，高质量的需求来自于客户和开发人员的有效沟通和合作。通常情况下，开发商和客户或者客户代理，比如营销人员之间的关系，会变成一种对立的关系。双方管理者只想要自己的利益，搁置用户提供的要求，就会产生摩擦。在这种情况下，不会给双方带来任何好处。
只有当双方参与者都明白他们需要什么才能成功，同时他们也应该知道合作伙伴需要什么才能成功时，合作关系才能建立起来。由于项目的压力越来越大，很容易忘记所有的利益相关者都有相同的目标。其实每个人都想开发一个优秀的软件产品，能够实现商业价值，满足用户需求，让开发者满意。
软件客户需求声明列出了客户在项目需求项目实施过程中与分析师和开发人员沟通的十项法律要求。每一项权利都对应着软件开发人员和分析师的义务。软件客户需求声明还列出了客户在需求过程中应承担的十项义务。如果你愿意，可以作为开发者的权利声明。
客户拥有以下权利:
1:要求分析师使用符合客户语言习惯的表达方式。
需求讨论要围绕业务需求和任务，所以要用业务术语，你要教给分析师，不一定要懂计算机行业术语。
2.要求分析师了解客户的业务和目标。
分析师通过与用户沟通获取用户需求，可以更好地理解你的业务任务，以及如何让产品更好地满足你的需求。这将有助于开发者设计出真正满足你需求、符合你期望的优秀软件。为了帮助开发人员和分析师，您可以考虑邀请他们来观察您或您的同事是如何工作的。如果使用新的开发系统来替换现有系统，开发人员应该使用当前系统，这将有助于他们了解当前系统的工作原理。
3.要求分析师编写软件需求说明书。
分析师应该整理从你和其他客户那里获得的所有信息。区分业务需求和规范、功能需求、质量目标、解决方案等信息。通过这些分析，可以获得软件需求规格。这种软件需求规格说明书可以使开发者和客户就要开发的产品内容达成一致。软件需求规格可以用你认为容易阅读和理解的方式来组织和编写。查看准备好的规范，确保它们准确、完整地表达了您的需求。一个高质量的软件需求规格可以帮助开发。
4.要求对所需工作的结果进行解释。
分析师可能会使用各种图表作为文本软件需求规范的补充。因为诸如工作流图之类的图表可以清楚地描述系统行为的某些方面，所以需求规范中的图表具有很大的价值。虽然它们并不太难理解，但你可能并不熟悉它们。因此，可以要求分析师解释每个图表的功能或其他需求开发结果和符号的意义，以及如何检查图表是否错误或不一致。
5.请开发者尊重你的意见。
如果用户和开发人员不能互相理解，需求的讨论就会有障碍，互相合作才能让大家“理解”。参与需求开发过程的客户有权要求开发人员尊重他们，珍惜他们为项目成功所付出的时间。同样，客户也应该对开发人员为项目成功所做的努力表示尊重和感谢。
6.请开发人员就需求和产品实现提供建议和想法。
通常，客户所说的“需求”是一个切实可行的实现方案。分析师会尽力从这些解决方案中了解真实的业务及其需求，同时还要找出现有系统的不恰当之处，以确保产品不会无效或低效。在彻底了解了业务领域的东西之后，分析师有时可以提出相当好的改进方法。有经验和创造力的分析师也可以提议增加一些用户没有发现的有价值的系统特性。
7.描述产品的易用特性。
你可以要求分析师在实现功能需求的同时，关注软件的易用性，因为这些易用的特性或质量属性可以使你更准确、更高效地完成任务。例如，客户有时要求产品“用户友好”或“健壮”或“高效”，但这对开发人员来说过于主观，没有实用价值。正确的是，分析师通过询问和调查了解客户想要什么友好、健壮和高效。
8.调整需求并允许重用现有的软件组件。
需求通常是灵活的。分析师可能会发现现有的软件组件与您描述的需求非常一致。在这种情况下，分析师应该提供一些修改需求的选项，以便开发人员可以在新系统的开发中重用一些现有的软件。如果有重用的机会，并且可以同时调整自己的需求，那么就降低了成本，节省了时间，不需要严格按照原来的需求。所以，如果你想在你的产品中使用一些现有的商业组件，而它们并不完全适合你所需要的特性，那么一定程度的需求灵活性是极其重要的。
9.获得满足客户功能和质量要求的系统。
每个人都希望这个项目成功。但这不仅需要你清楚地告诉开发人员系统“做什么”的所有信息，还需要开发人员通过沟通清楚地了解其中的权衡和限制。你必须清楚地陈述你的假设和潜在的期望。否则，开发人员开发的产品可能不会让您满意。
客户有以下义务:
1:向分析师解释你的业务。
分析师依赖于你向他们解释的商业概念和术语。但是你不能指望分析师成为这方面的专家，你只能让他们真正了解你的问题和目标。不要指望分析师能抓住你业务的微妙之处和潜力。他们很可能不知道你和你的同事认为理所当然的“常识”。
2.花时间清楚地解释和改进需求。
客户很忙，经常要在最忙的时候参与需求开发。但是，你有义务抽出时间参加头脑风暴会议、面试或其他活动来获取需求。有时候分析师可能会认为他们先理解了你的观点，后来发现他们需要你的解释。这时候，请耐心等待需求的重复和需求的细化，因为这是人与人交流中的自然现象，对软件产品的成功极其重要。
3.准确详细地解释需求
写一份清晰准确的需求文档是非常困难的。因为处理细节不仅烦人而且费时，很容易留下模糊的要求。但是，在开发过程中，必须解决这种模糊性和不准确性。而你是做决定解决这些问题的最佳人选。否则，你只能依靠开发者的猜测了。在需求说明书中临时添加一个待定的标志是个好主意，TBD也可以用汉语拼音缩写为“DQD:待定”)。它可以指出哪些内容需要进一步讨论、分析或补充信息。然而，有时，一个特殊的需求可能会被标上TBD，因为它很难解决或者没有人愿意处理它。尽可能清晰地解释每个需求的内容，以便分析师准确地将其写入软件需求的规格说明书。如果一时无法准确表达，那就要允许获得必要准确信息的过程。通常使用所谓的原型技术。通过开发出来的原型，你可以和开发人员反复修改，不断完善需求的定义。
4.及时做出决策
就像建筑师为你盖房子一样，分析师会要求你做一些选择和决定。这些决策包括处理多个用户提出的方法，或者在质量特性冲突和信息准确性之间选择一个折衷方案。有决策权的客户一定要对这一切持积极态度，尽快做出决定，因为开发商通常要等你做出决定才能行动，这种等待会耽误项目进度。
5.尊重开发商的需求、可行性和成本评估
所有的软件功能都有其成本价，开发者最适合预算这些成本(虽然很多开发者不擅长评估和预测)。有些你想要的产品功能可能技术上不可行，或者实现起来会极其昂贵。有些需求试图要求操作环境中不可能的性能或者试图得到一些根本得不到的数据，开发人员会对其做出负面评价。你应该尊重他们的意见。有时候，你可以给出一个技术上可行、实施成本低廉的需求。比如，要求某个行为“瞬间”发生是不可行的，但可以通过改成更具体的时间需求表述来实现(“50ms以内”，但没有准确的技术分析你不能轻易下结论)。
6.区分需求的优先级
大多数项目没有足够的时间或资源来实现功能的每个细节。决定哪些特性是必要的，哪些是重要的，哪些是好的是需求开发的主要部分。你只能负责设置需求优先级，因为开发人员不能根据你的观点来决定需求优先级。开发人员将为您提供关于每个需求的成本和风险的信息。当你设置优先级时，你帮助开发者在适当的时间内以最小的花费确保最好的结果。在时间和资源的限制下，是否能完成所需的功能或完成多少，应该尊重开发人员的意见。虽然没有人愿意看到自己想要的需求在项目中没有实现，但毕竟不得不面对这个现实。商业决策有时不得不缩小项目范围或延长建设周期，增加资源，或根据优先级在质量上找到一个折中方案。
7:评审需求文档和原型
正如我们将在1 4章中讨论的，无论是正式的还是非正式的，评审需求文档都将有助于提高软件质量。只有让客户参与评审，才能真正识别需求文档是否完整，并正确解释预期的必要特征。审查还为客户代表提供了一个机会，将反馈信息带给需求分析师，以改进他们的工作。如果你认为写的需求文档不够准确，你有义务尽快告诉分析师，并给出改进建议。通过阅读需求说明书很难想象实际的软件是什么样子的。更好的方法是先为产品开发一个原型，这样你可以为开发者提供更有价值的反馈信息，帮助他们更好地理解你的需求。必须认识到，原型并不是一个实际的产品，但开发人员可以将其转换和扩展为一个完整的系统。
8.如果需求发生变化，请立即联系。
不断的需求变化会给预定计划内高质量产品的完成带来严重的负面影响。变化是不可避免的，但是变化在开发周期中出现的越晚，其影响就越大。变更不仅会导致成本高昂的返工，还会迫使工期延迟，尤其是在一般结构完成后需要添加新功能时。所以一旦你发现有必要改变需求，请立即通知分析师。
9.应该遵循开发组织处理需求变更的过程。
为了将变更的负面影响降至最低，所有参与者都必须遵循项目的变更控制流程。这就需要不放弃所有提出的变更，对每一个需要的变更进行分析和综合考虑，最后做出适当的决策，以确保将一些变更引入到项目中。
10:尊重开发人员采用的需求工程过程。
软件开发中最具挑战性的事情是收集需求并确定它们的正确性。分析师采用的方法是合理的。你可能觉得需求过程不划算，但是请相信花在需求开发上的时间是“有价值”的。如果你理解并支持分析师收集和编译需求文档所使用的技术，并保证它们的质量，整个过程会更顺利。只需要问分析师为什么他们想要收集一些信息或者参与需求相关的活动。
系统分析师在开发过程中可能会遇到以下问题。一些忙碌的客户可能不愿意积极参与需求过程，缺乏客户的参与很可能会导致产品不尽人意。因此，有必要确保需求开发的所有主要参与者理解并接受他们的义务。如果出现分歧，可以通过协商达成对各自义务的相互理解，这样可以减少以后的摩擦。
7.需求文档
需求开发的最终结果是客户和开发团队就要开发的产品达成一致。该协议集成了业务需求、用户需求和软件功能需求。正如我们前面看到的，项目视图和范围文档包含业务需求，而用例文档包含用户需求。你必须从产品的用例和非功能需求文档中编写功能需求文档。包括质量属性和外部接口要求。只有当这些文档以结构化和可读的方式编写，并且被项目的涉众审查和批准时，各行各业的人才能确信他们认同的需求是可靠的。
您可以使用以下三种方法来编写软件需求规格说明:
用良好的结构和自然语言编写文本文档。
建立图形模型，可以描述转换过程、系统状态及其变化、数据关系、逻辑流或对象类及其关系。
编写形式规格说明，可以使用数学上精确的形式逻辑语言定义需求。
由于形式规范的严格性和准确性，只有少数软件开发人员熟悉所使用的形式语言，更不用说客户了。虽然结构化自然语言有很多缺点，但在大多数软件项目中，它仍然是编写需求文档最现实的方法。基于文本的软件需求规格说明，包括功能性和非功能性需求，已经被大多数项目所接受。图形分析模型通过提供另一个需求视图增强了软件需求规格。
如果你的问题解决了，请采纳！
如果没有解决，请继续提问。