Requirements Engineering: A Good Practice Guide
Download as PPT, PDF6 likes5,747 views
The document summarizes a good practice guide for requirements engineering. It outlines 66 guidelines for best practices in areas like requirements elicitation, analysis, validation and management. It recommends implementing basic practices first before moving to more intermediate and advanced practices. The guide provides examples of guidelines on using validation checklists and gives advice on planning incremental process improvements by addressing problems, setting goals and managing introductions of new practices.
Requirements Engineering: A Good Practice Guide
- 1. Requirements Engineering A Good Practice Guide
- 2. The good practice guidebook Structure: Contains a guide to the activities and products of the requirements process. Lists 66 guidelines to key good practices. Introduces the REAIMS improvement model for requirements process improvement. Provides guidance on the assessment of RE process maturity.
- 3. REGPG guidelines Guidelines are provided for each activity/product area. Requirements elicitation Requirements analysis and negotiation System modelling Requirement validation Requirement management Guidelines are: 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.
- 4. The top ten good RE practices Define a standard document structure. Make the document easy to change. Uniquely identify each requirement. Define policies for requirements management. Define standard templates for req. description. Use language simply, consistently and concisely. Organise formal requirements reviews. Define validation checklists. Use checklists for requirements analysis. Plan for conflicts and conflict resolution.
- 5. Basic good practices Assess system feasibility Be sensitive to organisational and political considerations Identify and consult system stakeholders Record requirements sources Define system’s operating environment Use business concerns to drive requirements elicitation
- 6. Intermediate practices Look for domain constraints Record requirements rationale Collect requirements from multiple viewpoints Prototype poorly understood requirements Use scenarios to elicit requirements Define operational processes In general, you should not introduce intermediate practices before a large number of basic practices are in normal use
- 7. Advanced practices Reuse requirements Assess requirements risks Specify systems using formal methods Collect incident experience Advanced practices should only be introduced after you have reached the repeatable level in the process maturity model. If you introduce them earlier, then you may find them ineffective
- 8. RE - GPG Guidelines Guidelines to the good practices are structured in a standard easy-to-understand way Each description includes A short discussion of the key benefits Practical advice on how to implement the practice An assessment of likely costs and problems of both introducing and using the practice
- 9. Example: Guideline 8.4 Define validation checklists General You should define a checklist or checklists which helps focus the attention of requirements validators on critical attributes of the requirements document. These checklists should identify what readers should look for when they are validating the system requirements. Key benefits : Help to focus the validation process Costs of introduction : Low-moderate Costs of application : Low Guideline type : Basic
- 10. Example: Guideline 8.4 (contd.) Benefits Checklists add structure to the validation process. It is therefore less likely that readers will forget to check some aspects of the requirements document. Checklists help in the introduction of people who are new to requirements validation. The checklist gives them hints what they should be looking for so that they feel more able to participate in the process. This is particularly important for customer management and end-users who may not have requirements validation experience.
- 11. Example: Guideline 8.4 (contd.) Implementation The use of checklists for requirements analysis has already been discussed in Guideline 5.2, Use checklists for requirements analysis and similar checklists may also be used in the validation process. These checklists are oriented towards individual requirements; validation checklists should also be concerned with the quality properties of the requirements document as a whole and with the relationships between individual requirements. This can’t be checked during requirements analysis as the requirements document is unfinished at that stage. Questions which might be included in such a checklist should be based on the following general issues: 1. Are the requirements complete, that is, does the checker know of any missing requirements or is there any information missing from individual requirement descriptions? … .etc…...
- 12. Example: Guideline 8.4 (contd.) Costs and problems This is not an expensive guideline to implement if you use a fairly general checklist with questions like those listed above. To introduce the guideline, you need to draw up an initial checklist based on the experience of people who have been involved in requirements validation. If a checklist is simply used a memory aid, there are no costs involved in applying the guideline. If checkers of the requirements must mark each requirement against the checklists, clearly some additional time is required. This should not be more than one or two minutes per requirement. In principle, there should be few problems in applying the guideline so long as you have a fairly flexible process which allows people to ignore inappropriate checklist entries. In practice, some requirements analysts may resent the introduction of checklists as they see them as de-skilling the process. You have to emphasise that the checklists are designed to help them and point out that professional judgement must still be used.
- 13. Process improvement Stakeholder requirements Requirements management Elicitation Analysis and negotiation Validation System requirements Test plans Good Practice
- 14. Applying the REGPG Getting started Ensure that the top 10 guidelines are in place Assess the maturity of the current processes Plan incremental RE process improvements Introduce new practices Check success of improvements against your improvement goals Introduce the next stage of improvements
- 15. Planning and implementing improvements The essence of the REAIMS approach to improvement Goal-driven Incremental Recognises the importance of controlling risks and costs There are four questions to ask when planning improvement: What are your most pressing problems? What are your improvement goals? How can improvements be matched to the goals? How should improvements be managed?
- 16. What are the most pressing problems? Incremental improvement should be problem-driven. Start by identifying and addressing your most urgent problems: Possible problems might be: poor product quality loss of change control cost and delivery over-runs staff morale low productivity lack of process visibility
- 17. What are the improvement goals? Decide what you want to achieve from the improvement process. If you don’t know where you are going, you won’t be able to tell if you’ve arrived Improvement goals should normally be related to the identified problems Goals must be realistic - unrealistic goals lead to disappointments, disillusion and cancellation. May be expressed in a qualitative or in a quantitative way
- 18. Match improvements to goals Use the advice in the good practice guide to identify the practices that are most likely to help you achieve your goals Relate the improvement goals to specific RE process activities or to deliverables from the RE process If the symptoms of your problems are hard to tie back to one of the activities/products of the RE process then STOP!. You need more information about your problems at this stage
- 19. Manage the introduction of improvements You have to assess your improvements against your goals. You should collect feedback from the improvements Quantitative information about the process such as the number of change requests, the time required to approve new requirements etc. Qualitative information from practitioners. What do people think? Feedback must be acted upon. If the practices don’t appear to be making a difference then don’t hesitate to re-iterate and to try something else.
- 20. Advice on introducing improvements Find an evangelist An evangelist is someone who believes in the improvement and will work to convince others. If you have an evangelist, this is a good reason to select one improvement over another Try changes out on pilot projects There will be problems! Pilot projects let you find these problems without affecting too many people Allow enough time to make the change Improvements to professional processes take time Respect professional skills The people in the processes are the experts. Listen to them
- 21. Summary The RE- GPG is intended to help organisations improve their requirements engineering processes Extends the principles of top-down software process improvement to requirements engineering Provides 66 good practices with advice on benefits, costs, etc. Focuses on pragmatic advice that is adaptable to individual organisations’ needs
Editor's Notes
- #4: Basic practices mainly about standardisation management ease of use Intermediate ones mainly about methods Advanced ones specialised on-going improvement and learning