在移动需求工程中，需求分析过程的哪些阶段是最具挑战性的阶段？

Question

我正在研究建立一个需求分析模型，作为移动应用程序开发的需求工程的一个阶段，考虑到它的局限性和需求(敏捷性等等)。)，我试图找出这个过程的哪些部分(移动开发的需求分析)是最具挑战性的部分(因此我可以更多地关注)，以及如果有任何阶段您认为我需要包括或排除(例如。一些人可能认为，质量计划可能是必要的，也可能是不必要的，等等。

为了更清楚地说明，下面列出了我可以关注的几个领域(顺便说一句，您的建议可能是下面列表中的任何内容)。

质量函数的-Requirements规范-Prototyping -Requirements优先级-Focusing

Answer 1

功能需求的水平可追溯性。

纵向可追溯性，从父需求到子需求，一直被认为是需求分析的重要组成部分。水平可追溯性是一个新概念，直到最近才变得可行。

功能需求获取输入数据，进行某种处理，并生成输出数据项。如果没有缺少需求，则可以通过一系列需求将所有系统输出追溯到系统输入。

“跟踪”是通过注意每个输入数据项必须是其他需求的输出来完成的。因此，需求是水平连接的，输入到输出。缺少连接意味着缺少需求。

“手工”验证多个需求的水平可追溯性是完全不可行的。使用电子表格宏进行分析可以轻松找到大多数缺少的需求。

这是非常新的，也不为人熟知。我编写了一个Excel宏来部分自动化这个过程。在http://www.barbarabea.com/?page_id=11免费提供

还有一个教程和用户指南。

我用它做了几个项目。其中一个项目有一套成熟的要求，即基于这些要求的产品已经完成并发运。当这些reqs放在电子表格中时，我们发现有很多reqs丢失了。(~40%)另一个项目使用它来编写新的功能需求。对于新的reqs，图形输出是最重要的部分。查看所有req是如何绑定在一起的，有助于确定接下来应该编写哪些req，以及哪些req需要修改，因为它们与其他req不太匹配。

我确实有另一个主意。但它更多的是学术性而非实用性。它也是写在芭芭拉比阿博客。

我们被告知，一个好的要求的一个特点是它是明确的。这通常被定义为只有一个可能的解释。任何具有子需求的高级别需求都是不明确的。否则，它将不需要子需求。

但是，如何决定一个需求是否含糊不清？我创建了一个客观的测试，以确定功能需求是否含糊不清。如果您从一组水平连接的功能需求开始，那么每个功能需求都是明确的当且仅当处理步骤是一个算法。

告诉过你这是学术性的。但这也是我所见过的唯一客观的模糊检验。