The document discusses the complexities and challenges of the requirements engineering (RE) process, emphasizing the need for understanding stakeholder needs and adapting to various environments. It highlights common issues in RE, including stakeholder elicitation failures and the impact of informal processes on product quality. The importance of incremental process improvement to enhance effectiveness and efficiency in RE practices is also underscored.

1. Requirements Engineering Process Improvement Professor Ian Sommerville Lancaster University, UK

2. Structure of the tutorial Goal identification What are YOUR problems and what would YOU like to gain from this tutorial? Requirements engineering - Processes and Problems Questions and Discussion A Requirements Engineering Process Maturity Model Requirements Engineering - Good Practice Guidelines Questions and Discussion

3. The REAIMS project Requirements Engineering Adaptation and Improvement for Safety and Dependability (1994 - 96) This was the background for the approach to process improvement that I will describe here. Partners: GEC-Alsthom; Aerospatiale; Digilog; TÜVit; University of Manchester, Lancaster University. Mature, quality-conscious, critical systems engineering Business Environment: Tightly regulated, slow evolution to a product focus

4. Requirements Engineering Processes and Problems

5. What is Requirements Engineering? Requirements engineering (RE) means different things to different people It’s about problem analysis, and It’s about solution specification, and It’s the baseline for design, and It’s what you do at the start of the life-cycle. RE is all of these things but, more generally, it is the process of developing an understanding of what a system should do, how it should do it and the environment where the system will be used.

6. A requirements engineering process

7. Goals of requirements engineering Specify a product that satisfies the stakeholders and constraints Specify how that satisfaction is to be verified Enable project planning and cost estimation Manage change Write a description of the requirements in a form that is suitable for the customer for the system and for the system developer

8. Problem understanding Understanding the problem when developing requirements for a system is not a simple technical issue. Requirements engineers have to understand The product The process The customer (s) The developer (s) of the software The deployment environment

9. Is the product... An information system? Understanding the organisational environment is crucial; The organisation may change radically; An embedded or hybrid system? Operational environment needs to be understood; Solution architecture fixed early and hard to change; Production problems tend to migrate to the software. A custom-built system or a software product Do customers for know what their requirements are? Who supplies the requirements for a software product?

10. Is the process... Customer-driven? Customer is principal stakeholder; Typically a document-driven process. Market-driven? Time-to-market is the dominant constraint; Developer is principal stakeholder; Driven by product vision for first release. Subsequent releases need to balance developer’s strategic goals and customers’ requirements.

11. Is the customer… Homogeneous? Need to understand their business and strategic objectives. Heterogeneous? Need to trade off conflicting requirements, This is the normal situation. Merely potential? Need a proxy to represent the actual customer

12. Has the developer... A document culture? Documentation may be an overhead for small start-ups - but a creeping requirement as product and customer base grows. A quality culture? RE ‘products’ perceived to have only an indirect relationship to software products; Classical view of quality conflicts with short development cycles. A RAD culture? No experience of dealing with requirements documents but works on the basis of prototyping and rapid evolution

13. Is the deployment environment... An existing environment with established processes and equipment? How should the system integrate with the existing equipment? Will existing processes be resistant to change? Flexible and geared to change? Are the people in the environment used to change or will they resist the system? Is the management tradionally hierarchical? Disciplined? Do the people in the environment work according to a process or do they set their own tasks?

14. Why is RE hard to get right? The world is complex The problem is not always tractable to analysis. The world changes The problem will change … and the solution may change the problem. Resources are scarce RE is always tightly time- and money-bound; Required effort will exceed budget.

15. RE process interactions

16. The requirements process Stakeholder requirements Elicitation Analysis and negotiation Validation System requirements Test plans

17. Typical process problems Requirements elicitation Failure to consider all important stakeholders and therefore critical requirements are not included in the system Requirements analysis Failure to carry out a detailed analysis of the requirements System and problem models become inconsistent Requirements validation Failure to identify requirements tests Insufficient validation of requirements Requirements management Failure of change control and management of requirements

18. Symptoms of RE process problems Product problems Customer dissatisfaction Delays in implementing changes to products Unused product features People problems System stakeholders feel excluded Meetings failing to reach agreement Schedule problems Requirements changes take a long time to negotiate Extensive rework causes schedule delays

19. Why RE process improvement? To reduce problems with operational software To reduce the costs of requirements engineering To satisfy external customers or regulators To reduce the time to delivery for software systems To adapt to other process changes To make better use of your intellectual assets

20. What is process improvement? Changes to a process that are introduced to make that process more effective in supporting the goals of the business Approaches to improvement Business process re-engineering. Radical revision of processes often supplemented with new IT support. Rarely effective for knowledge-based processes Incremental improvement. Finding better ways to do what is already being done! Technology support. Introducing new technology to support existing processes with minimal process change

21. Requirements engineering good practice Good practice is the basis of an incremental approach to RE process improvement Where does it come from? Experience Internal company experience External ‘community wisdom’ Standards, e.g. IEEE std 830 (SRS standard) IEEE std 1362 (Concept of Operations) ISO/IEC 12207 (S/W life-cycle standard) PSS-05 (ESA software engineering standard(s))

22. The state of RE processes Informal studies have shown that few organisations have thought about their RE processes and that many good practices are ignored If there’s so much known good practice, why is RE so immature? Domain specialists involved in RE are not aware of good practice because they are not requirements engineers Generally infeasible to adopt a ‘big-bang’ approach ‘ Community wisdom’ lacks consensus Standards need to be interpreted and tailored Insufficient guidance on how to prioritise adoption of a standard

23. Inhibitors to RE process improvement The range of stakeholders in the RE process itself and their different priorities Process improvement is perceived as a customer-imposed overhead; aimed at large, bespoke projects; resource-hungry. Existing software process improvements models fail to consider RE in detail

24. Are improvements possible? Definitely YES so long as: You tailor the improvements to the type of products and processes that you develop. Informal processes for small products are as amenable to improvements than larger processes for large custom systems products You don’t expect miracles. Improvements should be incremental and should respect the sensibilities of the people involved in the processes You design improvements based on what you REALLY do not on a formal, unrealistic model. Professionals interpret these models in their own way.

25. Summary Requirements engineering is a very complex task which can be thought of as the interface between the real world and the computer system Requirements engineering processes are often informal and process weaknesses can lead to problems in the delivered product Requirements engineering process improvement should improve product quality and shorten delivery times Process improvement should be incremental and should respect the sensibilities of the people involved