The need for developing a complete specification may encourage an analyst to write detaile...

Complete—All features of interest are described by requirements.

Example of incompleteness: The SatWatch specification does not specify the boundary behavior when the user is standing within GPS accuracy limitations of a state’s boundary.

Solution: Add a functional requirement stating that the time depicted by SatWatch should not change more often than once very 5 minutes.

Consistent—No two requirements of the specification contradict each other.

Example of inconsistency: A watch that does not contain any software faults need not provide an upgrade mechanism for downloading new versions of the software.

Solution: Revise one of the conflicting requirements from the model (e.g., rephrase the requirement about the watch not containing any faults, as it is not verifiable anyway).

Unambiguous—A requirement cannot be interpreted in two mutually exclusive ways.

Example of ambiguity: The SatWatch specification refers to time zones and political boundaries. Does the SatWatch deal with daylight saving time or not?

Solution: Clarify the ambiguous concept to select one of the mutually exclusive phenomena (e.g., add a requirement that SatWatch should deal with daylight saving time).

Correct—The requirements describe the features of the system and environment of interest to the client and the developer, but do not describe other unintended features.

Example of fault: There are more than 24 time zones. Several countries and territories (e.g, India) are half an hour ahead of a neighboring time zone.