软件开发的201个原则（第31~60）学习笔记_立即修复需求规格说明中的错误-CSDN博客

需求难以理解，更难以说明。对此，错误的解决方法是草率地完成需求规格说明，匆忙地进行设计和编码，然后徒劳地希望:
1.任何系统都比没有系统要好。
2.需求迟早会被解决。
3.或者，设计师在开发的过程中会明确可以开发什么
正确的解决方法是，立刻不计代价、尽可能多地获取需求信息。应使用原型的方法。

立即修复需求规格说明中的错误

因为你越是往后推，你就越是难办，难处理，困难就越是大，成本就越高

原型可以降低选择用户界面的风险

原型的确有很强的好处，主要是快捷，能够立马给出一个肉眼可见的演示效果，这样是更利于项目的推进的。

记录需求为什么被引入

假设客户后续要求做一个需求变更，我们需要知道原始需求的动机，以便确认是否可以安全地变更。同样当系统无法满足某个需求时，我们需要知道需求的背景，才能决定是修改系统设计以满足需求，还是修改需求以匹配系统。

确定子集

在编写需求规格说明时，要清晰识别有用的需求的最小子集。

评审需求

如果需求规格说明的某些部分是用更正式的语言编写的

相关人员可以“看到”系统功能，而不只通过“阅读”了解系统如何运行。

就是要方便快捷，让协作方能够更为快速认知

避免在需求分析时进行系统设计

需求阶段的目标是明确系统的外部行为

要最够明确，以保证当使用需求规格说明作为指引时，所有设计人员都能对系统的目标行为做出相同的理解。

给一个善意的提醒：

警告: 这里包含的设计，仅用于辅助理解产品的外部行为。在系统外部行为相同的情况下，设计人员可以选择任何设计方案。

使用正确的方法

就是面对不同的需求，我们要给出适配的解决方案，这真的很是重要

使用多角度的需求视图

就是多来一些图或者是分析的方法

介绍一下有限状态机

其实简单说，就是像是脚本一样，即使你有输入之后，它给你弄一套流程，之后这个流程中的每一个步骤就叫做状态，然后，这个步骤当然是可以数完的呀，那么就是有限的，机，相当于机制，或者这一整套，反正就是不是机器的意思。

有限状态机（Finite State Machine，FSM）是一种计算模型，用于描述系统的行为。它由一组状态、转移和动作组成，可以根据输入和当前状态来进行状态转移，并执行相应的动作。

在有限状态机中，系统的行为被建模为从一个状态到另一个状态的转移。每个状态代表系统所处的特定状态或条件。转移表示从一个状态到另一个状态的切换，转移可以由输入、事件或其他条件触发。动作则是与转移关联的操作，用于执行特定的行为或任务。

有限状态机可以分为两种类型：确定性有限状态机（Deterministic Finite State Machine，DFSM）和非确定性有限状态机（Nondeterministic Finite State Machine，NFSM）。

确定性有限状态机（DFSM）：在确定性有限状态机中，给定当前状态和输入，只能有一种确定的状态转移。它使用明确定义的规则来确定下一个状态。
非确定性有限状态机（NFSM）：在非确定性有限状态机中，给定当前状态和输入，可以有多种可能的状态转移。它允许模型在某些情况下具有多个可能的未确定的状态。

有限状态机在各种领域中得到广泛应用，例如编译器设计、网络协议、自动控制系统等。它们提供了一种简洁而有效的方式来建模和分析系统的行为，使得复杂的问题可以用一组离散的状态和转移来描述和解决。

总结起来，有限状态机是一种用于描述系统行为的计算模型，由一组状态、转移和动作组成。它提供了一种清晰、简明的方法来建模和分析系统的行为，具有广泛的应用领域。

合理地组织需求

站在对方的角度，从他们的使用视角出发，提出需求，这个很重要。

给需求排优先级

书写要简洁

真的，我们写的是实战工程，是要赚钱的项目呀，你又不是写论文，糊弄人的，写那么刁钻，让人看不懂干嘛

给每个需求单独编号

减少需求中的歧义

对自然语言辅助增强，而非替换

可通过使用有限状态机、谓词逻辑、Petri 网络、状态图筹来减少歧义

为什么要有这些图和逻辑说明啥的，就是为了消除自然语言的歧义的

在更形式化的模型前，先写自然语言

你要是看了上面的那个例子，你就知道了，如果上手就是用形式化的东西来写，那简直不是人看的东西。

工具和形式都是来促进我们自然理解的

最好的方法是(1) 写自然语言，( 2)写形式化模型，(3)根据形式化模型中发现的问题去修改自然语言，以减少歧义。

保持需求规格说明的可读性

因为这个需求文档是要被很多人阅读的，各色的人来看，那么我们需要保持我们给他们分别阅读的东西，要保持一个一致性，要不然大家都是各种理解，那怎么行？

有效方法，保持自然语言，同时结合更形式化的多视角

明确可靠性

可靠性真的不是随便乱说的，要不然没有用，失去可信度，对于什么事情都很可怕

可以从以下三个方面看：

当编写可靠性需求时，要区分以下概念
1.需求失效 (Failure on Demand)。系统正确响应的可能性(百1分比)是多少?例如，“系统应正确报告 99.999%的病人生命体征异常”。
2.失败率(Rate ofFailure)。这个概念和“需求失效”类似，但2.它以单位时间内的数值来衡量。例如，“系统无法正确报告病人生命体征异常的次数，每年不超过 1次”。
3.可用性(Availability)。系统可用的时间百分比是多少?例如“在任何自然年内，电话系统( 至少)在 99.999%的时间可用"。

应明确环境超出预期时的系统行为

当环境超出为其定义的任何约束时，在软件需求规格说明中应明确声明预期的系统响应。

自毁的待定项

对于一个需求文档来说，的确是不好的

但是如果创建了，我们就要在一个计划的时间内，将其完善好，以达到上面说的，自毁

需求最好保存到数据库中

理想情况下，需求规格说明本身就是整个数据库有组织的导出。

为什么只有被淘汰的页面被修改过时，才需要写回外存

当一个页面被淘汰时，系统需要为其分配一个新的物理页面，因此原来的页面内容需要被移出主存。如果该页面已被修改过，其内容在主存中与外存中的内容不一致，需要将主存中的内容写回外存，以保证数据的一致性。而如果页面没有被修改过，它在主存和外存中的内容是一致的，不需要写回外存。这样可以减少对外存的写入次数，提高系统性能。