From be2f41d88b3b5989154f03c915f39d193fdfe896 Mon Sep 17 00:00:00 2001 From: Hui Lan Date: Sat, 18 May 2019 22:42:51 +0800 Subject: =?UTF-8?q?=E4=BF=AE=E6=94=B9=E8=92=8B=E4=BD=B3=E7=8E=B2=E5=AF=B9p?= =?UTF-8?q?arnas=E6=96=87=E7=AB=A0=E7=AC=AC9=E9=A1=B5=E7=9A=84=E7=BF=BB?= =?UTF-8?q?=E8=AF=91=E3=80=82=20=E9=9C=80=E6=B1=82=E6=96=87=E6=A1=A3?= =?UTF-8?q?=E5=BA=94=E8=AF=A5=E5=8C=85=E6=8B=AC=E4=BB=80=E4=B9=88=EF=BC=9F?= =?UTF-8?q?=20running=20environment,=20interfaces=20to=20the=20outside=20w?= =?UTF-8?q?orld,=20output=20in=20various=20states=20of=20system,=20output?= =?UTF-8?q?=20accuracy,=20change=20cases,=20handling=20of=20undesired=20ev?= =?UTF-8?q?ents.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- parnas-a-rational-design-process.rst | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst index 741a4a9..588c5c8 100644 --- a/parnas-a-rational-design-process.rst +++ b/parnas-a-rational-design-process.rst @@ -307,20 +307,27 @@ Page 8 Page 9 --------------------------------------------------------------------- -蒋佳玲 +蒋佳玲 OK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -我们使用关注点分离来获得以下部分，从而在我们的需求文档中获得完整性: +我们通过把关注点分离（ **Separation of Concerns** ）到章节，来获得需求文档的完整: -—— 软件必须在其上运行的机器的一种规格。这台机器不一定是硬件——对于一些系统，这一部分可能只是指向语言参考手册的指针； -—— 软件与外界通信必须使用的接口规范； -—— 对于每个输出，其值在任何时候都以系统的软件可检测状态表示； -—— 对于每个输出，软件需要多长时间或多快重新计算它； -—— 对于每个输出，它需要有多精确。 -—— 如果要求系统易于更改，则需求必须包含被认为可能更改的区域的定义。您不能设计一个系统，使所有的东西都同样容易更改，而且程序员不应该必须决定哪些东西最有可能更改。 -—— 需求还必须包含关于当系统由于不希望发生的事件而不能满足其全部需求时，系统应该做什么的讨论。大多数需求文档忽略了这些情况;他们讨论当一切都完美运行时将会发生什么，但是留给程序员决定在出现部分故障时该做什么。 -我们希望清楚地表明，除非定义了每一个需求，否则无法编写正确的软件，并且一旦您成功地指定了每一个需求，您就已经完全指定了系统的需求。 +—— 指定软件运行的机器。 机器不必是硬件 —— 对于一些系统，这一节可能仅仅包含语言参考手册的名字； + +—— 指定软件与外界通信必须使用的接口； + +—— 对于每个输出，指定所有情况下的值（用软件可检测到的系统状态表示）； + +—— 对于每个输出，指定软件需要多频繁或多快速重新计算它； + +—— 对于每个输出，指定精确度。 + +—— 如果要求系统易于更改，则需求文件必须包括可能发生更改的地方。 你无法设计一个系统，可以让所有东西都同样容易更改。 哪些东西最有可能更改，不应该由程序员判断。 + +—— 需求还必须讨论由于不希望发生的事件发生了，系统无法满足需求时系统应该做什么。 大多数需求文档忽略了这些事件; 它们只讨论当一切都完美的情况，却把出现部分故障时该做什么留给程序员去决定。 + +我们希望大家清楚，除非定义了每一个需求，否则无法编写正确的软件。 一旦成功地指定了每一个需求，您就已经完全指定了系统的需求。 -- cgit v1.2.1