The Business Need group of criteria aims at analysing and assessing to which extent the Business Need of an eGovernment project is covered when using a formal specification. In other terms, is the formal specification suitable? And what is its potential?
The suitability of a formal specification can be defined as the extent to which the formal specification responds to the identified business need in the specific context, and promotes interoperability. The requirements are weighted and classified in a series of mandatory ones ("yes/no") and optional ones. Suitability characteristics are analysed in terms of applicability and relevance with regard to how the requirements are met when using the formal specification.
The potential of a formal specification identifies the indirect consequences linked to the use of the formal specification, whether it is in terms of analysing and assessing the impact of its use, or evaluating its possible evolution.
Suitability
The suitability of a formal specification can be defined as the extent to which the formal specification responds to the identified need and promotes interoperability.
In order to assess suitability of a formal specification, its applicability needs to be validated; in other terms, applicability considers whether a thorough and clear description of the formal specification is identified - if this description provides the goal and scope of use (who should use it, and for what applications), as well as what is specified.
Once the applicability of the formal specification in clear, relevance of the formal specification is needed for obtaining suitability. Relevance is the extent to which the use of the formal specification meets the identified requirements; it identifies how the key features necessary to support the identified eGovernment functional need are covered. It is a measure of completeness, functionality-wise.
The suitability criteria also takes into account the degree to which the choice of this formal specification allows or enhances interoperability. This is done by assessing if the formal specification has been designed so as to take into account interoperability. Moreover, further investigations may be done in the scope of the Market Criteria assessment, such as identifying existing or planned mechanisms to assess the interoperability of different implementations of the same formal specification.
Finally, suitability of a formal specification for an eGovernment need takes into account, whenever possible, and in the scope of the identified business need, to which extent accessibility needs for people with disabilities or design for all users are included when designing the formal specification.
The ideas behind the Suitability criteria can also be expressed with the following questions:
Applicability
CAMSS 1: What is specified in the formal specification? Is it clear who should use the formal specification and for what applications?
Relevance
CAMSS 2: To which degree does the use of the formal specification help meet the identified requirements?
CAMSS 3: Does the formal specification cover the key features necessary to support the identified eGovernment functional need?
CAMSS 4: What is its completeness functionality-wise?
CAMSS 5: Has the formal specification been designed so as to take into account interoperability? What are the existing or planned mechanisms to assess the interoperability of different implementations to the formal specification? (In Market Criteria)
CAMSS 6: How does the formal specification take into account accessibility needs, if possible in the scope of the business need?
Potential
An additional analysis of the future outcomes and the indirect consequences of using a formal specification finalises the requirements assessment; the criteria associated to this analysis - grouped under the “potential” criteria – focus on the various aspects linked to the impact of the choice as well as to the possible evolution of the formal specification.
Assessing the impact of use means identifying the risks and opportunities in the direct environment of the business need and linked to the choice of that formal standard. This identification is a first stage, and an evaluation at a global level. It may be refined in a second stage with a similar analysis linked to the implementations of the formal specification.
Impact assessment areas vary depending on the formal specification assessed, but they may generally cover a wide series of aspects. The financial aspect focuses on cost and benefit analysis. The organisational aspect highlights issues linked to continuity of process, change management, etc.... The environmental aspect looks into regional, national or even global consequences. Other relevant aspects include migration management, as well as effects on security and privacy issues. Effects on interoperability with other processes or other organisations need also to be analysed, including compatibility with formal specifications in the direct environment. Questions on dependencies are also relevant, as well as consequences on administrative burden.
Analysing the possible evolution of the formal specification implies looking at its scalability; in other words to which extent the system implementing it can either handle growing amounts of work in a straightforward manner or to be readily enlarged.
Extensibility is also a possible evolution; it indicates the degree to which the formal specification can adapt to other areas. Extensibility to another field of formal specification is enhanced if there is an associated methodology (for example, taxonomy for semantic standards). Extensibility also refers to the possibility of localisation, or in other terms the adaptation for non-native environments, especially other countries and cultures.
A formal specification may present the property of stability in its evolution, which is linked to concepts such as non-obsolescence and broad acceptance, and implies the analysis of issues linked to changes in the specifications and version release, including backward compatibility and upgrade management.
The stability of a formal specification is strongly linked to the quality of the maintenance process. Maintainability addresses the ease with which a formal specification can be modified; and analyses governance of the evolution of the formal specification, including dissemination of new versions and stability of the maintenance process.
The ideas behind the Suitability criteria can also be expressed with the following questions:
Impact
CAMSS7: What is the impact of choosing this formal specification? I.e., what are the risks and opportunities identified?
CAMSS8: What is the financial impact? Which are the costs incurred? Which are the benefits?
CAMSS9: What is the Organisational impact? Is there a continuity of process? Are there business processes to be changed? What is the scope of Change Management to be foreseen (i.e.: training...)?
CAMSS10: What is the Environmental impact of the choice? At the national / regional / global levels?
CAMSS11: What is the impact on the Migration? I.e.: are there migration tools?
CAMSS12: What are the Security aspects? I.e. consequences of the choice and further actions to assure security
CAMSS13: What are the Privacy aspects? I.e. consequences of the choice and further actions to assure privacy
CAMSS14: What is the impact on interoperability with other processes, other organisations?
CAMSS15: What is the compatibility of the formal specifications in the direct environment?
CAMSS16: What dependencies should be considered? (A dependency analysis does not only comprise dependencies of the standard or specification to other standards or specifications but also various “lock-in”, bundling or forced upgrades risks).
CAMSS17: What is the impact on administrative burden?
Scalability
CAMSS18: To which extent can the formal specification adapt to the size of the needs, i.e.: its ability to support an increasing number of implementations and/or interactions among those implementations
Extensibility
CAMSS19: To which degree or with which ease is the formal specification extensible to another area?
CAMSS20: Are there possibilities of localisation, i.e.: adaptation to different user environments and cultures?
Stability
CAMSS21: For how long has this formal specification existed?
CAMSS22: How long can it and its later modifications be used and still maintain its quality?
CAMSS23: How often are new versions released and with what type of change?
CAMSS24: Were these changes predictable? Were these changes controlled? Are there any "backward compatibility" issues linked to major revisions in progress?
CAMSS25: Are there any "backward compatibility" problems reported/documented for previous version of the formal specification?
CAMSS26: Which effort is needed for an organisation using the formal specification to upgrade to a new version?
Maintainability
CAMSS27: Is the maintenance process of the formal specification stable?
CAMSS28: Does the formal specification benefit from a strong community support?
CAMSS29: Is there any entity in charge of regularly assessing the formal specification against the evolution of needs and available technologies?
CAMSS30: How are new versions communicated to organisations using the formal specification?
CAMSS31: Are there promises to enhance openness of a formal specification?
Status of This Document
CAMSS has been evolving gradually since its creation in 2007. This is work in progress and the document will be subject to change. New terms may be added at any time, and consequently this specification is an evolving work. The extent of change is communicated by the change of version. A change in the first number notifies a major semantic change, in the second number a minor semantic change, the character is a for alpha and b for beta and finally the last number is just a syntactic change, Major Semantic. Minor Semantic (a|b) Syntactic.
This CAMSS documentation is produced as part of the CAMSS project, to provide authoritative documentation of the contents, status and purpose. The author welcomes comments on this document, preferably via email to per-olav.gramstad@ec.europa.eu. Further work is also needed on the explanatory text in this document and on the CAMSS website; progress towards this will be measured in the version number of future revisions to the CAMSS documentation.
Contributors:
Members of the CAMSS expert group.
© European Communities, 2009. Reproduction is authorised provided the source is acknowledged. Printed in Belgium
Nature of documentation: Article