CSA BROCHURE

Introduction to Computer System Architects (CSA)

CSA is a specialist consultancy company whose core competence is the minimization of project risk by means of Requirements Engineering (RE). This competence is derived from more than 25 years of cutting-edge experience in the field, including the development of the world’s first (and still the only) true RE methodology and supporting software tool set – “GMARC”.

GMARC is capable of being applied to any kind of specification.

What is RE?

Requirements Engineering is here defined as:

The process of ensuring measurable quality of the information in all specification related documentation throughout the life of the associated project with the objective of reducing downstream risk.

RE involves the methodical application of scientific techniques to improve the quality of a specification[1]. It is based upon the principles of information engineering, which requires considerable skill and experience to be applied. It is a vitally important, intellectually demanding and painstaking activity which progressively reveals the real nature of a specification as it demands the answers to ever more penetrating questions. For almost all but the most elementary specifications, the information engineer needs to be able to apply a sound methodology and be supported by powerful software with appropriate functionality. The information engineer’s ‘toolkit’ must include meaningful metrics to enable the measurement of quality and to monitor both the direction and size of any improvement.

In the above respects, RE is no different from any other engineering discipline.

Key CSA Products

- RE Consultancy Services

- Requirements Warehousing Services

- The GMARC RE Methodology/Tool Set

- The provision of RE Training

- Generic Requirements Knowledge Bases

These products and their benefits are described in more detail below on pages 3-5.

How does RE fit in with other Requirements Handling activities?

Requirements Engineering belongs to a trinity of requirements handling capabilities:

Requirements Capture extracts and records raw requirements information from documents or from the minds of subject matter experts.

Requirements Engineering translates raw requirements information into a complete, correct, coherent and consistent quality-assured Statement Of Requirements (SOR).

Requirements Management provides traceability and change management facilities for the SOR throughout the project life-cycle.

Applying a logical combination of Requirements Capture, Engineering and Management will significantly reduce project risk throughout the project life-cycle.

Applying only Requirements Capture and/or Requirements Management techniques to a SOR of unquantified quality results in a significant and unquantified risk to the ability of a project to deliver that for which it has been created.

The Importance of Requirements Documents

The Statement of Requirements (SOR) drives all project activities………

…and dictates the content of all technical documents, such as the system design, build specification, test specification and support plan. Project managers rightly apply engineering disciplines (design engineering, production engineering, test engineering and logistics engineering) to assure themselves of the quality of the associated technical documents, so they surely ought to apply an equally rigorous discipline (Requirements Engineering) to get a similar level of quality assurance to the source of all technical documents – the SOR.

The Penalties of Ignoring RE

These are many and varied and derive mainly from a poor understanding of the real requirement and a lack of confidence-building metrics. Typical results are:

- Failure to gain project approvals.

- Failure to negotiate contracts.

- Cost overruns.

- Time overruns.

- Performance failures.

- Poor initial support arrangements.

- Poor in-service support decisions.

Why Choose CSA?

The GMARC software and methodology were realised some 14 years ago by CSA. Since that time CSA has gained extensive experience in its application and can provide either:

- licences and training for projects to use the GMARC methodology/toolset (OPTION A), for those organisations who wish to acquire their own capability,

- a comprehensive RE service comprising RE consultancy support to project staff, and operation of GMARC on the project’s behalf (OPTION B).

The GMARC software toolset and associated RE methodology were first copyrighted in 1992 by CSA, preventing unauthorized use of the toolset or the methodology. To date a number of consultancy companies and major system organizations have acquired GMARC licences and now have formally trained consultants with the necessary skills to understand and apply the GMARC methodology/toolset

CSA Track Record

CSA has a proven track record of successful RE supporting procurement work across all sectors (see list at page 9 of this document). In particular some of the largest UK Defence projects ever undertaken have used GMARC. Project LARONE and the Type 45 Destroyer both chose Option A (see next column) whilst the Future Infantry Soldier Technology (FIST) & the Future Wheeled Recovery Vehicle (FWRV) both chose Option B. The Defence Logistics Organization (DLO) have also applied Option B successfully to Naval Engineering Standard (NES 45) and have recently sponsored the application of Option B to Naval Manning Rules in conjunction with the Naval Manning Agency. The Future Offensive Air System (FOAS) and the UK Military Flying Training System projects have also recently chosen to use GMARC to audit their URD documents and to develop their Key User Requirements. In an independent survey and trial of tools claiming RE functionality, conducted by the Ministry of Defence (MOD) in 1997, the CSA/GMARC combination was judged to be the only option which added value to the requirements process. This view can be found expressed in the MOD’s written guidance to projects under the Smart Requirements initiative[2].

How CSA Can Help a Project

Training & GMARC Licences

For large, complex projects with plenty of time to develop the requirement, a case can be made for training full-time project staff in the discipline of RE and for acquiring the necessary methodology/software toolset for internal use (OPTION A). This is especially true if it is intended that the same staff will eventually carry out the RE function for a succession of similar projects. The investment of project staff time is not trivial, but the payback in long term cost savings for the RE activity might well justify choosing this option.

R E Consultancy

For the smaller project (or for specific tasks within a large project), where timescales may be shorter or the payback for deep training of project staff would not justify the outlay, the employment of suitably skilled consultants would prove far more cost-effective. Such consultants may be co-opted to the project for a finite period, working locally and providing “on-line” support (OPTION B1), or working away from the project and meeting with full time project team members only on formally planned occasions (OPTION B2). Both of these options release hard-pressed project staff to concentrate on their own areas of expertise (ie the underlying requirements content), leaving the professional Requirements Engineer to apply the RE discipline. The overhead to CSA of such activity is marginal, and hence the cost to the project is much lower than trying to do it alone, not to mention the improved results from employing the right people for the right jobs. It should be emphasized that, just as the project needs Requirements Engineering to ensure the quality of its SOR, so the Requirements Engineer needs the project’s Subject Matter Experts (SMEs) to help to understand what the customer really needs. The whole process depends on a close working partnership between the Requirements Engineer and the appropriate SMEs, with both sides contributing equally to a successful outcome. There really are no alternatives – both skills are too demanding. SMEs do not make good Requirements Engineers and Requirements Engineers cannot be knowledgeable in all application areas.

Requirements Warehousing

If used in-house, any requirements handling tool will impose a training and maintenance overhead on project staff. Recognizing this, CSA can maintain your project’s GMARC database for you, at very low cost, providing base-line versions, complete with quality metrics, to your stakeholders whenever you require. This will again release your project staff to concentrate on requirements content, rather than (this time) database construction and maintenance which do not directly add value to your project. CSA’s costs for this extra service, which we call “Requirements Warehousing” (RW), are relatively small since they are entirely marginal in a company whose core activity is RE and, in addition, such service incurs no licence fees.

Illustrative planning costs for a SOR to be maintained in a GMARC database by CSA are equivalent to one man day per calendar month. This price would not vary with the number of requirements and it provides up to 8 hrs of free CSA consultancy support made available to client staff while at CSA premises[3]. Experience across many projects has shown this to be a highly effective and efficient way of working and the MoD has taken the concept into its comprehensive requirements handling strategy.

URD: Base-lined versions of the User Requirements Document (URD) are issued as the document is developed by the IPT, drawing initially on the generic requirements set developed against other systems. Each base-lined version is audited for quality, using GMARC, before issue to prove that the URD is continually improving and to identify aspects requiring further work. No internal project team effort will be spent on GMARC database maintenance – instead, CSA will “warehouse” the URD on behalf of the project team.

SRD: Where competing commercial consortia develop separate System Requirements Documents (SRDs) concurrently, the project team will develop an evaluation module to assess and compare the consortia proposals objectively. Part of this module will contain those System Requirements, identified during URD construction, about which the IPT needs to make specific statements.

Additional Benefits

Generic Requirements

It is usually the case that at least 70% of the requirements statements in any SOR are generic within that application domain (eg warships, communications or information systems). GMARC encourages the identification of these and they can be made available to your project. This, in turn, facilitates:

- Concentration of your effort on what makes your project unique.

- Identification of the more Generic Requirements, useable by other projects, at no extra cost or effort.

- Identification of sub-domains which allow sub-systems to be managed separately whilst still retaining links with main system and “systems of systems”.

This form of modelling is the current ultimate in specification verification capability.

Behaviour Modelling

GMARC allows behaviour modelling of the requirement, at any level of abstraction. This facilitates:

- Trade-off analysis between different areas of the SOR – including the business model.

- Multiple Systems Modelling.

- Testing in Synthetic Environments.

Specific Benefits to Industry

Industry can capitalize on all the benefits mentioned so far, but there are some specific areas that are especially relevant as follows:

Competitive Advantage

Bid Preparation

Using GMARC to analyze and fully understand the customer’s SOR is vital in Bid Preparation.

Innovation/Continuous Improvement

Being “first-to-market” with a Requirements Engineering capability is one of the critical success factors of Smart Requirements.

Risk Reduction

Quality Assurance

Comprehensive and objective metrics provide management confidence with improving quality and give timely warnings if/when quality worsens due to changes.

Right First Time

Behaviour modelling of the engineered requirement will show whether the system, if built to specification, will work in the way intended. This provides confidence that the system can be built on time, within budget and meeting performance.

Smart Procurement

Using same approach as customer

As more and more projects adopt RE as part of their requirements handling strategy it makes sense to use the same methodology and metrics to mutual benefit.

Enterprise Integration

GMARC Modelling produces Data Flow Diagrams (DFDs) that facilitate sub-system isolation and system integration. These DFDs also facilitate the writing of information interchange specifications and hence the management of product information in a Shared Data Environment.

Impact analysis

GMARC DFDs allow the impact of various system architecture options to be assessed – including cases where existing (legacy) sub-systems are specified no matter where they appear in the product supply chain.

Audits

With a specification of measurable quality the task of the project/system auditor is made considerably easier. As a consequence, valuable (and scarce) auditor resources are able to be deployed to far greater effect.

***

All of the above can be achieved long before making any commitment to the design and/or build stages. Thus it can be seen that the potential benefits to the manufacturer are at least as great as those to the customer.

Are There Any Risks?

Yes! If you don’t know how good your requirement is, or how to improve it, how can you possibly expect to manage the resulting risks to the timeliness, cost and performance of the system it will produce? Having read this document, this is the risk you will knowingly incur if you make no effort to measure the quality of your SOR! The risks of not applying RE (‘head in the sand’ policy) are unacceptable!

CSA’s Staged Approach to RE minimises your financial risk in adopting RE.

The GMARC methodology is applied to requirements information in a series of stages. Each stage builds on the work of the previous stage and confers increasing benefit as indicated in the table of progressive stages of benefit below:

Pedigree

The GMARC 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 GMARC originated[5].

In total, more than 40 elapsed years of in-depth experience (involving several hundred man years of effort) went into the original development of GMARC and, to date, on every project where GMARC has been used, the customer has expressed considerable satisfaction at the results achieved.

GMARC 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 the specification as it progressively evolves from an unstructured, subjective and nearly always untestable collection of narrative sentences, to a fully structured, precisely defined and objectively testable set of atomic requirements.

Process

The GMARC 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 a body of ad hoc (unstructured) information, either via prompted interviews, workshops or from documents, the first sequence of GMARC 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 GMARC '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 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 GMARC 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).

Benefits

A major benefit that derives from using the GMARC 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 GMARC benefit is the fact that GMARC-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 GMARC tool-set for behaviour 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 GMARC 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 GMARC 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). Such 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.

A Few GMARC Applications

The following illustrates a sample of the projects to which GMARC has recently been applied in order to improve the quality of the requirement specification aspects of the work:

o Project FOCSLE - outline specification for a global communication system for the Ministry of Defence (MOD), Portsmouth.

o The Multi-Launch Rocket System (MLRS) project specification for the Defence Research Agency, Fort Halstead, Kent.

o A quality audit of a proposed requirements engineering methodology developed for the Future Offensive Air System (FOAS) project for the Defence Evaluation Research Agency (DERA).

o The Spot 5 satellite-ground segment communications system specification for the National Remote Sensing Centre at Farnborough, Hampshire.

o The Army logistics system LOCPRES specification for Data Sciences Ltd, Farnborough, Hampshire.

o The AFCT army training system specification for Cray Defence Systems, Bristol.

o A European Space Technology Centre Satellite -ground segment communications system specification for Alcatel, Antwerp, Belgium.

o A Video UHF Transmitter specification for space ship communications for Alcatel, Antwerp, Belgium.

o The Pharos military Air Traffic Control System specification produced by the Royal Dutch Air Force, Holland.

o A statement of requirements for a VLF (Very Low Frequency) communications system for the MOD, Portsdown, Hampshire.

o The development of the URD for the Future Integrated Soldier Technology (FIST) project for the UK Army.

o The re-engineering and dynamic modelling of the specification of manning requirements for the Naval Manning Agency, Portsmouth, Hampshire.

o The development of the key User Requirements for the UK Military Flying Training System (UKMFTS) for the Defence Procurement Agency, Abbey Wood, Filton.

o The development of the URD for the Shared Data Environment of the Future Offensive Air System (FOAS) for the Defence Procurement Agency, Abbey Wood, Filton.

o The development and behavioural modeling of the URD for the Future Offensive Air System (FOAS) for the DPA, Abbey Wood, Filton.

o A Flight Simulator System specification for Thomson Training & Simulation, Crawley, Sussex.

o The AWES system specification for SAAB, Huskvarna, Sweden.

o The CVSG system specification for the MOD, Portsdown, Hampshire.

o The specification of an Area Defence Weapon (ADW) for British Aerospace, Stevenage.

o Software specification for a new satellite communications system for INMARSAT, London.

o Project Larone, the operational requirement for a wide area Naval communications system for the Defence Procurement Agency, Abbey Wood, Filton.

o The Staff Requirement for the Future Carrier on behalf of CNOCS, MOD, Portsdown, Hampshire.

o A customer billing system specification for Northern Electricity, Birmingham.

o A generic Integrated Logistic Support System for the Warship Support Agency, Foxhill, Bath.

o The re-engineering of Defence Standard 02-45 (Reliability Centred Maintenance) for the Head of Whole Life Support (Navy), Foxhill, Bath.

o The development of the specification for the Future Wheeled Recovery Vehicle (FWRV) for the Defence Procurement Agency, MOD, Abbey Wood, Filton.

o The development of a specification for the Joint Insensitive Munitions Steering Group, MOD, Abbey Wood, Filton.

o The re-engineering of a draft specification for the Network Management Centre for the west coast modernization system for Railtrack, London.

o The development of the key User Requirements for the Shared Working Environment of the Future Offensive Air System (FOAS) for the Defence Procurement Agency, Abbey Wood, Filton.

All the above, and many more, requirement specification activities have demonstrated the unique effectiveness of the CSA approach to requirements engineering using its proprietary methodology and support tool GMARC.

^[1] MOD “Guide to the Production of User Requirements Documents” Version 2 dated 19/06/2000

^[2] MOD “Guide to the Production of User Requirements Documents” Version 2 dated 19/06/2000

^[3] Further consultancy support is costed as required, plus travel and subsistence costs where appropriate.

^[4] International research into major project failures indicates that the cost of putting right an error undetected or uncorrected in one project phase will multiply ten-fold in the next.

[5] 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 CSA had been developing in-house since1980