Requirements engineering processes<br />Prof Ian Sommerville<br />
Objectives<br />To introduce the activities in requirements engineering processes<br />To discuss the reasons why there RE...
RE process perspectives<br />Different views of requirements engineering processes<br />
Perceptions of requirements engineering<br />Requirements engineering (RE) means different things to different people<br /...
Goals of requirements engineering<br />Specify a product that satisfies the stakeholders and constraints<br /> Specify how...
RE process interactions<br />
A staged model of a requirements engineering process<br />
A spiral view of the RE process<br />
Process variability<br />The factors that lead to variability in requirements engineering processes<br />
Process activities<br />Requirements discovery<br />Interacting with stakeholders to discover their requirements. Domain r...
Problem understanding<br /> Understanding the problem when developing requirements for a system is not a simple technical ...
Is the product...<br /> An information system?<br />Understanding the organisational environment is crucial;<br />The orga...
Is the process...<br /> Customer-driven?<br />Customer is principal stakeholder;<br />Typically a document-driven process....
Is the customer…<br />Homogeneous?<br />Need to understand their business and strategic objectives.<br />Heterogeneous?<br...
Has the developer...<br />A document culture?<br />Documentation may be an overhead for small start-ups - but a creeping r...
Is the deployment environment...<br />An existing environment with established processes and equipment?<br />How should th...
Why is RE hard to get right?<br />The world is complex<br />The problem is not always tractable to analysis.<br />The worl...
Typical process problems<br />Requirements elicitation<br />Failure to consider all important stakeholders and therefore c...
Symptoms of RE process problems<br />Product problems<br />Customer dissatisfaction<br />Delays in implementing changes to...
Requirements management<br />The process of managing changes to system requirements<br />
Requirements management<br />Requirements management is the process of managing changing requirements during the requireme...
Requirements change<br />The priority of requirements from different viewpoints changes during the development process.<br...
Requirements evolution<br />
Enduring and volatile requirements<br />Enduring requirements. Stable requirements derived from the core activity of the c...
Requirements classification<br />
Requirements management planning<br />During the requirements engineering process, you have to plan:<br />Requirements ide...
Requirements identification<br />A scheme has to be devised for requirements identification so that requirements can be un...
Change management<br />
Traceability<br />Traceability is concerned with the relationships between requirements, their sources and the system desi...
Tool support<br />Requirements storage<br />Requirements should be managed in a secure, managed data store.<br />Change ma...
Key points<br />A staged requirements engineering process includes a feasibility study, requirements elicitation and analy...
Upcoming SlideShare
Loading in …5
×

L4 RE Processes

1,406
-1

Published on

Requirements engineering processes - different ways of looking at requirements engineering

Published in: Business, Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,406
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
42
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

L4 RE Processes

  1. 1. Requirements engineering processes<br />Prof Ian Sommerville<br />
  2. 2. Objectives<br />To introduce the activities in requirements engineering processes<br />To discuss the reasons why there RE processes vary significantly from one organisation to another<br />To introduce the activity of requirements management<br />
  3. 3. RE process perspectives<br />Different views of requirements engineering processes<br />
  4. 4. Perceptions of requirements engineering<br />Requirements engineering (RE) means different things to different people<br />It’s about problem analysis, and<br />It’s about solution specification, and<br />It’s the baseline for design, and<br />It’s what you do at the start of the life-cycle.<br />RE is all of these things so, as a consequence, there cannot be a single, definitive RE process<br />RE processes vary dramatically depending on the type of system being developed and the maturity of the organisation procuring the system<br />
  5. 5. Goals of requirements engineering<br />Specify a product that satisfies the stakeholders and constraints<br /> Specify how that satisfaction is to be verified<br /> Enable project planning and cost estimation<br /> Manage change<br />Write a description of the requirements in a form that is suitable for the customer for the system and for the system developer<br />
  6. 6. RE process interactions<br />
  7. 7. A staged model of a requirements engineering process<br />
  8. 8. A spiral view of the RE process<br />
  9. 9. Process variability<br />The factors that lead to variability in requirements engineering processes<br />
  10. 10. Process activities<br />Requirements discovery<br />Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.<br />Requirements classification and organisation<br />Groups related requirements and organises them into coherent clusters.<br />Prioritisation and negotiation<br />Prioritising requirements and resolving requirements conflicts.<br />Requirements documentation<br />Requirements are documented and input into the next round of the spiral.<br />
  11. 11. Problem understanding<br /> Understanding the problem when developing requirements for a system is not a simple technical issue.<br />Requirements engineers have to understand<br />The product<br />The process<br />The customer (s)<br />The developer (s) of the software<br />The deployment environment<br />
  12. 12. Is the product...<br /> An information system?<br />Understanding the organisational environment is crucial;<br />The organisation may change radically;<br />An embedded or hybrid system?<br />Operational environment needs to be understood;<br />Solution architecture fixed early and hard to change;<br />Production problems tend to migrate to the software.<br />A custom-built system or a software product<br />Do customers for know what their requirements are?<br />Who supplies the requirements for a software product?<br />
  13. 13. Is the process...<br /> Customer-driven?<br />Customer is principal stakeholder;<br />Typically a document-driven process.<br /> Market-driven?<br />Time-to-market is the dominant constraint;<br />Developer is principal stakeholder;<br />Driven by product vision for first release. Subsequent releases need to balance developer’s strategic goals and customers’ requirements.<br />
  14. 14. Is the customer…<br />Homogeneous?<br />Need to understand their business and strategic objectives.<br />Heterogeneous?<br />Need to trade off conflicting requirements, This is the normal situation.<br />Merely potential?<br />Need a proxy to represent the actual customer<br />
  15. 15. Has the developer...<br />A document culture?<br />Documentation may be an overhead for small start-ups - but a creeping requirement as product and customer base grows.<br />A quality culture?<br />RE ‘products’ perceived to have only an indirect relationship to software products;<br />Classical view of quality conflicts with short development cycles.<br />A RAD culture?<br />No experience of dealing with requirements documents but works on the basis of prototyping and rapid evolution<br />
  16. 16. Is the deployment environment...<br />An existing environment with established processes and equipment?<br />How should the system integrate with the existing equipment? Will existing processes be resistant to change?<br />Flexible and geared to change?<br />Are the people in the environment used to change or will they resist the system?<br />Is the management tradionally hierarchical?<br />Disciplined?<br />Do the people in the environment work according to a process or do they set their own tasks?<br />
  17. 17. Why is RE hard to get right?<br />The world is complex<br />The problem is not always tractable to analysis.<br />The world changes<br />The problem will change … and the solution may change the problem.<br />Resources are scarce<br />RE is always tightly time- and money-bound;<br />Required effort will exceed budget.<br />
  18. 18. Typical process problems<br />Requirements elicitation<br />Failure to consider all important stakeholders and therefore critical requirements are not included in the system<br />Requirements analysis<br />Failure to carry out a detailed analysis of the requirements<br />System and problem models become inconsistent<br />Requirements validation<br />Failure to identify requirements tests<br />Insufficient validation of requirements<br />Requirements management<br />Failure of change control and management of requirements<br />
  19. 19. Symptoms of RE process problems<br />Product problems<br />Customer dissatisfaction<br />Delays in implementing changes to products<br />Unused product features<br />People problems<br />System stakeholders feel excluded<br />Meetings failing to reach agreement<br />Schedule problems<br />Requirements changes take a long time to negotiate<br />Extensive rework causes schedule delays<br />
  20. 20. Requirements management<br />The process of managing changes to system requirements<br />
  21. 21. Requirements management<br />Requirements management is the process of managing changing requirements during the requirements engineering process and system development.<br />Requirements are inevitably incomplete and inconsistent<br />New requirements emerge during the process as business needs change and a better understanding of the system is developed;<br />Different viewpoints have different requirements and these are often contradictory.<br />
  22. 22. Requirements change<br />The priority of requirements from different viewpoints changes during the development process.<br />System customers may specify requirements from a business perspective that conflict with end-user requirements.<br />The business and technical environment of the system changes during its development.<br />
  23. 23. Requirements evolution<br />
  24. 24. Enduring and volatile requirements<br />Enduring requirements. Stable requirements derived from the core activity of the customer organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models<br />Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy<br />
  25. 25. Requirements classification<br />
  26. 26. Requirements management planning<br />During the requirements engineering process, you have to plan:<br />Requirements identification<br /> How requirements are individually identified;<br />A change management process<br />The process followed when analysing a requirements change;<br />Traceability policies<br />The amount of information about requirements relationships that is maintained;<br />CASE tool support<br />The tool support required to help manage requirements change;<br />
  27. 27. Requirements identification<br />A scheme has to be devised for requirements identification so that requirements can be unambiguously identified<br />The most common scheme is a nested numbering scheme e.g. 1.2.3. However, such schemes are a problem <br />The top level classification (the first number) has to be fixed in advance<br />There are problems when requirements are changed<br />Major problem is ensuring that stakeholders use the requirements identification scheme in a consistent way<br />
  28. 28. Change management<br />
  29. 29. Traceability<br />Traceability is concerned with the relationships between requirements, their sources and the system design<br />Source traceability<br />Links from requirements to stakeholders who proposed these requirements;<br />Requirements traceability<br />Links between dependent requirements;<br />Design traceability<br />Links from the requirements to the design;<br />
  30. 30. Tool support<br />Requirements storage<br />Requirements should be managed in a secure, managed data store.<br />Change management<br />The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated.<br />Traceability management<br />Automated retrieval of the links between requirements.<br />
  31. 31. Key points<br />A staged requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements management.<br />Social and organisational factors influence system requirements, resulting in variations in RE processes<br />Business changes inevitably lead to changing requirements.<br />Requirements management includes planning and change management.<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×