A CAPABILITY OVERVIEW

  

                  Contents

 

                                              

 

1        Introduction to Information System Architects Ltd                                            

2        Key ISA Products                                                                                               

3        The Importance of Requirements Documents                                    

4        The Penalties of Ignoring Requirements Engineering                  

5        Why Choose ISA?                                                                                             

6        ISA Track Record                                                                                              

7        How ISA Can Help a Project                                                                       

7.1      G-MARC Training & Licences                                                                

7.2      Requirements Engineering Consultancy                                                            

7.3      Requirements Warehousing

7.4      Additional Benefits                                                                                                                                   

7.4.1      -             Generic Requirements                                                                 

7.4.2      -             Behaviour Modelling                                                                    

7.5      Specific Benefits to The Supplier                                                                            

 7.5.1     -             Competitive Advantage                                                              

 7.5.2     -             Risk Reduction                                                                                  

 7.5.3     -             Smart Procurement                                                                        

7.6            Are There Any Risks?

7.7          A Sense of Perspective                                                                                                   

8        The G-MARC Methodology & Supporting Tool-set                    

8.1      Pedigree                                                                                                                                      

8.2      Process                                                                                                                                        

8.3      Benefits                                                                                                                                       

9        A Few G-MARC Applications                                                                   

10     Scope of ISA Capability                                                                                

11             Contact Details

          

 

 

----------||----------

 

 

 

1        INTRODUCTION TO INFORMATION SYSTEM ARCHITECTS (ISA)

 

ISA 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 40 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 – “G-MARC”.

 

G-MARC is capable of being applied to the specification of any kind of system.

 

 

              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.  The information engineer is provided with a sound methodology and is supported by powerful software with appropriate functionality.  The information engineer’s ‘toolkit’ includes 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.  However its introduction, at the very beginning of every project, enables it to provide the greatest contribution to project success.

 

2        KEY ISA PRODUCTS

 

-                                  RE Consultancy Services

-                                  Requirements Warehousing Services

-                                  The G-MARC RE Methodology/Tool Set

-                                  The provision of RE Training

-                                  Generic Requirements Knowledge Bases.

 

These products and their benefits are described in more detail below.

 

 

 

3        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.

 

 

              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 Statement Of Requirements (SOR) of measurable quality – a feature unique to G-MARC.

 

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

 

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

 

Applying only conventional Requirements Capture and/or Requirements Management techniques to a SOR of un-quantified quality results in a significant and un-quantified risk to the realization of any project.

 

 

 

4        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.

 

Anyone who thinks that such things will never happen to them should read the CHAOS report by the US Standish Group; see:

http://www.informeng.com/documents/CHAOS.htm

 

The probability of failure rises rapidly with the number of subjective requirements.  It is easy to show that the probability of developing a correct solution to a specification that embodies at least 200 subjective requirements is less than the reciprocal of the number of elementary particles in the known universe!  Very few conventionally produced specifications are free from subjectivity and all too many are entirely subjective.

 

 

 

5        WHY CHOOSE ISA?

 

The G-MARC software and methodology were realized some 30 years ago by ISA.  Since that time ISA has gained extensive experience in its application and can provide either:

-            licenses and training for projects to  use the G-MARC methodology/toolset (OPTION A), for those organizations who wish to acquire their own capability.

or

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

 

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

 

6        ISA TRACK RECORD

 

ISA has a proven track record of successful RE supporting procurement work across all sectors (see list at the end of this document).  In particular some of the largest UK Defence projects ever undertaken have used G-MARC. 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) applied Option B successfully to Naval Engineering Standard (NES 45) and to the extraction of a body of requirements from an ILS manual use study. The DLO also sponsored the application of Option B to Naval Manning Rules in conjunction with the Naval Manning Agency.  This comprehensive contract employed every one of the G-MARC phases of Requirements engineering, starting with data capture and audit and ending with full behavioural modeling of the functional aspects of the manning process.    The Future Offensive Air System (FOAS) and the UK Military Flying Training System projects also chose to use G-MARC to audit their URD documents and to further develop their User Requirements.  The ASTOR (Advanced Stand Off Radar) project chose G-MARC to re-engineer a URD from an existing system specification.

In an independent survey and trial of tools claiming RE functionality, conducted by the Ministry of Defence (MOD) in 1997, G-MARC 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].

 

7        HOW ISA CAN HELP A PROJECT

 

7.1    Training & G-MARC 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.

 

7.2    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 (i.e. the underlying requirements content), leaving the professional Requirements Engineer to apply the RE discipline.  The overhead to ISA 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.

 

7.3    Requirements Warehousing

 

If used in-house, any requirements handling tool will impose a training and maintenance overhead on project staff.  Recognizing this, ISA can maintain your project’s G-MARC database for you, at very low cost, providing electronic copies of G-MARC reports and/or base-line versions of your database, complete with quality metrics, to you and/or your stakeholders whenever you require.  Such data can be supplied either by mail or via the internet, as required and according to the sensitivity of the material.  This will again release your project staff to concentrate on requirements content, rather than (this time) on database construction and maintenance that do not directly add value to your project.  ISA’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.

 

Illustrative planning costs for a SOR to be maintained in a G-MARC database by ISA 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 off-site consultancy support per calendar month[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.

 

7.4    Additional Benefits

 

7.4.1  Generic Requirements Modelling

 

It is usually the case that at least 70% of the requirements statements in any SOR are generic within that application domain (e.g. warships, communications or information systems).  G-MARC encourages the identification of these generic aspects 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 that 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.

 

7.4.2  Behaviour Modelling

 

G-MARC provides the ability to conduct behavior 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.

This type of modelling provides the client with strong confirmation of specification validity.

 

 

7.5    Specific Benefits to The Supplier

 

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

 

7.5.1               Competitive Advantage

Bid Preparation

Using G-MARC 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.

 

 

7.5.2               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

Behavior 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.

 

 

7.5.3               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

G-MARC 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

G-MARC 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 can 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 supplier are at least as great as those to the customer.

 

 

 

7.6    Are There Any Risks?

 

Yes!  If you don’t know how good your requirements are 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!

 

The G-MARC 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.


The G-MARC staged approach allows the level of benefit obtained from the RE process to be tailored to project needs.  Furthermore, since the benefit and cost are cumulative, no extra cost premium is incurred by adopting a low-risk “stage-at-a-time” strategy.

 

Since the “Subjectivity” metric is obtained from the first stage, it is possible to contract only for stage 1 initially.  The metric so gained would then inform any subsequent decisions on whether to take the process further. 

 

 

 

7.7    A Sense of Perspective

 

For any development project, the cost of fully engineering the User Requirement Document is typically less than 1% of the overall project cost, yet this activity can yield saving factors of 106 for effort put in on developing the requirement[4].

 


----------||----------

 

 

 

8        THE G-MARC METHODOLOGY AND SUPPORTING TOOL-SET

 


8.1    Pedigree

 

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, were all originated by ISA’s associate company Computer System Architects  (CSA)[5].

In total, more than 40 elapsed years of in-depth experience (involving several hundred man years of effort) have been devoted to the development of G-MARC and, to date, on every project where 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 un-testable collection of narrative sentences, to a fully structured, precisely defined and objectively testable set of atomic requirements.

 

8.2    Process

 

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 a body of ad hoc (unstructured) requirements, either via prompted interviews, workshops or from documents, the first sequence of G-MARC activities is referred to as ‘data cleansing’. This sequence of activities leads to the development of a set of regularized, tentatively objective, atomic requirements.  Note that it is important that each atomic requirement is then made fully objective by attaching a clear acceptance test to each one.  This process confirms the atomic requirements as being semantically comprehensible.  If it is not possible to identify an acceptance test for a requirement then the item of information concerned must be regarded as semantically incomprehensible and, as such, 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.

Following the above sequence of activities, the body of atomic requirements is then allocated to a multi-dimensional classification matrix. This matrix facilitates the ability of anyone to examine the coverage of any aspect of the subject matter by the number and type of atomic requirements and from any viewpoint at any specified level of detail.

Each cell in the classification matrix may contain one or more groups of requirements dependent on level of detail. These groups are assigned names - according to their content - and, having been thus identified, these groups of objective and atomic requirements are then analyzed to develop appropriate hierarchical structures.  By virtue of the massive increase in visibility introduced by this Structuring activity, the risk of repeat activities due to successive waves of revision is significantly reduced.

G-MARC 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).

 

 

8.3    Benefits

 

A major benefit that derives from using the G-MARC methodology is the access to a variety of metrics for measuring specification quality during 'cleansing'.  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 can be used generically to assist the development of other specifications.  The classification matrix can 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 sub-assemblies 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 that also varies in time in an unknown manner.

 

 


9        A FEW G-MARC APPLICATIONS

 

The following illustrates a sample of the projects to which G-MARC has 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    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    The requirements for a VLF (Very Low Frequency) communications system for the MOD, Portsdown, Hampshire.

O    Development of the User Requirements Document (URD) for the Future Integrated Soldier Technology (FIST) project for the UK Army.

O    Re-engineering and dynamic modelling of the specification of manning requirements for the Naval Manning Agency, Portsmouth, Hampshire.

O    Development of the key User Requirements for the UK Military Flying Training System (UKMFTS) for the Defence Procurement Agency (DPA), Abbey Wood, Filton.

O    The reverse engineering of a URD from a system specification of the ASTOR (Advanced Stand Off  Radar) project for the DPA, Abbey Wood, Filton.

O    Subjectivity audit of the URD and SRD for the T45 Destroyer for the DPA, Abbey Wood, Filton.

O    The development and behavioral 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 Advanced Weapons Effect Simulator 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 DPA, 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    The specification of a generic Integrated Logistic Support System for the Warship Support Agency (WSA), Foxhill, Bath.

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

O    Development of the specification for the Future Wheeled Recovery Vehicle (FWRV) for the DPA, Abbey Wood, Filton.

O    Development of a specification for the Joint Insensitive Munitions Steering Group, MOD, Abbey Wood, Filton.

O    The development of an international specification for information interchange (AP233) on behalf of  the Warship Support Agency, Foxhill, Bath.

O    Re-engineering of a draft specification for the Network Management Centre for the west coast modernization system for Railtrack, London.

O    Development of the User Requirements for the Shared Working Environment of the Future Offensive Air System (FOAS) for the DPA, Abbey Wood, Filton.

O    Audit and re-engineering of the User Requirements for a further development of the Nimrod airborne reconnaissance system – project HELIX.

O    Audit and re-engineering of the User Requirements for a Digital Diagnostic and Repair system for the UK Defence Logistics Organisation.

O    Development from scratch of the User Requirements for the CBRN project at the DPA, Abbey Wood, Filton.

O    Audit and re-engineering of the User Requirements for a corporate Electronic Document Viewing system for the UK Defence Logistics Organisation.

 

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

 

 

 

10    OTHER TYPES OF PROJECT

 

The following list indicates other types of project for which ISA staff has been responsible in the past, the experience from which has contributed to the development of G-MARC:

o                    TSR2 – The specification, design and implementation of the in-flight autopilot for a UK Tactical Strike and Reconnaissance aircraft, for the British Aircraft Corporation (BAC), Weybridge, Surrey.

o                    Vigilant - Mathematical modelling and design of the flight control and guidance computing systems, for the wire guided, Vigilant anti‑tank missile for the BAC.

o                    Blue Steel - Design of solid-state telemetry systems for the development program and flight trials of the Blue Steel air‑to‑ground stand‑off missile, for the BAC.

o                    Development of remote process control and monitoring systems for heavy industrial plant (including chemical by‑products), for British Steel.

o                    Mathematical modelling, design and implementation of the semi‑active homing systems used in the radar beam riding missiles Sea‑Slug, for the Sperry Gyroscope Co.

o                    Specification, design and implementation of the Sea Dart beam riding missile, for the Sperry Gyroscope Co.

o                    Research - Design of self‑adaptive target seeking control systems immersed in an environment contaminated by radar jitter, noise and target glint effects, for the Sperry Gyroscope Co.

o                    Design & development of the SPERRY 1412 digital computer, for the Sperry Gyroscope Co.

o                    BAC 1-11 – Specification, Design and implementation of the in-flight autopilot, auto‑approach, glideslope, autoflare and auto‑land systems, for Elliot Automation.

o                    VC 10 – Specification, Design and implementation of the in-flight autopilot, auto‑approach, glideslope, autoflare and auto‑land systems, for Elliot Automation.

o                    Concorde – Specification, Design and implementation of the in-flight auto autopilot, auto‑approach, glideslope, autoflare and auto‑land systems, for Elliot Automation.

o                    Design and development of general-purpose information retrieval packages FIND (tape based, serial search version) and PRIOR (disc based, random access version) with interactive communications languages, for ICL.

o                    Design and production of interactive data capture and database handling systems for the remote on‑line recording of the Divisional Level War Game, for the MoD at Fort Halstead.

o                    Development of a fingerprint recognition system, for the Home Office.

o                    Design and implementation of the Satellite Check‑out and Test (SCHAT) real time language and associated database, for the European Space Technology Centre, Holland.

o                    Design and production of a real‑time Interrupt Director and a general purpose Factory Fault Simulator package that was used to check out system hardware and software, for the textile industry.

o                    Specification and design of a very low power consumption, highly reliable, data logging sub‑system, radio communications link and data analysis sub‑system for an unattended, oceanic, data gathering buoy, for GEC.

o                    Design of an On‑Line/Real Time system to aid computation and payment of Sickness and Injury Benefits via a communications network linking over 500 local offices throughout the UK, for the DHSS.

o                    Design of the country‑wide interactive communications network for project CRISP, for the MoD, Bath.

o                    Study and definition of a new and cost effective approach to the proving and maintenance of Real Time software for both Air Defence and Avionics systems, via total synthetic representation, for the MoD.

o                    Design study for a new generation of computerised photo- typesetting systems, for a major Fleet Street company.

o                    Design study for a low-cost, highly reliable, multi-processor microcomputer intended, initially, for packet switching network applications, for the NPL.

o                    Study of the communications and processing loads in a proposed, national packet switching network in order that an appropriate computer centre strategy could be devised, for British Steel.

o                    Design of an on‑line information retrieval system that was destined to go live, at Heathrow Airport, for the British Airports Authority.

o                    Design and implementation of the software and database structures for a new, highly time critical, ship-borne, EW system and the selection and justification of the associated computer – project Isabel/Morthoe – for the MoD.

o                    Study of the required computer network architecture and facilities to control beer production at a new Heineken plant at Zoeterwoude, near Leiden, Holland.

o                    Design & development of a new approach to the structuring of real time software for Stored Program Controlled (SPC) telephone exchanges and of the associated special purpose digital computers, for Bell Telephone Manufacturing, Antwerp, Belgium.

o                    Design and implementation of a complete road traffic automation communication system, for the Belgian government.

o                    Design and implementation of the software of the complete sonar sensor and weapons control system for the submarine project SEA DRAGON, for the Dutch navy.

o                    Definition, design, and implementation of a methodology for the production of C3I simulators for naval combat situations, for the UK Admiralty Surface Weapons Establishment, Portsmouth,

 



----------||----------


 

 

 

 

10   SCOPE OF ISA CAPABILITY

 

The full spectrum of ISA’s capability encompasses the application sectors of Science & Engineering, Commercial & Financial and Defence.

The dramatic effectiveness of the methodology that ISA has developed to support its consultancy activities is entirely due to a unique juxtaposition of intense need, wide ranging experience, specialist skills and the coincident availability of support from the UK Government’s Department of Trade & Industry, The UK Ministry of Defence and the UK Civil Aviation Authority.  It is unlikely that the opportunity to develop such a fertile juxtaposition would have arisen in a large organization:

                                                           “…large organizations …are more inclined to kill off new ideas than encourage them”.

                                                                                               -  John Buckley, Institute of Directors’ Guide to Innovation.


In addition to the benefits that ISA clients derive from the application of its unique methodology, the quality of ISA’s work on behalf of its clients is further enhanced by virtue of ISA’s policy of employing only seasoned professionals to perform requirements engineering.  All ISA consultants are academically qualified to at least first degree level and many have MSc and/or PhD level qualifications as well as more than 20 years of professional experience in their chosen discipline.

 

 

 

 

 

11    WHOM DO I CONTACT FOR MORE INFORMATION?

 

 

All enquiries should be directed to:

 

The Marketing Manager, Information System Architects Ltd.:               E-mail: ISA@InformEng.com

 

                                               ----------||----------

 

 



[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