parnas-a-rational-design-process.rst: Undesired Events翻译为意外事件.

1 files changed, 2 insertions, 2 deletions

diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst
index 2f20711..9c8e46a 100644
--- a/parnas-a-rational-design-process.rst
+++ b/parnas-a-rational-design-process.rst
@@ -319,7 +319,7 @@ Page 9
 
 - 如果要求系统易于更改，则需求文件必须包括可能发生更改的地方。 你无法设计一个系统，可以让所有东西都同样容易更改。 哪些东西最有可能更改，不应该由程序员判断。
 
-- 需求还必须讨论由于不希望发生的事件发生了，系统无法满足需求时系统应该做什么。 大多数需求文档忽略了这些事件; 它们只讨论当一切都完美的情况，却把出现部分故障时该做什么留给程序员去决定。
+- 需求还必须讨论由于意外事件发生了，系统无法满足需求时系统应该做什么。 大多数需求文档忽略了这些事件; 它们只讨论当一切都完美的情况，却把出现部分故障时该做什么留给程序员去决定。
 
 我们希望大家清楚，除非定义了每一个需求，否则无法编写正确的软件。 一旦成功地指定了每一个需求，您就已经完全指定了系统的需求。
 
@@ -393,7 +393,7 @@ Page 13
 
 (袁世家 翻， 卢梦茹 改， 李润超 改)
 
-在其它情况下，我们从描述内部数据结构开始；在有些情况下，这些数据结构由子模块实现（并隐藏）。 对每个访问程序，我们包括一个函数 [10] 或者 LD-关系 [14], 用于描述它对数据结构的影响。对于模块返回给调用者的每个值，我们提供另外一个数学函数，这个数学函数叫做抽象函数，它将数据结构的值映射进返回值。对于每个不想其发生的事件，我们描述如何检查它。最后，我们提供一个"验证"，论证拥有这些属性的程序将会满足模块规范。
+在其它情况下，我们从描述内部数据结构开始；在有些情况下，这些数据结构由子模块实现（并隐藏）。 对每个访问程序，我们包括一个函数 [10] 或者 LD-关系 [14], 用于描述它对数据结构的影响。对于模块返回给调用者的每个值，我们提供另外一个数学函数，这个数学函数叫做抽象函数，它将数据结构的值映射进返回值。对于每个意外事件，我们描述如何检查它。最后，我们提供一个"验证"，论证拥有这些属性的程序将会满足模块规范。
 
 我们继续分解与设计子模块，直到每个工作任务足够小，小到即便负责这个模块的程序员离开了项目，我们也可以承担放弃它并重新开始的代价。