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 defined 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 CSA of such activity is minimal, and hence the cost to the project is much lower than when 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.
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 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) database construction and maintenance which 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 Requirements Engineering.
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. 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 G-MARC, 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 G-MARC database maintenance – instead, ISA 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.
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 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.
G-MARC provides behavior modelling of the requirement, or system, 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.
Industry can capitalize on all the benefits mentioned so far, but there are some specific areas that are especially relevant as follows:
Using G-MARC to analyze and fully understand the customer’s SOR is vital in Bid Preparation.
Being “first-to-market” with a Requirements Engineering capability is one of the critical success factors of Smart Requirements.
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.
Using same approach as customer
As more and more projects recognize the importance of RE as part of their procurement strategy it makes sense to use the same methodology and metrics to mutual benefit.
G-MARC Modelling produces Data Flow Diagrams (DFDs) to 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.
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.
Initiating a project with a specification of measurable quality enables the task of the project/system auditor to be 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.
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!
ISA’s Staged Approach to RE minimises your financial risk in adopting RE.
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 progressively increasing benefits as indicated in the table below:
The G-MARC staged approach allows the level of benefit obtained from the RE process to be tailored to project needs. Furthermore, since the benefits and costs 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 then informs the subsequent decision on whether to take the process further.
For any development project, the cost of fully engineering the Requirements Documents is typically less than 1% of the overall project cost, yet this activity can yield saving factors of 106 for effort put in on the requirement.
 Further consultancy support is costed as required, plus travel and subsistence costs where appropriate.
 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.