ARIA

 

Automated Requirements Intelligent Analysis

 

Requirements Analysis

Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous inspection have been shown to help deal with these issues. Ambiguities, incompleteness, and inconsistencies that can be resolved in the requirements phase typically cost orders of magnitude less to correct than when these same issues are found in later stages of product development - Wikipedia

 

ARIA provides thorough and detailed analysis by machine to ensure that ambiguity is highlighted. It uses consistent reasoning to work out what is true, so it is constantly searching for inconsistencies. It works in a space bounded by objects, logic and numbers, so any incompleteness it finds can take many forms, and cross boundaries.

 

The first draft of a specification may be reasonably clean, but as it is amended it can become grubbier and grubbier. ARIA analyses it anew each time, without guesswork or boredom.

 

Verification

Verifiability is necessary for a requirement but there are other important issues. A requirement can be verifiable yet incorrect; and assessing verifiability alone will not detect incorrect requirements. Moreover, verification is totally irrelevant with regard to a requirement which has been overlooked. Mere analysis, inspection, or review alone will find some of these issues but generally is far weaker than usually is realized - Wikipedia

ARIA allows “natural” expression of a requirement, reducing the probability that it will be incorrect.

“mere analysis” refers to a person doing the analysis – the limited focus needs to be broadened by machine analysis, tirelessly following every path.

The visibility of the structure that ARIA builds reduces the possibility that a requirement will be overlooked.

 

 

Why ARIA?

 

People have a fundamental limitation of no more than six to nine pieces of information in play at any one time – more than that, and they “chunk” information – they simply assume that nothing will change while they work on a subset.

 

In attempting to improve the outcomes of projects, it became clear in the 1960s that people could not manage more than about fifty activities without some tool to assist them – they would become confused at the interplay of the different activities as the durations changed. A tool – Critical Path Method – was developed to assist in planning of projects. It provides a time model of the activity interactions, and projects with thousands of activities are regularly planned with it. It is fairly crude, as it does not allow for the free interplay of time and cost and risk in its algorithm, but it was a considerable improvement on unassisted human planning.

The analogy with building a model for specifications is not perfect – activities can be treated as largely independent, while the objects described in a specification will usually be strongly interdependent. Concentration on just one aspect of the relations among the objects – say one of propositional, existential or temporal logic, or the hierarchy of objects, would seem to be a mistake, as it is the holistic nature of the specification that needs to be modelled, there being no equivalent in a specification of the simple and powerful metric of the early finish date of a project.

 

ARIA is to specifications what CPM is to projects – a method of modelling to handle complexity.

 

Large specifications often have contributions from specialist areas, so it is possible that no person has an in-depth understanding of the complete specification. ARIA can take over that role, with contributions of knowledge from the various areas, integrated in ARIA’s knowledge structure.

 

ARIA breaks the human limitation of six to nine pieces of information in play, and can manage millions of connections among objects and relations, a density of knowledge that would overwhelm a person.

 

What Is ARIA?

 

ARIA is a complete system for reading specifications, extracting the meaning, and building an accurate and complete representation of the knowledge contained in the specification.

 

ARIA combines grammar and semantics with seamless self-extensibility – the new knowledge it finds in the text is combined with its existing knowledge structure.

 

It has a global dictionary of words for which it already has modelling, and it builds a local dictionary as it reads the specification – adding words and phrases as it finds their definitions. The definition may just be an acronym for a phrase already encountered, or it may be a full literal definition.

 

ARIA provides a complete synthesis of the logics found in specifications – propositional, existential, temporal, locational, set handling, number handling, state transitions, as well as allowing relations on relations without limit.

 

At its base, ARIA operates by dynamic constraint reasoning, which it uses to resolve one meaning out of many.  It has structural backtrack, so it can build some structure hypothetically, examine the effect, then pull it apart and try something else, until it finds the meaning buried in the text.

 

In the process of building the knowledge structure, ARIA examines everything in minute detail – the relations, the prepositional chains, the defined terms, the internal and external references. This detailed inspection can find errors and inconsistencies in the grammar or the semantics, and at short or long range in the text.

 

Requirements for Automated Reading

Initial Knowledge

ARIA uses its knowledge about objects and relations to turn text into structure. That means it needs knowledge modelling about things in a new domain – an area of knowledge that is new to it. An effective way to do this is to involve ARIA in the Requirements Elicitation phase – as each new requirement is proposed, modelling for new relations is provided. This allows an incremental approach to building the knowledge, and allows stakeholders to see it grow and be comfortable with it, rather than a burst of modelling put into the system to handle the first draft of the complete specification.

 

Eliminating Ambiguity

One way of minimising ambiguity is not to allow several meanings for relations in the knowledge modelling. Too strict an adherence will probably fail – sometimes a verb will have two different meanings when used twice in the same sentence. It is preferable to model the meanings of a relation that are relevant to the particular knowledge domain, then provide modelling that selects a particular meaning, based on its subject, object or other context.

ARIA can show the specification developer where ambiguity exists in the structure – the developer can quickly eliminate these ambiguities and disseminate the knowledge structure to others, confident that they can now see exactly what is meant.

What About SysML?

 

OMG SysML is intended for modelling of requirements. Its genesis is different to that of ARIA – it came from a need to model computing processes, whereas ARIA came from a need to model complex projects. The connections between objects or activities in SysML are directed (they have arrows on them), which is inappropriate for describing requirements. If we take a simple statement of propositional logic

 

    If it is raining, the road is wet.

 

If the road is not wet, it is not raining. This is Modus Tollens – it is obvious to any human (without logical training – the mother tells the small child  “If you are good, I will give you a lolly” and the child replies “I don’t want a lolly”, fully aware of the effect of negating the consequent), and yet something so basic is beyond the grasp of SysML. With even propositional logic closed to it, SysML cannot support more complex logics – the person must do that. While initially alluring, in that it suggests that all the logic of a specification can be laid out in a diagrammatic form, the result is that the human, after spending days in creating a static directed structure, must still support in their head all the concepts the directed structure cannot describe. The difference between SysML and the active structure of ARIA is exemplified in the implication operator – if the operator waits to see which are its inputs, then we have Modus Tollens.

 

 

The structure in ARIA has far more state information than the structure in SysML, allowing ARIA to control its own phasing.. That is, SysML is a modelling language for a simple sequential program, not useful for systems which do not map to a program, but instead contain autonomously active elements, such as people, or alternatives that must be decided in the field. A similar situation, of connections which are uncommitted to being input or output,  occurs in any constraint reasoning problem – constraint reasoning is a good metaphor for design, with possibilities flowing backwards and forwards in all directions at many levels, connections switching between being inputs or outputs, objects and relations switching between existing and not existing (structure switched to not existing is not the same as negation of existence – the relation in “He can’t swim” has its existence negated, but switching the statement to not existing makes the statement itself “disappear”, as in “section 3.2 is null and void if…”). The definition of requirements precedes the design phase, so making the requirements structure static and directed (where it need not be) would seem a severe conceptual error.

Some requirements are constraints on what can be constructed, taking us far beyond the static structure of SysML. In ARIA’s active structure, states move through the structure, but the directions are transient and are calculated by the operators in the structure, not imposed on it from without. Operators in the structure can also build new structure, providing a dynamicity of approach to match dynamic problems of command and control.