Principles initially documented by De Marco, Yourdon, Booch, Jacobsen and Rumbauld support our systems analysis. Our strength lies in the ability to involve system originators and end users throughout. An object-oriented, suite of graphical analysis tools, coupled with a prototyping methodology supported by a development environment that facilitates Rapid Application Development, enable us to produce systems that more than meet users' expectations. We are able to provide specification in a range of formal notations, dependant upon customer preference. We are comfortable with the current eGif standards of UML and XML. The proof of our approach lies in the successful completion of the major projects listed elsewhere upon this site.

A Brief Summary of our Specification Methodology

"My sad conviction is that people can only agree about what they’re not really interested in" - Bertrand Russell

"An unbiased opinion is valueless" - Oscar Wilde

Standard system specification methodologies adopt a reductionist approach to identifying system components, based upon the assumption that the system in its entirety can be rebuilt from each of the separate component parts obtained by the analyst. Some moves have been made in order to accommodate aspects of open system theory, however, many failures of complex IT projects have been attributed to inappropriate system specification, despite the application of standard methodologies. Real world systems display behaviours resulting from the relationships between component parts, and such emergent properties cannot be identified by standard system description techniques.

Another major failing of ‘classical’ systems analysis is the lack of consideration for the wider environment within which the system operates. To this end, Checkland’s "Soft Systems Methodology" was devised. Checkland sought to consider a range of factors, including ‘weltanschauung’, a world view. Checkland’s methods are based on grounded theory and phenomenology.

Checkland’s methods are appreciated more by organisational managers than by systems engineers. They include extensive graphical representation of individual and group views of system issues and behaviour, however, cannot easily be translated into system specification.

Other major concerns include the interaction between the analyst and the individuals involved on an everyday basis with the system to be described. The ‘problem space’ of many methodologies is limited and can be further reduced by inappropriate analytical behaviour. The capacity for interaction between short and long term memory requires facilitation,and bias in the form of recency, concreteness, anchoring and intuitive statistical analysis must be anticipated.

A development cycle based on prototyping allows the specification to be revisited many times during the production phase and is a key component of our in-house approach, principles drawn from Gilb's evolutionary approach to software delivery.

Our system specification techniques include the effective elements of a number of documented methodologies, is graphically based and requires the input of a range of individuals of varied roles within the organisation, for a prolonged period of time. It will also allow for iteration, essential to accommodate the inevitable misunderstandings and revisions of documented behaviour.