5. SE RequirementEngineering task.ppt
- 1. Chapter 7 Requirement Engineering 1 Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Software Engineering 9/e By Ian Sommerville Introduction to Software Engineering
- 2. Content to complete Requirement Engineering Task • Inception • Elicitation • Elaboration • Negotiation • Validation • Requirement Management 2
- 3. Inception How does a software project get started? •Is there another source for the solution? •Stakeholders from the business community define a business case for the idea, try to identify the breadth and depth of the market, do analysis and identify description of the project’s scope. •You establish a basic understanding of the problem the people who want a solution, nature of solution, collaboration b/w the other stakeholders and S/W team 3
- 4. Requirement Elicitation •Sometimes called requirements elicitation or requirements discovery ,requirement capture and requirement acquisition. •Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. •May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.
- 5. Problems of Elicitation Problem of Scope: –The boundary of the system is ill-defined. –Customers / users specify unnecessary technical detail that may confuse rather than clarify objectives. Understanding: -Stakeholders don’t know what they really want. -Stakeholders express requirements in their own terms. -Different stakeholders may have conflicting requirements. -Organizational and political factors may influence the system requirements. -Customers are not completely sure of what is needed?. -Customers have a poor understanding of the capabilities and limitations of the computing environment
- 6. Problems of Elicitation Volatility: The requirements change during the analysis process. New stakeholders may emerge and the business environment change. requirements change over time
- 7. Elicitation Techniques Various elicitation techniques are used to identify the problem, determine its solution, and identify different approaches for the solution –Interviews –Scenarios –Ethnography –Quality Function Deployment (QFD) •General requirements •Expected requirements •Unexpected requirements
- 8. Interviewing •In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed. •There are two types of interview –Closed interviews where a pre-defined set of questions are answered. –Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.
- 9. 9 Effective interviewers •Interviewers should be open-minded, willing to listen to stakeholders and should not have pre-conceived ideas about the requirements. •They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’.
- 10. Scenarios •Scenarios are real-life examples of how a system can be used. •They should include –A description of the starting situation; –A description of the normal flow of events; –A description of what can go wrong; –Information about other concurrent activities; –A description of the state when the scenario finishes.
- 11. Ethnography •A social scientists spends a considerable time observing and analyzing how people actually work. •People do not have to explain or articulate their work. •Social and organizational factors of importance may be observed. •Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models.
- 12. Elaboration •Is to refine the information obtained from the customer during inception and elicitation. •Is an ANALYSIS MODELING actions –Focus on developing a refined technical model of software functions, features, and constraints, behavior and information. –Determine how end user will interact the system.
- 13. Negotiation •Understand stakeholders •Resolve Conflicts so that each party achieves some measures of satisfaction. •Resolve Risks •categorizes and organizes requirements •explores each requirement in relation to others •examines requirements for consistency , omissions, and ambiguity •ranks requirements based on the needs of the users
- 14. Specification •The term specification means different things to different people •A specification can be a Written document •Graphical model •Formal mathematical model •Collection of usage scenarios •Prototype •Follow Standard Template •Final work product • •Foundation for subsequent SE activities
- 15. 15 Requirements validation •Concerned with demonstrating that the requirements define the system that the customer really wants. •Requirements error costs are high so validation is very important –Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.
- 16. Requirements checking •Validity. Does the system provide the functions which best support the customer’s needs? •Consistency. Are there any requirements conflicts? •Completeness. Are all functions required by the customer included? •Realism. Can the requirements be implemented given available budget and technology •Verifiability. Can the requirements be checked? .
- 17. 17 Requirements reviews Regular reviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage.
- 18. 18 Review checks Verifiability: Is the requirement realistically testable? Comprehensibility: Is the requirement properly understood? Traceability: Is the origin of the requirement clearly stated? Adaptability: Can the requirement be changed without a large impact on other requirements?
- 19. Requirements management Requirements management is the process of managing changing requirements during the requirements engineering process and system development. Requirement management is a set of activities that help the project team to identify, control and track requirements and changes to requirements at any time as the project proceed. Requirements are unavoidably incomplete and inconsistent –New 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.
Editor's Notes
- #13: By Dorfman