Splitting the Requirements Atom

Requirements should exhibit, besides their logical properties (correct, complete, consistent, unambiguous), further important qualities. Atomicity is one of them. When is a requirement said to be atomic? For example, can (1) a = 21 be an atomic requirement? Well, it could be split into (2) a ≥ 21 and a ≤ 21 or even worse into (3) a is odd, a is not a prime, a > 15 ∧ a < 25 Does that mean (1) not atomic? In requirements literature there are lots of statements like: “A requirement is not atomic, if it can be split into more than one requirement.”, but nothing rigorous (as it seems). Alternatively, can the atomicity concept from logic take us further? Logically, a requirement is a sentence, i.e. they evaluate to either true or false. In particular, an atomic sentence is a formula that doesn’t contain any logical symbols (and, or, not, quantifiers) and thus no variables. However, with requirements we want to express properties on the class level (Boy loves Girl), usually not for single instances (Abelard loves Heloise). So, the atomicity concept from logic is not sufficient for requirements. Perhaps it can be expanded in a reasonable way? Worth to think about. Fortunately, the above example contains only a constant a, such that the atomicity concept of logic applies without modification. This leaves us with 2 kinds of atomicity: 1. the logical one, s.t. a=21 can be called atomic. 2. the ‘atom splitting’ one that divides = into le, ge, s.t. a = 21 could not be called atomic. How do these 2 interpretations relate to each other? Are they contradictory? Atomicity in 1 and 2 is compatible if = seen as an abstraction of ≥ and ≤. This means, they are statements on different abstraction levels, and since it makes lot of sense to picture requirements on different levels of abstraction separately it is perfectly reasonable to call a = 21 atomic. For example, Use Case Diagrams are a perfectly reasonable way to describe functional requirements, although they do not contain all details. Notice, that in addition, higher abstraction levels often use reduced language, that makes it impossible to express the details anyway, as in the = and Use Case Diagram example. Thus, a = 21 can be called atomic, with respect to a certain abstraction level, and can also be split into details, like a ≥ 21 and a ≤ 21. Such details on rock bottom level are sometimes called atoms, too (e.g. by Robertson & Robertson). So long |= PS Open Issue: can the logical atomicity be broadened to a useful concept in requirements?

About modelpractice

Modeling Theory and Abstraction Awareness in strive for scientific rigour and relevance to information systems engineering.
This entry was posted in Requirements and tagged , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s