跟我学软件系统需求工程——如何获得软件系统的用户需求
软件工程中的用户需求获取与分析
软件工程中的用户需求获取与分析软件工程中的用户需求获取与分析是软件开发的重要环节之一，它是指通过各种途径，了解用户对软件的需求，它对于软件的质量、可靠性和可维护性都有着至关重要的作用。
第一节：用户需求的获取获取用户需求是软件开发的第一步，如果不能正确的获取用户需求，那么剩下的开发工作也就没有必要。
在获取用户需求的过程中，需要使用到各种方法，其中最常见的方法有：1.用户访谈法用户访谈法是通过与用户面对面的交流，了解用户的需求，这个过程中，需要注意保持耐心和客观，避免过度引导用户。
2.调查法调查法是通过问卷调查的方式，收集用户对软件的需求，这种方法适用于大规模的用户需求获取。
3.案例分析法案例分析法是通过分析用户已有的软件需求或者软件应用过程中的问题，来获取用户的需求。
4.焦点小组法焦点小组法是通过组织一些用户（或者用户代表）进行讨论，从而得出用户对软件的需求。
5.用户练习法用户练习法是通过让用户在使用软件前尝试使用一些操作手册或者演示版，从而获取用户对软件功能的需求。
通过上面的几种方法，就可以获取到用户对软件的需求，但是，获取到用户需求，并不意味着这些需求就是最终的需求，我们还需要对用户的需求进行分析、筛选和整合。
第二节：用户需求的分析与整合用户需求的分析与整合是一种综合性的工作，需要对用户提供的需求进行系统的分析，然后整合成系统的需求。
在用户需求的分析过程中，需要考虑以下几点：1.需求的真实性在用户提供需求的过程中，可能会存在一些过度的描述或者夸大实际需求的情况，需要通过多次电话或者面对面交流的方式，了解其真实需求。
2.需求的优先级每一个用户提出的需求都有其优先级，需要根据需求的紧急程度和相对重要性确定需求的优先级，从而使得开发人员有条理的进行开发。
3.需求的明确性在用户提供需求的过程中，可能会存在一些术语、缩写等难以理解的东西，需要针对性的进行解释和澄清。
4.需求的可行性在用户提出的需求中，会存在一些技术实现上不可行或者成本过高的需求，需要通过技术分析和项目预算来确认需求的可行性。
如何进行软件工程中的用户需求收集(七)
如何进行软件工程中的用户需求收集引言软件工程中的用户需求收集是指从最终用户那里获取他们的需求和期望，以便为他们开发出满足其需求的软件产品。
用户需求收集对于软件工程的成功至关重要。
本文将探讨几种常见的用户需求收集方法，并分析其优缺点。
需求概述在进行用户需求收集之前，首先需要将需求进行概述。
这意味着要对软件产品的目标、功能、约束条件以及其他相关要求进行全面的了解。
概述需求的目的是为了给待采集需求的用户提供一个基本的框架，以便他们能够更好地表达自己的需求。
用户访谈用户访谈是最常用的需求收集方法之一。
通过面对面的交流，开发团队可以与用户互动，深入了解他们的需求和期望。
在访谈过程中，可以利用开放式问题和封闭式问题向用户提问，以确保全面而准确地收集到用户的需求。
用户调查用户调查是另一种有效的需求收集方法。
通过向用户发放问卷或在线调查表，开发团队可以更广泛地了解用户的需求。
用户调查可以帮助开发团队收集到大量的用户意见和反馈，但也需要注意调查设计的科学性和问题的准确性。
原型设计原型设计是一种通过创建界面或交互模型来展示软件功能的方法。
通过与用户交互，开发团队可以进一步了解用户的需求，并及时调整和改进原型设计。
原型设计可以帮助用户更好地理解软件产品的功能，从而提供更准确的需求。
用户故事（User Stories）用户故事是一种简洁而有效的需求收集方法。
通过用简短的语句来描述用户的需求和期望，开发团队可以更好地理解用户的想法。
用户故事通常包含一个角色、一个目标和一些具体需求。
它们可以帮助开发团队更好地解释和追踪用户需求。
原始资料分析原始资料分析是一种从现有资料中收集用户需求的方法。
开发团队可以通过研究用户的报告、文档、邮件等资料，获取用户关于软件产品需求的信息。
这种方法适用于已经存在相关资料的项目，可以节省需求收集的成本和时间。
用户沟通与用户的沟通是一种持续的需求收集方法。
在软件开发过程中，开发团队应该与用户保持联系，及时了解他们的需求和反馈。
软件需求工程实训课程学习总结需求获取与需求分析方法比较
软件需求工程实训课程学习总结需求获取与需求分析方法比较软件需求工程是软件开发过程中至关重要的一环，其目的是确保软件系统最终能够满足用户的需求。
在软件需求工程实训课程中，我学习了不同的需求获取和需求分析方法。
本文将对这些方法进行比较，以总结出对于不同情况下最适合的方法。
需求获取是软件需求工程的起点，它是通过与用户沟通和交流，了解用户需求的过程。
在实训课程中，我学习到了几种常用的需求获取方法：面谈、问卷调查和观察。
面谈是一种直接与用户进行交流的方法，通过与用户面对面的交流，可以深入了解用户需求背后的真正问题和期望。
通过面谈，我可以主动提问，用户也可以自由表达自己的观点。
在实践中，我发现面谈能够有效避免信息的误解，提供更加准确和详细的需求描述。
问卷调查则是一种匿名的需求获取方式，通过向用户发送问卷，可以收集到大量的用户意见和建议。
问卷调查相对而言更加快捷和方便，可以向更多的用户收集数据。
然而，问卷调查可能会出现信息不准确的问题，因为用户可能无法完全理解问题的含义，或者没有精力和时间来填写问卷。
观察是一种通过观察用户在实际环境中使用软件的方法，来获取用户需求的方法。
观察可以帮助我们了解用户在具体场景下的行为和需求，从而更好地设计软件。
但是，观察的过程相对较长，需要时间和资源投入，而且我们无法观察到用户在未来可能出现的情况。
需求分析是在需求获取的基础上，对收集到的需求进行整理、分析和抽象，以便进行后续的开发和设计。
在实训课程中，我学习了几种常用的需求分析方法：数据流图、用例图和决策表。
数据流图是一种图形化的工具，用于表示系统内部的数据流动和处理过程。
通过数据流图，我们可以清晰地了解系统的功能和数据流动方式，从而更好地识别出系统的需求和问题。
数据流图由于其简洁明了的特点，在实际中使用较为广泛。
用例图是一种通过描述系统与用户之间的交互来分析需求的方法。
用例图通过描述系统的各种情景，可以帮助我们更好地理解用户需求和系统功能。
软件工程中的需求工程方法与实践技巧
软件工程中的需求工程方法与实践技巧需求工程是软件开发过程中至关重要的一环，它确定了软件系统需要满足的功能和性能要求。
在软件工程中，需求工程师负责收集、分析和定义用户需求，为开发团队提供清晰、具体的指导。
本文将介绍一些常用的需求工程方法和实践技巧，以帮助开发团队更好地理解和应对需求工程的挑战。
1. 需求收集需求收集是需求工程的第一步，它的目的是获取用户的需求和期望。
需求工程师可以通过以下几种方式进行需求收集：- 面对面交流：与用户进行面对面的会议和访谈，了解他们的需求和期望。
这种交流方式可以更好地把握用户的真实需求，并及时解答用户的疑问。
- 文档分析：分析现有的需求文档、项目计划和用户手册等，了解系统已有的需求和规范。
- 调查问卷：设计调查问卷，广泛收集用户的需求，以获取更全面和客观的数据。
- 观察和模拟：观察用户的工作环境和方式，模拟他们的操作过程，以更好地理解他们的需求和使用习惯。
2. 需求分析与建模需求分析是将收集到的需求进行分析和整理的过程，它的目的是确定需求的优先级和相关的约束条件。
需求建模是需求分析的一种重要工具，它可以帮助将需求转化为易于理解和验证的形式。
- 用例图：用例图是一种常用的需求建模工具，它描述了系统和外部参与者之间的交互关系，帮助开发团队更好地理解系统的功能和用户的行为。
- 领域模型：领域模型是对系统所涉及的相关领域和实体进行建模的过程，以确定系统的边界和相关概念之间的关系。
- 数据流图：数据流图描述了系统中数据的流动和处理过程，帮助开发团队更好地理解系统的数据需求和处理逻辑。
3. 需求验证和确认需求验证和确认是确保需求的正确性和可行性的过程，它有助于避免开发过程中的返工和变更。
- 需求审查：通过团队内部和用户参与的需求审查会议，确认需求的正确性和一致性。
- 原型演示：根据收集到的需求，开发简化的原型系统，与用户共同验证需求的实现效果。
- 用户验收测试：在软件开发结束后，邀请用户进行验收测试，并与其确认是否满足其需求和期望。
如何进行软件工程中的用户需求收集
软件工程中的用户需求收集是开发一个成功软件的基础，它涉及到了与用户的有效沟通以及对用户需求的理解和分析。
在软件开发过程中，收集到准确的用户需求对产品设计、开发以及测试都具有重要意义。
本文将探讨如何进行软件工程中的用户需求收集的方法和技巧。
一、了解用户需求的重要性用户需求是软件开发的驱动力，仅有深入了解用户需求，才能确保软件开发过程中不偏离用户的期望。
用户需求收集的目的是为了准确获取到用户的期望和目标，并将其转化为开发团队可以理解和实现的具体任务。
二、与用户建立有效的沟通渠道与用户建立有效的沟通渠道是用户需求收集的关键步骤。
传统的方式是通过面对面会议、电话沟通等方式获取用户需求，但面对面的交流成本较高且易疏忽细节，因此我们可以运用一些现代技术手段，如使用在线问卷、邮件调查、在线讨论论坛等方式来和用户进行交流。
这些方式能够提高效率、减少信息丢失的风险，并且为用户提供了一个方便的平台，随时随地分享和表达他们的需求。
三、正确使用需求收集技巧需求收集技巧是帮助开发团队更好地理解用户需求的重要工具。
以下是一些常用的需求收集技巧：1. 面对面访谈：选择关键用户，通过面对面的访谈方式，直接获取用户需求以及背后的需求高度。
在访谈中，开发人员应以开放性问题的形式询问用户，以便充分理解用户的真实需求。
2. 观察用户行为：观察用户在使用类似软件时的行为细节，通过观察用户的操作习惯、应用场景等来获取更准确的需求信息。
3. 原型设计：通过设计软件的原型，让用户快速了解软件的外观和功能，收集用户对原型设计的反馈，从而更好地理解他们的需求。
四、积极倾听用户反馈在软件的持续开发和改进过程中，积极倾听用户的反馈是非常重要的。
用户反馈是一个宝贵的资源，能够帮助开发团队更好地理解用户的真实需求，及时调整和改进产品。
为了促使用户提供真实反馈，我们可以采取以下措施：1. 创造一个安全、友好的反馈环境，让用户感到舒适和放心表达自己的意见和建议。
跟我学软件系统需求工程——如何获得软件系统的用户需求
1.1跟我学软件系统需求工程——如何获得软件系统的用户需求在本单元中希望重点了解和掌握什么是用户需求，需求的表达形式，如何获取用户需求，如何细分需求，同时在此阶段所应该形成的制品；另外也应该掌握如何采用用例图（Use Case）对用户的需求进行建模，以及Use Case方法最主要的优点。
1.1.1需求工程1、需求工程（1）需求工程结构图（2）需求开发和需求管理的流程其中，需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。
1.1.2如何获得用户需求1、什么是用户需求（1）关于用户需求1)它主要是说明系统所必须符合的条件或者应该具备的的功能，也即它用来描述系统应该和不应该做什么也即决定本系统应该有什么功能，从而开发者和用户可以创建一个初始化的商业联系。
2)重点在是应该做什么，而不是应该如何做。
3)需求最根本的挑战在于：寻找、交流并记录什么是真正需要的，并能够向用户和开发团队讲解。
（2）一个关于影响项目进展的因素的研究如下图（Jim Johnson 1994 Chaos:Charting the Seas of Information Technology. Published Report .The Standish Group）可见37%的问题都与需求有关，这就需要“需求开发”和“需求管理”。
（3）“需求管理”的两种方法●瀑布式在项目的第一阶段，在任何设计和实现工作之前，尽可能的推敲，把需求完全定义清楚，并把它稳定下来，并且实际开发前冻结需求，但历史证明这种方式是失败的，在项目很大的时候，冻结需求几乎没有可能。
●迭代式用一种条理化的方法来寻找、记录、组织和跟踪不断变化的需求。
这里的关键是“不断变化”这个词，把需求变化作为项目进展的不断驱动力，另一个重要的词是“寻找”，可以通过写出用例和召开需求研讨会等手段巧妙的得出需求。
整个问题都来自于，用户往往对自己的愿望并不清晰，需求会不断的变化。
软件项目获取用户需求的沟通技巧
软件项目获取用户需求的沟通技巧在软件开发过程中，获取用户需求是非常重要的一步。
软件的成功与否很大程度上取决于开发团队是否了解客户的真实需求。
因此，有效的沟通技巧是必不可少的。
本文将介绍一些软件项目获取用户需求的沟通技巧。
确定你的目标用户首先，一个成功的软件项目需要明确目标用户。
团队成员需要明确软件的预期目标，并向客户了解他们的需求和期望。
这意味着需要详细地了解用户以及他们使用软件的目的和特定场景。
在这个过程中，要问清楚谁会使用软件、使用场景是什么、需要功能有哪些，这样才能确保你的软件真正满足用户的需求。
听取用户的意见沟通是关键。
在与用户沟通的过程中，需要保持耐心和平静。
别忘了，你是要了解用户的需求，而不是把你自己和你的想法强加给他们。
在谈话中要仔细倾听用户的回答，并展开更深入的对话来代表用户的更多需求。
同时也要注意非语言性的线索，例如面部表情和身体语言等。
这些线索常常能帮助我们感知用户对话的情绪和态度，识别并解决问题。
清晰明了地表述问题保持表述清楚和简短很面对任何客户都非常重要。
问题应该清晰地设计出来，以确保客户完全了解该问题的含义。
为了帮助客户更好地了解问题，我们可以使用实际的示例或场景来说明想要解决的问题。
不要畏惧提出问题在获取用户需求时，团队需要注意不要让客户产生压力和困难。
一些用户可能会感到他们的需要不重要或错误。
这个时候你需要让用户放心，告诉他们这些问题与他们的需求相关，如果有疑问可以与团队进行讨论的。
同时，在获取用户需求时不要害怕问问题。
当你对某个需求不理解时，最好是问得明确。
这没有任何问题，相反，这有助于清晰和具体的理解用户的问题。
留意用户使用的语言和词汇虽然软件开发团队一般具有技术专业知识，但是需要注意用户理解能力和词汇使用方式。
一方面，我们需要确保尽可能简单明了的语言使用。
另一方面，我们应该谨慎使用过多的行话和技术术语。
因此，聆听并使用用户自己的词汇和术语更容易让用户感觉被关注到，理解软件项目，检查他们的需求。
软件需求工程学习软件需求工程的方法与实践
软件需求工程学习软件需求工程的方法与实践软件需求工程学习：软件需求工程的方法与实践软件需求工程是软件开发过程中至关重要的一环，它涉及到对用户需求的收集、分析、规范以及验证和确认。
在本文中，我们将介绍软件需求工程的基本概念、方法和实践，以帮助读者更好地理解和应用软件需求工程的知识。
一、软件需求工程概述软件需求工程是指通过系统化的方法，对软件系统的需求进行收集、分析、规范和验证的过程。
软件需求是对软件所需功能和性能的具体描述和规范，它是软件开发的基础和出发点。
软件需求工程的目标是确保开发人员和用户对软件需求达成一致，并建立可执行的需求规范。
它涉及到多个阶段的活动，包括需求获取、需求分析、需求规范、需求验证和需求管理等。
二、软件需求工程的方法1. 需求获取方法需求获取是软件需求工程的第一步，它旨在收集和理解用户对软件的需求。
常用的需求获取方法包括面谈、问卷调查、观察和原型开发等。
面谈是一种直接与用户交流的方式，可以深入了解用户需求；问卷调查可以扩大用户群体，获取更多的意见和建议；观察可以通过对用户使用行为的观察，获取隐含的需求；原型开发可以通过快速搭建出简单的软件原型，让用户直观地感受软件功能和界面。
2. 需求分析方法需求分析是对收集到的需求进行整理、分析和理解的过程。
通过需求分析，可以将抽象的用户需求转化为具体的软件功能和性能规范。
常用的需求分析方法包括需求建模、用例分析和数据流分析等。
需求建模用于描述软件系统的结构和行为；用例分析用于描述软件系统与用户之间的交互；数据流分析用于描述软件系统内部的数据传递和处理过程。
3. 需求规范方法需求规范是对已分析的需求进行详细描述和规范的过程。
需求规范应该具有清晰、一致、可测量、可追溯、可验证等特点。
常用的需求规范方法包括自然语言描述、结构化语言描述和形式化规范描述等。
自然语言描述是常用的需求规范方式，但容易存在歧义和模糊性；结构化语言描述使用表格、图表等方式呈现需求，可以提高可读性；形式化规范描述使用数学符号和逻辑表达式定义需求，可以提高精确性和一致性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1.1跟我学软件系统需求工程——如何获得软件系统的用户需求在本单元中希望重点了解和掌握什么是用户需求，需求的表达形式，如何获取用户需求，如何细分需求，同时在此阶段所应该形成的制品；另外也应该掌握如何采用用例图（Use Case）对用户的需求进行建模，以及Use Case方法最主要的优点。
1.1.1需求工程1、需求工程（1）需求工程结构图（2）需求开发和需求管理的流程其中，需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。
1.1.2如何获得用户需求1、什么是用户需求（1）关于用户需求1)它主要是说明系统所必须符合的条件或者应该具备的的功能，也即它用来描述系统应该和不应该做什么也即决定本系统应该有什么功能，从而开发者和用户可以创建一个初始化的商业联系。
2)重点在是应该做什么，而不是应该如何做。
3)需求最根本的挑战在于：寻找、交流并记录什么是真正需要的，并能够向用户和开发团队讲解。
（2）一个关于影响项目进展的因素的研究如下图（Jim Johnson 1994 Chaos:Charting the Seas of Information Technology. Published Report .The Standish Group）可见37%的问题都与需求有关，这就需要“需求开发”和“需求管理”。
（3）“需求管理”的两种方法●瀑布式在项目的第一阶段，在任何设计和实现工作之前，尽可能的推敲，把需求完全定义清楚，并把它稳定下来，并且实际开发前冻结需求，但历史证明这种方式是失败的，在项目很大的时候，冻结需求几乎没有可能。
●迭代式用一种条理化的方法来寻找、记录、组织和跟踪不断变化的需求。
这里的关键是“不断变化”这个词，把需求变化作为项目进展的不断驱动力，另一个重要的词是“寻找”，可以通过写出用例和召开需求研讨会等手段巧妙的得出需求。
整个问题都来自于，用户往往对自己的愿望并不清晰，需求会不断的变化。
所以，我们必须使用一种处理过程，这种处理过程的特点就在于适应这种需求的变化。
所以，无论是统一过程，还是设计模式，所有问题的焦点都在于如何适应变化。
2、需求的表达（1）Id（系统名称）shall 执行的功能，而 Shall包括“应该”或“必须”等的语句（2）表达需求可以采用多种不同的方式，如你可以用商业的概念、该领域的术语、框图或者其它方法将功能性的需求写成文档。
如：下面的“转帐需求”的表达1)我希望能够把一个帐号的金额转入另外一个帐号，系统应该能够让我选择我要转帐的银行；2)系统应该能够让我选择我要转帐的信用卡号，系统应该能够让我选择转帐的金额3、获得用户需求的目的（1）需求分析活动其实本来就是一个和客户交流，正确引导客户能够将自己的实际需求用较为适当的技术语言进行表达（或者由相关技术人员帮助表达）使开发人员明确项目目的的过程。
（2）通过需求分析，其主要的目的是为了获得和描述系统中所有的要求，以及生成一个在该系统中定义关键域类的模型。
从而在开发者与需求者之间建立相互理解和沟通。
4、如何获取用户需求（1）对用户进行访谈和调研了解客户方的所有要求以及潜在的要求，有时还需要在用户方工作一定时间以深入了解其业务流程。
然后，根据他们的要求来确定系统的整体目标和系统的工作范围。
（2）与用户进行充分的交流交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。
需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。
（3）可以将需求细分为下面的各个类型1)功能需求2)非功能需求也即技术性的要求，如响应时间、平均无故障工作时间、自动恢复时间等性能和安全等方面的要求----主要涉及系统性能、可用性、可管理性、可靠性、可扩展性、安全性等等。
环境限制、设计约束注意：但有人认为上面的这种分类方法太泛，但这种分类确实用得很广泛。
而在统一过程中，需求是按照FURPS+模型进行分类的，每个字母含义如下：F：功能性（Functional）：特性、能力、安全性。
U：可用性（Usability）：人性化因素，帮助，文档。
R：可靠性（Reliability）：故障周期，可恢复性，可预测性。
P：性能（Performance）：响应时间，吞吐量，准确性，有效性，资源利用率。
S：可支持性（Supportability）：适应性，可维护性，国际化，可配置性。
+：辅助和次要的因素，比如：实现（Implentation）：资源限制，语言和工具，硬件等。
接口（Interface）：与外部系统接口所加的约束。
操作（Operations）：系统操作环境中的管理。
包装（Packaging）：授权（Legal）：许可证或其它方式。
事实上，FURPS+模型并不是唯一的，但用它来作为需求范围检查表是很有效的，这可以降低考虑系统的时候遗漏某些因素的风险。
还有一些分类方式和FURPS+模型类似，比如ISO9126，它主要来自于美国软件工程研究所(SEI)。
5、应用要点（1）在这个阶段中，开发者一般不应该考虑具体的代码或程序细节。
将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；（2）用例仅能捕获功能性需求，不适合捕获非功能性需求和设计约束等。
功能性：日志和错误处理。
安全性，人性因素。
可靠性：可恢复性。
性能：适应性，可配置性。
实现约束：比如开发的领导层或者用户方坚持要使用Java开发。
采购的组件。
免费开放源码的组件。
接口：值得注意的硬件和接口，触摸屏，条码扫描仪，数据打印机，信用卡读卡器，签名读取器（第一版中不支持）。
（3）需求收集工作的特点1)问题复杂性：需求涉及的因素繁多,如运行环境,系统功能2)交流障碍：软件用户,问题领域专家,项目管理员具备不同的背景知识,相互交流困难3)不完备性和不一致性：用户的陈述往往不完备,各方面的需求可能存在矛盾4)需求易变：用户的需求变动极为普遍（4）用户需求不明确主要体现在四个方面1)在软件开发出来之前，用户自己也不清楚软件的具体需求；2)用户对软件需求的描述不精确，可能有遗漏、有二义性、甚至有错误；3)在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求；4)软件开发人员对用户需求的理解与用户本来愿望有差异。
6、避免下面的情况出现（1）跨过需求，直接进入了设计甚至实现阶段。
因为在需求方面任何小的疏漏都可能导致进展不利乃致失败，因为太多的工作被浪费在错误的方向上。
（2）用我们的想法来理解客户的需求设计不应该成为需求收集的一部分，将需求与设计分离是至关重要的。
我们常常是提出问题，然后是解决问题。
而不是有了一个解决方案之后，再找一个问题去适合它。
问题的解决方案必须在问题已经被确定、形成文档、理解和达成共识之后产生。
如果设计在需求之前提出，则系统用的就是自己的需求，并不能代表用户的利益。
在设计之前完整地定义问题永远都是明智的。
要做到这些的方法只有一个，就是站在用户的角度而不是设计者的角度看待系统。
（3）从一开始你就没听清客户要的是什么很多时候，用户并不知道自己要什么？需要我们去引导。
当系统存在多个用户时，你会发现不同的用户在需求方面是矛盾的。
7、某个餐馆定座系统需求示例（1）功能性的需求1)服务生可以通过系统查询是否有满足条件的桌子尚未定出2)服务生可以通过系统为顾客定座以及取消定座3)服务生可以查询客户以往的消费情况（2）非功能性的需求1)系统的响应查询时间应该小于10秒2)系统必须7X24小时服务，每天可以有30分钟的维护时间，同时只能在0点到1点之间（3）环境限制（约束条件）在局域网络的环境中完成此功能注意：不难看出，需求本身就是对客户而言产品必须满足的条件或具备的能力。
对于用户需要产品做的事情，比如要完成的样子我们称之为功能性需求。
还有一些不能算做产品要实现的功能，但是为了达到用户的期望值必须完成的一些附加需求，比如多长时间完成称之为非功能性需求。
8、感悟“需求收集”和“用例”（1）对用户的需求整理就像是理发顾客自己只知道大概的样子，多长时间完成这个发型等等，而到底要做成什么样自己根本不知道。
发型设计师需要不断的和客户进行交流，然后再根据自己的理解，加上多年的设计经验，推荐给顾客一种适合的发型与顾客进行确认。
（2）和用户交流本身就是需求收集的过程而只有了解了用户的需求之后才可能设计出系统的初始原形（提出一个大概的样子---系统的初步功能，这当然可以利用原形法或者面向对象的用例图来实现）与其进行确认。
9、软件系统的需求种类也相当复杂（1）问题以工程领域的例子开道吧。
比如设计一座跨江大桥：我们会考虑“连接南北的公路交通”这个“功能需求”，从而初步设计出理想化的桥墩支撑的公路桥方案；然后还要考虑造桥要面临的“约束条件”，这个约束条件可能是“不能影响万吨轮从桥下通过”，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及“大桥的使用期质量属性”，比如为了“能在湍急的江流中保持稳固”，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，“建造期间的质量属性”也很值得考虑，比如在大桥的设计过程中考虑“施工方便性”的一些措施。
（2）软件系统的需求种类也相当复杂和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如下图所示。
（3）理解需求种类的复杂性——超市系统案例我们列举了一个典型的超市系统的需求子集，从这个例子中可以清晰地看到需求可以分为两大类：功能需求和非功能需求。
简单而言，功能需求就是“软件有什么用，软件需要做什么”。
同时，注意把握功能需求的层次性是软件需求的最佳实践。
以该超市系统为例：1)超市老板希望通过软件来“提高收银效率”。
2)那么，我们可能需要为收银员提供一系列功能来促成这个目的，比如供收银员使用的“任意商品项可单独取消”功能有利于提供收银效率。
3)而具体到这个超市系统，系统分析员可能会决定要提供的具体功能为：通过收银终端的按键组合，可以使收银过程从“逐项录入状态”进入“选择取消状态”，从而取消某项商品。
从上面的例子中我们还惊讶地发现，非功能需求--人们最经常忽视的。
非功能需求又可以分为如下三类：1)约束。
要开发出用户满意的软件并不是件容易的事，而全面理解要设计的软件系统所面临的约束可以使你向成功迈进一步。
约束性需求既包括企业级的商业考虑（例如“项目预算有限”），也包括最终用户级的实际情况（例如“用户的平均电脑操作水平偏低”）；既可能包括具体技术的明确要求（例如“要求能在Linux上运行”），又可能需要考虑开发团队的真实状况（例如“开发人员分散在不同地点”）。