在需求中编码体系结构

Question

为了开发下一代的医疗监控设备，由几个具有嵌入式软件的专用硬件系统组成，我正在研究当前一代的医疗监控设备的需求，看看什么是可以重用的。在此过程中，我能够跨越一些需求，这些需求明确地为某个子系统和假定特定体系结构的需求指定了特定的体系结构。

我的问题是，有这样的要求是正确的吗，还是这样的设计决策真的应该被降为架构设计呢？我认为假定一个体系结构的要求是最麻烦的，因为它们在该体系结构中确实有优点，但当选择了不同的设计时，它们可能是胡说八道，而且不总是能够以一种独立于体系结构的方式重写它们。

一些解释了这些要求的例子：

该系统将由硬件模块X，Y和Z组成，的基本原理是:这是我们以前做过的，我们没有遇到任何麻烦。

我的问题是:最终用户不会关心我们如何划分系统，只要它不是工作的负担。我也看不到任何其他利益相关者会在这里拥有既得利益。

硬件模块X应与硬件模块Y. 原理物理分离:这允许更容易地存储系统，并允许用户在遇到问题时交换更脆弱的模块X。

我的问题是:我可以同意的需求的意图，也是最终用户可能关心的事情，但我不明白需求如何能够指一个硬件模块，其存在取决于一个非需求的设计决策。

硬件模块Y应包含软件功能S. 的基本原理:软件功能S需要相当大的处理能力，只有模块Y才能使用。

我的问题是:它也可以决定给硬件模块X一个更有能力的处理器，让它处理软件功能S。

另一个问题是，至少我们中的一些人坚信，所有模块/软件需求都必须可以追溯到系统需求，如果那些与体系结构相关的需求被丢弃，这可能就不再是真的了。

Answer 1

原则上，要求应该处理问题空间，而不是解决空间。然而，当您使用医疗设备时，有一个规范的理由将此作为设计约束，因为您必须能够证明某些行为。尤其是当涉及到证明变化时，模块之间定义的独立性将使向监管机构解释变得更加容易。

你所展示的理由与我上面所说的并不完全一致，但你也必须考虑一些隐含的硬件约束，你必须接受这些约束(例如Y模块中的计算能力)。

因此，我认为这必须被视为一个设计上的限制。将其声明为一项要求将确保某人在不触发评审的情况下不会决定改变这一情况。

Answer 2

不，您所写的不属于需求，而是属于体系结构。

需求由用户意愿组成，用户不应该知道也不应该关心您是使用库X，还是使用模块Y。

同时，在需求中添加理由也是没有意义的。

该系统将由硬件模块X，Y和Z组成，的基本原理是:这是我们以前做过的，我们没有遇到任何麻烦。

那得看情况。如果硬件模块是设备的内部部分，那么这既不属于任何需求，也不属于软件体系结构。

但是，如果硬件模块是用户可以插入或退出的模块，那么它们确实属于需求。例如，他们希望能够连接USB接口。或者他们想要连接一个特定的探头到一个超声音系统。

事实上，你是为了一个原型做的，这是不相关的。您的基本原理可以转到与硬件相关的文档。

硬件模块X应与硬件模块Y. 原理物理分离:这允许更容易地存储系统，并允许用户在遇到问题时交换更脆弱的模块X。

更好的文本(在敏捷方法中)是:作为设备ABC的用户，我希望能够分离X，以便在出现问题时可以替换它。

是的，这属于要求。并对软件产生影响。

硬件模块Y应包含软件功能S. 的基本原理:软件功能S需要相当大的处理能力，只有模块Y才能使用。

这听起来不像是个要求。实际上，这可能是HW部门的内部要求，这也影响了软件。因此，我会把它放在体系结构中(我们试图在软件中实现这一点，但结果并不顺利)。我们用HW来代替)。

这不属于用户需求，因为用户并不关心如何实现某些功能。

Answer 3

“系统必须使用Windows技术”可能是一个要求，因为最终用户是Windows商店，不能运行Linux解决方案。这是一个架构决策，但仍将是用户需求的一部分。

同样地，基于最终用户的系统，这些广泛的组件必须以这种方式定义，这样模块化可能有一个很好的理由，当然，您仍然可以以任何方式实现它们。

有时，架构决策是需求的一部分，请考虑应用程序是one应用程序还是桌面应用程序的最常见的例子。这绝对是一个架构决策，但在用户需求中往往会出现这种情况。

因此，您的特定需求是否只是一个过于热心的、微观管理的客户，还是有一些理智的理由是我们无法判断的。这可能取决于“模块”是如何定义的，如果它们运行在一组硬件盒上，那么它们听起来相当现实。如果您正在编写一个单块桌面应用程序，并且它们类似于dll，那么它们可能是不明智的，您应该回击它们。

PS。如果需要强大的可追溯性，则无法将所有内容映射到用户需求，因为最终用户不会定义许多方面。在这些情况下，您必须将它们映射到您自己定义的设计需求。