From: Andrew Gabb (agabb@tpgi.com.au)
Date: Tue Dec 16 2003 - 13:08:02 EST
Rajneesh wrote:
> This 3 step process is very helpful for any Requirement Engg. Professionals
> , Though the output of step 3 format (template) is readily available , Can
> anybody suggest a template for concept of operations (ConOps). since as an
> Requirement Engineer If I expect the users to document it , They must be
> provided with some form of standard template , otherwise it will be a story
> telling !
Yes, you do need a template for a ConOps/OCD (the terms are used somewhat indiscrimately in different areas). The 3 generally available guides/standards are as follows:
IEEE Std 1362-1998 Guide for Information Technology – System Definition – Concept of Operations Document.
DI-IPSC-81430 - Operational Concept Description, December 1994 [MIL-STD-498]. ANSI/AIAA G-043-1992 Guide for the Preparation of Operational Concept Documents, January 1993 [NASA].
Although these are similar in intent and content, they tend to be quite different in structure and advice. Unfortunately, they also tend to be easy to misinterpret and somewhat poorly written and structured. The MIL-STD-498 DID is the only one which is 'free' and is the least detailed and least useful (but hey, a start's a start). I can provide a copy if needed.
Neither of the IEEE and AIAA standards are close to optimal (IMNSHO), and I strongly recommend reading both to get a real feel for the subject. Also check out the various advice on conops/OCDs in my papers on the subject at http://www1.tpgi.com.au/users/agabb/
I am currently one of those working on a major revision of the AIAA guide, but progress is slow, so don't hold your breath.
Typical contents are as follows (the bulk is usually in sections 6-7):
1 Scope 2 Referenced documents 3 Background 4 Current situation 5 Required changes 6 Proposed capability 7 Operational scenarios 8 Support concept and scenarios 9 Impact summary 10 Analysis of proposed capability 11 Verification & validation
One final issue which needs to be understood before getting into this area: OCDs can be written for various purposes including during the initial RE process (what I call Front-End OCDs), ie what is being discussed here. However, OCDs have (more?) commonly been used for showing how a system design will meet the users' needs - as a form of early validation - and all three are written with this primary viewpoint (although they expressly allow other purposes).
I think we've a long way to go before we have really good guides and templates for OCDs, particularly Front-End OCDs, but that doesn't stop anyone from lashing together something useful from one or more of the above standards. This stuff is not rocket science, and is nowhere near the complexity of eg software development processes.
The sophistication lies in issues such as what activities you describe, how you describe them, the number of scenarios you include, and how much detail to include. Note that most engineers will have serious difficulties in writing a good OCD, because the *style* is quite different from what they're used to.
Andrew
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Mon Dec 22 2003 - 09:00:14 EST