A process maturity model for requirements engineering
Download as PPT, PDF2 likes3,623 views
The REAIMS process maturity model provides a framework for assessing and improving an organization's requirements engineering processes. It consists of three levels - initial, repeatable, and defined - based on the extent to which basic, intermediate, and advanced good practices are used. The model was developed to address limitations of other models like CMM in assessing requirements engineering. Assessment involves scoring organizational usage of practices against a checklist to determine the current maturity level and identify areas for improvement.
A process maturity model for requirements engineering
- 1. A Process Maturity Model for Requirements Engineering
- 2. Process Maturity Models A process maturity model is a framework that organisations can use to assess their processes against ‘best practice’ in industry Processes are ranked on an ascending scale according to the practices used and the quality assurance procedures that are in place in the organisation Models serve as a basis for process improvement through moving from one level to another in the model The US DoD Software Capability Maturity Model is the best known maturity model but others (Bootstrap, Spice) have also been developed
- 3. The CMM for Software Requirements management 4 managed 2 repeatable 3 defined 1 initial 5 optimising
- 4. The CMM and Requirements Engineering The Capability Maturity Model has been designed for military system development where the requirements are the input to the software development process and are developed as part of the system procurement process It is NOT therefore concerned with requirements engineering processes except for requirements management - controlling changes to the requirements after they have been agreed The REAIMS project has identified a similar model for requirements engineering processes
- 5. The REAIMS process maturity model 3 level model. No direct correspondence with CMM levels 4 and 5. 1 initial 2 repeatable 3 defined
- 6. Principles of the REAIMS model There are known good practices in requirements engineering Use of these good practices lead to fewer RE process problems, better system requirements and therefore better software systems Because of the variability in RE processes, the model should not be prescriptive about the actual practices used in an organisation The model should provide a framework for process assessment and incremental RE process improvement through the introduction of these good practices
- 7. Good RE practices Basic : Fundamental measures needed for a repeatable process Intermediate : Help make process more systematic, sometimes complex to implement Advanced : Require specialist expertise, support on-going improvement Not all practices are appropriate to all organisations Implementation of Intermediate and Advanced practices is only likely to be successful if there is a foundation of basic good practice in place
- 8. The REAIMS process maturity model Level 1 - Initial level. Limited use of the best industrial practices. Most organisational RE processes operate at this level Typically: Ad hoc processes Costs are hard to estimate and control Unsupported by planning and review procedures or documentation standards Depend on “heroics”. Success depends on individuals rather than the organisation
- 9. The REAIMS process maturity model Level 2 - Repeatable level. Extensive use of basic good practices and limited use of intermediate and advanced practices. Typically: Defined standards for documents Policies and procedures for requirements management Possible use of structured methods ISO 9000 certification if appropriate
- 10. The REAIMS process maturity model Level 3 - Defined level Extensive use of basic and intermediate practices. Some use of appropriate advanced practices Few organisations appear to be operating at this level. However, it is probably only appropriate for developers of critical systems. Typically: Integrated requirements and systems engineering Active process improvement programme Able to accurately evaluate new practices
- 11. Maturity levels & practice classifications No rigid correspondence between maturity level and practice classes It is not necessary to have implemented all 36 basic practices to be a repeatable process Similarly... No rigid correspondence between maturity level activities/products e.g.: requirements elicitation should be addressed to help achieve a repeatable process but not to the exclusion of other areas.
- 12. Maturity assessment Goals of maturity assessment: Identify the approximate maturity level A management requirement. Identify particular areas of weakness Needed for effective targeting of resources We felt that the assessment process used in the CMM was too complex and expensive. Therefore, a requirement for the maturity assessment process was that it should be fairly easy to use We have developed a simple checklist-based assessment process based around good practice usage
- 13. Maturity assessment Resolve areas of uncertainty Calculate maturity Score process against checklist Prune guideline checklist Select people to interview
- 14. Prune guideline checklist We have developed a check-list with 36 basic good practices, 21 intermediate practices and 9 advanced practices Eliminate those practices that are obviously never used Some of the practices recommended are domain specific (e.g. are focussed on critical systems) Some practices are very advanced and only used in a small number of organisations (e.g. formal specification) Managers can very quickly identify practices that they are sure are never used in their organisation
- 15. Select people to interview Need to identify key people to talk to Practitioners what happens on the ground, level of usage, practical difficulties, etc. Managers what is supposed to happen, level of organisational commitment, etc. Choose people from different projects/groups/departments Only a small number of organisations have actually standardised the techniques that they use Your goal is to discover the reality not what the situation is supposed to be
- 16. Score practices against checklist Your goal is to discover whether or not good practices are used in the organisation Practices are roughly scored according to whether they are: Standardised - defined organisational standards have been agreed. In normal use - used by virtually all teams but often in different ways Used at peoples’ discretion - some teams have chosen to adopt particular practices Never used
- 17. Resolve areas of uncertainty The previous assessment activity will usually reveal patchy use across (e.g.) projects Need to evaluate representative level of usage and their consequences for the organisation This is an opportunity to find out what you do well and what you could do better. You may be surprised at the skills in your organisation Typically, this is likely to be most time-consuming part of the assessment
- 18. Calculate process maturity Score 3 for standardised practice, 2 for normal practice, 1 for occasional practice and 0 for unused practice Initial < 55 in basic practices. Repeatable >= 55 in basic practices and normally < 40 in others Defined > 85 in basic practices and >= 40 in others
- 19. Interpreting the result As it is practically impossible to draw clear divisions between the levels, we believe that the assessment used is accurate enough as a basis for process improvement Other, more accurate but more costly assessment schemes could be devised. But (unlike the CMM) the classification is simply an internal guide and not used by external organisations Of course, the numeric result should be considered in the light of what is known about the domain and the organisation.
- 20. Benefits of assessment Understanding what you actually do is an essential pre-requisite for improving your practice You may discover excellent practices and commonalities between projects and teams that were not previously apparent You expose engineers to new ideas and provide a basis for change It demonstrates an external and internal commitment to improving quality
- 21. Summary A process maturity model is a framework for assessing your existing processes and putting in place a programme of process improvement The REAIMS requirements engineering maturity model has three levels based on the use of good RE practices Initial - limited use Intermediate - extensive use of basic good practice Advanced - use of advanced techniques A simple checklist-based process can be used to assess the maturity of an organisation’s RE processes