- 需求获取可以分成哪些活动？
需求获取既涉及技术问题，也涉及社会交往的问题，是最需要交流的方面。
它可进一步分成查找需求源（识别需求的涉众）、网罗需求信息（收集各方面人员对产品的要求，得到“系统特性列表”）和整合需求信息等活动。
- 客户与开发人员的合作伙伴关系建立的前提是什么？
合作关系建立的前提：明确双方权利和义务
- 软件需求工程中，SRS指什么？
软件需求规格说明
需求分析员对来自不同客户的信息进行整理，把业务需求、业务规则、功能需求、质量目标、解决方案的建议等内容区分开来，形成SRS
- 如何更好地让客户听取对需求工作成果的解释？
- 对于MIS系统，通常情况下怎么样的需求，其优先级比较高？
- 如何理解需求确认中客户的“签字”？
- 客户和开发人员之间合作伙伴关系的核心就是产品和需求达成一致。很多组织把在需求文档上签字作为客户认可需求的标志。
- 需求批准过程的所有参与者都应该明白签字意味着什么，否则会出现很多问题。
- 问题之一是客户代表把在需求文档上签字视作毫无意义的仪式。
- 另一个关于签字的问题是，开发经理把签字作为冻结需求的方法。
- 签字不仅仅是仪式，更重要的是建立需求协议的基线 。
- 项目的范围说明主要应该包括可哪些方面的内容？
项目的范围说明主要应该包括以下三个方面的内容：
1．项目目的的合理性说明。即解释为什么要实施这个项目，也就是实施这个项目的目的是什么。
2．项目目标。项目目标是项目所要达到的期望产品或服务，确定了项目目标，也就确定了成功实现项目所必须满足的某些数量标准。项目目标至少应该包括费用、时间进度和技术性能或质量标准。
3．项目可交付成果清单。如果列入项目可交付成果清单的事项一旦被完满实现，并交付给使用者——项目的中间用户或最终用户，就标志着项目阶段或项目的完成。
- 根据前景和范围文档，我们可以判断出某项特性或需求是否包括在项目中，一般有哪三种情况？
·一种是被提议的需求明显在范围之外。
·另一种可能是需求显然是在定义好的项目范围之内。
·第三种可能是被提议的新需求不在范围之内，但它很有价值，因而需要对项目范围做出调整以容纳这一新的需求。
- 寻找客户需求中，为征求客户的意见，必须采取哪几步？
- 明确项目用户需求的来源。
- 明确使用该产品（软件）的不同类型的用户。
- 与不同用户类的代表进行沟通。
- 遵从项目的最终决策者的意见。
- 能举出和理解四种以上的软件需求来源。
- 与潜在用户进行交谈和讨论
要想知道某个新软件的潜在用户的需求，最直接的方式莫过于向用户了解。
- 描述现有产品或竞争产品的文档
这类文档可能也会描述产品必须遵循的行业标准，以及法律和法规等。（如*人事管理软件）
- 系统需求规格说明
同时包含硬件和软件的产品，具有一个高级的系统需求规格说明，用于描述整个产品。
- 现有系统的问题报告和改进要求
客户服务和技术支持人员也是需求的重要来源。
- 市场调查和用户问卷调查
这类调查能够从广大的潜在用户那里收集到大量的数据。
- 观察用户如何工作
让需求分析员观察现有系统的用户或将要推出的系统的潜在用户如何进行工作。
- 用户工作的情景分析
在确定用户需要借助系统完成哪些工作之后，需求分析员就能推导出用户完成这些工作必需的功能性需求（借助USER CASE用户实例）。
- 画出客户和用户的层次结构图
- 用户代表（代言人）的作用是什么？
- 每个项目都有几位用户类的关键成员负责提供需求。我们称他们为用户代言人或项目（业务）协调人。
- 设置用户代言人为构造客户和开发人员之间的伙伴关系提供了有效途径。
- 每位用户代言人都是他所属用户类的成员与项目的需求分析员之间的主要联系人。
- 如果每位用户代言人都被赋予足够的权力，能够为他代表的用户类做出具有约束力的决定，他们就能发挥最大效应。
- 理解不同情况下，需求“谁来做出决策”。
- 如果是个别用户之间的分歧，则由用户代言人来裁决。
- 用户经理表述的需求有时会和其部门中实际用户的需求相矛盾。但不属于用户类的经理应该服从于用户代言人，因为后者是用户的代表。
- 当开发人员对产品的想法与客户的要求不一致时，通常应由客户做出决定。
- 如果不同的用户类或客户群提出的需求发生冲突时，应支持最重要的用户类或对产品的商业前景影响最大的客户群提出的需求。（如讨论某一财务付款流程，谁最重要？）
- 不同的企业客户都可能要求按他们自己的喜好设计产品。解决办法还是依据项目的业务目标来确定哪些客户对项目的成败影响最大(总经理决定重大流程)。
- 调查研究的主要方法有哪些？
用户访谈
收集和研究资料
调查问卷
实地观察
- 问卷调查和用户访谈的优点和缺点各是什么？
一）收集和研究资料方法
- 以MIS(管理信息系统)为例，资料包括：企业组织结构图、公司战略计划、各部门的正式目标和职责、政策手册、操作过程、工作指令、各种表格、报告、会议记录。
- 优点：获取大量历史、静态信息，有助于分析问题、数据精确。
- 缺点：需要整理归纳、深层次存在的问题不易发现。
二）问卷调查法
- 步骤：确定采用的调查问卷的格式;设计调查问题;复制和分发调查问卷，回收和整理问卷。
- 注意：试题易答、避免歧义或遗漏
- 优点：大量发放、快速、低成本，保护隐私（不记名），便于归纳整理。
- 缺点：问卷不够灵活（内容局限）、信息质量难于保证。
3.用户访谈优点和缺点
访谈为分析人员提供了与访谈对象*沟通的机会；通过访谈可以挖掘更深层次的用户需求；访谈允许分析人员使用一些个性化的问题；成功的访谈在很大程度上取决于分析人员的经验与技巧；
访谈占用的时间较多，访谈后的资料整理，也需要花费较多的时间。
四）实地观察法
直接、直观、带有一定的实验性。
优点：获取第一手数据、有助于弄清复杂流程（包括异常场景）、获取多方面数据，可以证实收集的资料正确与否，更正不正确的概念，澄清模糊的概念（某*工资处的工改）。
必须懂得业务、跟随进行实际工作、较花费时间。
- 各举两个例说明“业务规则”、“外部接口需求”和“数据定义”、“约束”。
当客户说只有特定用户在特定条件下才能执行某一动作时。例如：“如果一个药剂师在危险化学制品培训方面是可靠的，那么他就可以在一级危险药品清单上订购化学制品”。业务规则是有关业务过程的操作原则。可以用一些软件功能需求来加强规则，例如，让“化学制品跟踪系统”可以访问培训记录数据库。
又如：图书馆的借阅者最多可以同时借10本书。
- 外部接口需求
描述了系统与外部世界的联系，例如：
- “从<某些设备>读取信号”
- “给<一些其它系统>发送消息”
- “以<某种格式>读取文件”
- “能控制<一些硬件设备>” ERP之DCS和考勤机、Lims（实验室信息管理系统）及MES的例子
- ERP读取数字矿山设备的数据
- 约束
对设计和实现的约束(constraint)合理地限制了开发人员可用的选择，例如：
- “必须使用<一个特定的数据库产品或语言>”
实例：人事开发工具的选择、某集团SAP产品选择
- “PC机内存不超过多少G”
- “操作必须与<其它系统>相同或类似”
- 理解和说明用例法中的相关概念：用例、角色、主执行者、场景。
- 用例描述了系统与外部角色之间的一系列交互。
- 角色(actor)指与系统交互以实现某种目的的人、软件系统或硬件设备。角色的另外一个名称是用户角色(user role)。
用例描述了在不同条件下，系统对于某一项目相关人员的请求作出的响应。
提出请求的相关人员叫做主执行者。主执行者通过发起系统的一次交互来实现某个目标。系统对于任意执行者作出的响应。
根据执行者作出的请求和请求涉及的条件，系统将执行不同的行为序列，每一行为序列称之为一个场景。一个用例是多个不同场景的集合。