The G-MARC methodology has a substantial pedigree.  Commonly accepted concepts such as:

-           Atomic requirements,

-           Objective requirements,

-           Separating User requirements from System requirements,

-           Separating goals from constraints,

-           Requirements Modelling,

and many more, are all G-MARC originated[1].

In total, more than 50 elapsed years of in-depth experience (involving several hundred man years of effort) have been invested overall in the development of G-MARC.  No one should entertain the possibility of developing a viable methodology on the back of a single project - especially when the need to verify its effectiveness needs to be included before it is used in anger.  To date and for every project upon which G-MARC has been used, the customer has expressed considerable satisfaction at the results achieved.

G-MARC is unique.  It is unique in terms of the wide range of capabilities that it brings to bear when engineering quality into a requirement specification and it is also unique in terms of its effectiveness when introducing structure into a specification.

No other known methodology or tool provides its users with the ability to objectively measure the quality of a specification as it progressively evolves from an unstructured, subjective and nearly always untestable collection of narrative statements, to a fully structured, precisely defined and objectively testable set of atomic requirements.




The G-MARC methodology continues to be developed.  It is supported by a clearly defined, mature and robust, suite of application software that, in turn, is supported by a comprehensive suite of Microsoft foundation software.

Having captured an initial body of ad hoc (unstructured) information, either via prompted interviews, workshops or from documents, the first sequence of G-MARC activities is referred to as 'Reduction'. This sequence of activities leads to the development of a (tentative) set of objectively testable, atomic requirements.  Note that it is important that each atomic requirement be objectively testable. If it is not possible to identify an acceptance test for a requirement then the item of information concerned cannot really be regarded as a requirement.  This is a fundamental principle that has been subscribed to by the International Standards Organization [ISO] for many years.

The body of atomic requirements that is produced by the G-MARC 'Reduction' process is allocated to a multi-dimensional classification matrix. This matrix facilitates the ability of anyone to view the coverage of the subject matter by the number and type of atomic requirements.

Each cell in the matrix may contain one or more groups of requirements. These groups are assigned names - according to their content - and, having been thus identified, these groups of objective and atomic requirements are then analysed to develop appropriate hierarchical structures.  Ideally, this Application structuring should always be provided with the best possible input as this reduces the risk of having to repeat activities due to successive waves of revision.

The G-MARC Requirements Engineering methodology uses the hierarchical structures and framework to identify and rectify:

-        bias in the type and number of requirements against technical (or stakeholder) area;

-        unjustified (orphan) requirements;

-        incompleteness (such as missing requirements as indicated by gaps in the framework);

-        inconsistency (contradiction);

-        redundancy (duplicate requirements);

-        incorrectness (functions which do not operate together as expected);

-        incoherence (requirements expressed at differing levels of detail within a single group).





A major benefit that derives from using the G-MARC methodology is the access to a variety of metrics for measuring specification quality during 'Reduction'.  This is vital when wishing to know whether the quality is improving (or not) as development proceeds.

A further major G-MARC benefit is the fact that G-MARC derived structural information is able to be used generically to assist the development of other specifications.  The classification matrix is able to be rapidly evolved into a structural standard for all specifications in a given area thus drawing attention to, and capitalizing on, commonality across systems.

The structural framework can be used by the G-MARC tool-set for behavior modelling, testing and development of operational scenarios in those situations where it is considered desirable to do so.

The structural framework can also be used to accumulate such things as typical cost and time for each requirement and/or group of requirements.  Using this type of capability the G-MARC User is able to produce rapid estimates of likely implementation costs and timescales for an entire proposed system or for any combination of any set of subassemblies within such a system.  These capabilities apply equally well to the development of Business requirements as they do to System requirements

Application of all of the above capability progressively improves the overall quality of, confidence in and value of the specification.  This, in turn, leads to a clearer record of the impact of the various families of goals and constraints on any resulting system.  This, in turn, facilitates the ability to easily modify the system without risk and in full knowledge of the implications.

Finally, basing an Invitation to Tender (ITT) on a specification produced using G-MARC provides an opportunity to objectively evaluate competing proposed solutions on a level footing rather than use the typical, highly subjective evaluation process based upon the opinions of a review board (this is because the structure and full modelling described above are axiomatic to the quantitative assessment of any complex system description, be it in the form of a SOR or a design).  Review Board opinions, even if they come from the best experts, inevitably evolve during the course of evaluating a series of tenders.  This results in a subjective evaluation process which also varies in time in an unknown manner.

Previous Page     Next Page      Contents List


 [1] These assertions can be readily confirmed by reference to the final report of the UK Department of Trade & Industry [DTI], Information Engineering Directorate's project ref. No. IED4/1/1151.  This project was originally submitted by CSA to the DTI for consideration, in 1988. The project was subsequently awarded to CSA and was completed in 1992 in Collaboration with the Civil Aviation Authority [CAA], The National Engineering Research Council [NERC], King's College - London University, the City University and the Ministry of Defence. The work was based on a code of practice that ISA had been developing in-house since1980