I think we need to take types and slots into account while calculating ambiguity because static structure (types and slots) could be as important as processes (UCs), if not more. To prove that, see this task of clarifying a TBD, such tasks almost always need defining new detailed types.

Maybe we can do this by defining a set of standard simple types that are considered unambigous while calculating ambiguity. This will be something like the list of elementary use cases we already have for UCs, e.g., creates, reads, etc.

However, it is possible that some projects may need additional simple data types. If we are going to allow that, we can extend requs syntax to mark data type as "simple". If we go this way, we don't even need a standard list of simple types that requs recognizes, because SRS author will decide on his own which of his types are "simple".

UML also has enumeration stereotype for class (and probably a lot of other crazy stuff, from which I think enumerations deserve some attention). Maybe we should extend the syntax in this direction, too. I mean, allow enum definitions and consider them as simple types.

After we define what is a "simple" data type, each slot defined as informal will give +1 ambiguity point, each slot using a simple type or another type from this SRS will decrease ambiguity.

Preciesly, ambiguity could then be calculated as:

A = u * Au + s * As

where:

• Au is an ambiguity of use cases, that is exactly what ambiguity now is.
• As is an ambiguity of types. This is the new component corresponding to types ambiguity.
• (u + s) must be equal to 1 to keep ambiguity in a range of [0..1]. They are the weight coefficients that represent the impact of use cases and types in overall ambiguity. In a simple case we can consider both equal to 0.5.