答案

在系统分析的历史上，发现和形式化不明显、模糊或隐藏的需求是最困难的任务之一。客户往往无法清楚地解释他们具体需要什么，或者使用的术语并未揭示他们真实的期望。

关键特征：

• 隐性需求通过 分析、主动倾听、澄清问题、访谈 和观察来识别。
• 形式化发生在一个对客户和开发人员都能理解的语言中（例如，使用用户故事、BPMN场景）。
• 必须 记录和与客户确认澄清后的表达 以避免歧义。

问题的历史

未形式化需求的问题自早期实施项目以来就已存在。最初为此采用简单的访谈，现在也使用用户故事映射、原型制作、促进等方法。

问题

隐性需求导致任务错误设定、无谓的劳动成本和各方之间的冲突。

解决方案

使用访谈技术、可视化（流程图、原型）、促进和清晰的结果文档记录。在每个需求记录阶段后检查反馈。

反向问题。

在项目开始之前，是否可以提前形式化所有需求？

不可以，许多需求在原型制作和项目澄清过程中逐渐明确。

是否只记录客户明确表达的愿望？

不可以，分析师还应该处理隐性期望，分析商业目标，并识别隐藏需求。

系统分析师的任务是否仅仅是将需求翻译成技术任务？

不可以，分析师还负责需求的形式化、确认和澄清，识别矛盾。

常见错误和反模式

• 不记录中间协议。
• 认为所有需求同等重要。
• 仅记录显性表达的内容，而不分析真实流程。

生活中的例子

负面案例：
分析师记录了客户所说的一切，而没有 уточнять 细节。 优点： 开发快速开始，节省分析时间。
缺点： 由于期望错误，产生大量返工和与客户的冲突。

正面案例：
分析师制作原型，进行澄清会议，与客户一起记录隐性需求。
优点： 需求准确性高，客户满意，冲突较少。
缺点： 促进和收集反馈的成本。