parnas-a-rational-design-process.rst: 融入胡刚强的翻译. (PDF page 9).

1 files changed, 10 insertions, 11 deletions

diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst
index 9c8e46a..3b38a04 100644
--- a/parnas-a-rational-design-process.rst
+++ b/parnas-a-rational-design-process.rst
@@ -302,26 +302,25 @@ Page 8
 Page 9 
 ---------------------------------------------------------------------
 
-(蒋佳玲 翻)
+(蒋佳玲 翻，胡刚强 改)
 
-我们通过把关注点分离（ **Separation of Concerns** ）到章节，来获得需求
-文档的完整:
+我们通过使用关注点分离（ **Separation of Concerns** ）来得到下面的章节，来获得需求文档的完整性:
 
-- 指定软件运行的机器。 机器不必是硬件 -- 对于一些系统，这一节可能仅仅包含语言参考手册的名字；
+- 软件运行的机器的规范。机器不必是硬件 -- 对于一些系统，这一节可能仅仅指向一个语言参考手册；
 
-- 指定软件与外界通信必须使用的接口；
+- 软件与外界通信必须使用的接口的规范；
 
-- 对于每个输出，指定所有情况下的值（用软件可检测到的系统状态表示）；
+- 所有情况下的每个输出值（在软件可检测的系统状态方面）的规范；
 
-- 对于每个输出，指定软件需要多频繁或多快速重新计算它；
+- 软件重新计算每个输出的必须的频率与速度；
 
-- 对于每个输出，指定精确度。
+- 每个输出必须达到的精度。
 
-- 如果要求系统易于更改，则需求文件必须包括可能发生更改的地方。 你无法设计一个系统，可以让所有东西都同样容易更改。 哪些东西最有可能更改，不应该由程序员判断。
+- 如果要求系统易于更改，则需求必须包括被认为可能发生更改的地方的定义。你无法设计每个地方都同样容易改变的系统，并且，程序员不应该去决定哪些东西最有可能被改变。
 
-- 需求还必须讨论由于意外事件发生了，系统无法满足需求时系统应该做什么。 大多数需求文档忽略了这些事件; 它们只讨论当一切都完美的情况，却把出现部分故障时该做什么留给程序员去决定。
+- 需求还必须讨论由于意外事件，系统无法满足需求时应该做什么。大多数需求文档忽略这些情况;它们讨论当一切都完美时将发生什么，却把部分故障发生时应该做什么留给程序员去决定。
 
-我们希望大家清楚，除非定义了每一个需求，否则无法编写正确的软件。 一旦成功地指定了每一个需求，您就已经完全指定了系统的需求。
+我们希望明确，除非定义了每个需求，否则无法编写正确的软件，并且一旦成功地指定了每个需求，你就已经完全指定了系统的需求。