L4 RE Processes
Download as PPTX, PDF5 likes1,105 views
Requirements engineering processes vary significantly between organizations due to differences in factors like the type of system being developed and the organization's maturity. Key activities in most requirements engineering processes include requirements discovery, classification, prioritization, documentation, and management of changes. Effective requirements engineering requires understanding problems from different perspectives like the product, customers, developers, and environment to develop requirements that satisfy stakeholders.
L4 RE Processes
- 1. Requirements engineering processesProf Ian Sommerville
- 2. ObjectivesTo introduce the activities in requirements engineering processesTo discuss the reasons why there RE processes vary significantly from one organisation to anotherTo introduce the activity of requirements management
- 3. RE process perspectivesDifferent views of requirements engineering processes
- 4. Perceptions of requirements engineeringRequirements engineering (RE) means different things to different peopleIt’s about problem analysis, andIt’s about solution specification, andIt’s the baseline for design, andIt’s what you do at the start of the life-cycle.RE is all of these things so, as a consequence, there cannot be a single, definitive RE processRE processes vary dramatically depending on the type of system being developed and the maturity of the organisation procuring the system
- 5. Goals of requirements engineeringSpecify a product that satisfies the stakeholders and constraints Specify how that satisfaction is to be verified Enable project planning and cost estimation Manage changeWrite a description of the requirements in a form that is suitable for the customer for the system and for the system developer
- 7. A staged model of a requirements engineering process
- 8. A spiral view of the RE process
- 9. Process variabilityThe factors that lead to variability in requirements engineering processes
- 10. Process activitiesRequirements discoveryInteracting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.Requirements classification and organisationGroups related requirements and organises them into coherent clusters.Prioritisation and negotiationPrioritising requirements and resolving requirements conflicts.Requirements documentationRequirements are documented and input into the next round of the spiral.
- 11. Problem understanding Understanding the problem when developing requirements for a system is not a simple technical issue.Requirements engineers have to understandThe productThe processThe customer (s)The developer (s) of the softwareThe deployment environment
- 12. 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 productDo customers for know what their requirements are?Who supplies the requirements for a software product?
- 13. 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.
- 14. 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
- 15. 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
- 16. 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?
- 17. Why is RE hard to get right?The world is complexThe problem is not always tractable to analysis.The world changesThe problem will change … and the solution may change the problem.Resources are scarceRE is always tightly time- and money-bound;Required effort will exceed budget.
- 18. Typical process problemsRequirements elicitationFailure to consider all important stakeholders and therefore critical requirements are not included in the systemRequirements analysisFailure to carry out a detailed analysis of the requirementsSystem and problem models become inconsistentRequirements validationFailure to identify requirements testsInsufficient validation of requirementsRequirements managementFailure of change control and management of requirements
- 19. Symptoms of RE process problemsProduct problemsCustomer dissatisfactionDelays in implementing changes to productsUnused product featuresPeople problemsSystem stakeholders feel excludedMeetings failing to reach agreementSchedule problemsRequirements changes take a long time to negotiateExtensive rework causes schedule delays
- 20. Requirements managementThe process of managing changes to system requirements
- 21. Requirements managementRequirements management is the process of managing changing requirements during the requirements engineering process and system development.Requirements are inevitably incomplete and inconsistentNew requirements emerge during the process as business needs change and a better understanding of the system is developed;Different viewpoints have different requirements and these are often contradictory.
- 22. Requirements changeThe priority of requirements from different viewpoints changes during the development process.System customers may specify requirements from a business perspective that conflict with end-user requirements.The business and technical environment of the system changes during its development.
- 24. Enduring and volatile requirementsEnduring 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 modelsVolatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy
- 26. Requirements management planningDuring the requirements engineering process, you have to plan:Requirements identification How requirements are individually identified;A change management processThe process followed when analysing a requirements change;Traceability policiesThe amount of information about requirements relationships that is maintained;CASE tool supportThe tool support required to help manage requirements change;
- 27. Requirements identificationA scheme has to be devised for requirements identification so that requirements can be unambiguously identifiedThe most common scheme is a nested numbering scheme e.g. 1.2.3. However, such schemes are a problem The top level classification (the first number) has to be fixed in advanceThere are problems when requirements are changedMajor problem is ensuring that stakeholders use the requirements identification scheme in a consistent way
- 29. TraceabilityTraceability is concerned with the relationships between requirements, their sources and the system designSource traceabilityLinks from requirements to stakeholders who proposed these requirements;Requirements traceabilityLinks between dependent requirements;Design traceabilityLinks from the requirements to the design;
- 30. Tool supportRequirements storageRequirements should be managed in a secure, managed data store.Change managementThe process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated.Traceability managementAutomated retrieval of the links between requirements.
- 31. Key pointsA staged requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements management.Social and organisational factors influence system requirements, resulting in variations in RE processesBusiness changes inevitably lead to changing requirements.Requirements management includes planning and change management.