Downloaded 718 times
More Related Content
Similar to Requirements engineering process in software engineering
Requirements engineering process in software engineering
- 1. RReeqquuiirreemmeenntt EEnnggiinneeeerriinngg PPrreeeettiiMMiisshhrraa CCoouurrssee IInnssttrruuccttoorr
- 4. Why good Specsare Essential: • It is VERY expensive to fix problems late in the process. It is very cheap to rewrite or clarify a written spec. • What costs $1 to fix at ReqGathering – $5 in the design stage – $10 in the coding stage – $20 in the unit testing phase – $200 after delivery 4
- 5. 5 The Problemswith our Requirements Practices • We have trouble understanding the requirements that we do acquire from the customer • We often record requirements in a disorganized manner • We spend far too little time verifying what we do record • We allow change to control us, rather than establishing mechanisms to control change • Most importantly, we fail to establish a solid foundation for the system or software that the user wants built
- 7. TTyyppeess ooff RReeqquuiirreemmeennttss • Functional – ex - it must email the sales manager when an inventory item is "low" • Non-Functional – ex - it must require less than one hour to run report #5 • Explicit – ex – required features • Implied – ex – software quality • Forgotten – ex – exists in current process • Unimagined 7
- 8. RReeqquuiirreemmeennttss ooff RReeqquuiirreemmeennttss • Clear • Measurable • Feasible • Necessary • Prioritized • Concise 8
- 9. Why Req Engis Difficult 9
- 10. 10 A Solution:Requirements Engineering • Begins during the communication activity and continues into the modeling activity • Builds a bridge from the system requirements into software design and construction • Allows the requirements engineer to examine – the context of the software work to be performed – the specific needs that design and construction must address – the priorities that guide the order in which work is to be completed – the information, function, and behavior that will have a profound impact on the resultant design
- 11. Requirement Engineering –RE helps software engineer to better understand the problem they will work to solve – Participant : Software Engineers, managers, customers and end users – RE is a software engineering action that begin during the communication activity and continues into the modeling activity
- 12. RE Provides theappropriate mechanism for • Understanding what the customer want • Analyzing need • Assessing feasibility • Negotiating a reasonable solution • Specifying a solution unambiguously • Validating the specification • Managing the requirement as they are transformed into an operational system
- 13. 13 Requirements Engineering Tasks • Seven distinct tasks – Inception – Elicitation – Elaboration – Negotiation – Specification – Validation – Requirements Management • Some of these tasks may occur in parallel and all are adapted to the needs of the project • All strive to define what the customer wants • All serve to establish a solid foundation for the design and construction of the software
- 14. 14 Validation Requirements Management Inception Elicitation Elaboration Negotiation Specification
- 15. Requirement Engineering Tasks • Inception—Establish a basic understanding of the problem and the nature of the solution. • Elicitation—Draw out the requirements from stakeholders. • Elaboration—Create an analysis model that represents information, functional, and behavioral aspects of the requirements. • Negotiation—Agree on a deliverable system that is realistic for developers and customers. • Specification—Describe the requirements formally or informally. • Validation—Review the requirement specification for errors, ambiguities, omissions, and conflicts. • Requirements management—Manage changing requirements.
- 16. 16 Inception Task • During inception, the requirements engineer asks a set of questions to establish… – A basic understanding of the problem – The people who want a solution – The nature of the solution that is desired – The effectiveness of preliminary communication and collaboration between the customer and the developer • Through these questions, the requirements engineer needs to… – Identify the stakeholders – Recognize multiple viewpoints – Work toward collaboration – Break the ice and initiate the communication
- 17. 17 The FirstSet of Questions These questions focus on the customer, other stakeholders, the overall goals, and the benefits • Who is behind the request for this work? • Who will use the solution? • What will be the economic benefit of a successful solution? • Is there another source for the solution that you need?
- 18. 18 The NextSet of Questions These questions enable the requirements engineer to gain a better understanding of the problem and allow the customer to voice his or her perceptions about a solution • How would you characterize "good" output that would be generated by a successful solution? • What problem(s) will this solution address? • Can you show me (or describe) the business environment in which the solution will be used? • Will special performance issues or constraints affect the way the solution is approached?
- 19. 19 The FinalSet of Questions These questions focus on the effectiveness of the communication activity itself • Are you the right person to answer these questions? Are your answers "official"? • Are my questions relevant to the problem that you have? • Am I asking too many questions? • Can anyone else provide additional information? • Should I be asking you anything else?
- 20. Elicitation • Itcertainly simple enough, but… • Why difficult – Problem of Scope • The boundary of the system is ill-defined – Problem of Understanding • The customer/users are not completely sure of what is needed – Problem of volatility • The requirement change over time • To help overcame these problem, requirement engineers ,must approach the requirement gathering activity in an organized manner
- 22. Elicitation Process Guideline – meetings are conducted and attended by both software engineers and customers – rules for preparation and participation are established – an agenda is suggested – a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting – a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used – the goal is • to identify the problem • propose elements of the solution • negotiate different approaches, and • specify a preliminary set of solution requirements
- 23. Elaboration • Expandrequirement into analysis model • Elements of the analysis model – Scenario-based elements • Functional—processing narratives for software functions • Use-case—descriptions of the interaction between an “actor” and the system – Class-based elements • Implied by scenarios – Behavioral elements • State diagram – Flow-oriented elements • Data flow diagram
- 25. Negotiation • Agreeon a deliverable system that is realistic for developers and customers • SW team & other project stakeholders negotiate the priority, availability, and cost of each requirement • The Process are : – Identify the key stakeholders • These are the people who will be involved in the negotiation – Determine each of the stakeholders “win conditions” • Win conditions are not always obvious – Negotiate • Work toward a set of requirements that lead to “win-win”
- 26. 26 The Artof Negotiation • Recognize that it is not competition • Map out a strategy • Listen actively • Focus on the other party’s interests • Don’t let it get personal • Be creative • Be ready to commit
- 28. Specification • Finalwork product produced by requirement engineer. • Can be any one (or more) of the following: – A written document – A set of models – A formal mathematical – A collection of user scenarios (use-cases) – A prototype
- 29. Technically Speaking, "requirement"≠ "specification" • Requirement – understanding between customer and supplier • Specification – what the software must do • Requirements that are not in the SRS – Costs – Delivery dates – Acceptance procedures – etc 29
- 30. Validation examine thespecification to ensure that SW requirement is not ambiguous, consistent, error free etc A review mechanism that looks for • errors in content or interpretation • areas where clarification may be required • missing information • inconsistencies (a major problem when large products or systems are engineered) • conflicting or unrealistic (unachievable) requirements.
- 31. Validation Vs. Verification • Validation: “Am I building the right product?” checking a work product against higher-level work products or authorities that frame this particular product. – Requirements are validated by stakeholders • Verification: “Am I building the product right?” checking a work product against some standards and conditions imposed on this type of product and the process of its development. – Requirements are verified by the analysts mainly
- 32. Validation Cont’d •A review of the analysis model addresses the following question : – Is each requirement consistent with the overall objective for the system/product? – Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? – Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? – Is each requirement bounded and unambiguous? – Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? – Do any requirements conflict with other requirements?
- 33. 33 Summary Validation Requirements Management Inception Elicitation Elaboration Negotiation Specification
- 34. The problems isnot that there are problems. The problem is expecting otherwise and thinking that having problems is a problem Theodore Rubin
- 35. Need to focus Moving in the wrong direction at a fast pace is still moving in the wrong direction. Right Wr ong
- 36.
- 37. Information on QFD…. • Developed in Japan in the mid 1970s • Introduced in USA in the late 1980s • Toyota was able to reduce 60% of cost to bring a new car model to market • Toyota decreased 1/3 of its development time • Used in cross functional teams • Companies feel it increased customer satisfaction
- 38. Why….? • Productshould be designed to reflect customers’ desires and tastes. • House of Quality is a kind of a conceptual map that provides the means for interfunctional planning and communications • To understand what customers mean by quality and how to achieve it from an engineering perspective. • HQ is a tool to focus the product development process
- 39. Important points •Should be employed at the beginning of every project (original or redesign) • Customer requirements should be translated into measurable design targets • It can be applied to the entire problem or any subproblem • First worry about what needs to be designed then how • It takes time to complete
- 40. Components of Houseof Quality Customer Evaluation Units Targets This Product This Product Who Whats Who vs. Whats Hows vs Hows Hows Whats vs Hows Now Now vs What How Muches Hows vs How Muches
- 42. Step 1: Whoare the customers? • To “Listen to the voice of the customer” first need to identify the customer • In most cases there are more than one customer – consumer – regulatory agencies – manufacturing – marketing/Sales Customer Evaluation Units Targets This Product This Product Who Whats Who vs. Whats Hows vs Hows Hows Whats vs Hows Now Now vs What How Muches Hows vs How Muches Customers drive the development of Customers drive the development of the product, not the designer the product, not the designer
- 43. Step 2: Determinethe customers’ requirements • Need to determine what is to be designed • Consumer – product works as it should – lasts a long time – is easy to maintain – looks attractive – incorporated latest technology – has many features Customer Evaluation Units Targets This Product This Product Who Whats Who vs. Whats Hows vs Hows Hows Whats vs Hows Now Now vs What How Muches Hows vs How Muches List all the demanded qualities at the same level of abstraction
- 44. Step 2: cont... • Manufacturing – easy to produce – uses available resources – uses standard components and methods – minimum waste • Marketing/Sales – Meets customer requirements – Easy to package, store, and transport – is suitable for display
- 45. Kano Model BasicQuality: These requirements are not usually mentioned by customers. These are mentioned only when they are Excitement absent from the product. Performance Quality: provides an Satisfiers increase in satisfaction as performance improves Excitement Quality or “wow requirements”: are often unspoken, possibly because we are seldom asked to express our dreams. Creation of some excitement features in a design differentiates the product from competition. Delighted Performance Basic Fully implemented Absent Customer Satisfaction + - Disgusted
- 46. Types of customer requirements • Functional requirements describe the product’s desired behavior • Human factors • Physical requirements • Reliability • Life-cycle concerns • Resource concerns • Manufacturing requirements
- 47. How to determine the Whats? • Customer survey (have to formulate the questions very carefully) • If redesign, observe customers using existing products • Combine both or one of the approaches with designer knowledge/experience to determine “the customers’ voice”
- 48. Step 3: DetermineRelative Importance of the Requirements: Who vs. What • Need to evaluate the importance of each of the customer’s requirements. – Generate weighing factor for each requirement by rank ordering or other methods Customer Evaluation Units Targets This Product This Product Who Whats Who vs. Whats Hows vs Hows Hows Whats vs Hows Now Now vs What How Muches Hows vs How Muches
- 49. Rank Ordering •Order the identified customer requirements • Assign “1” to the requirement with the lowest priority and then increase as the requirements have higher priority. • Sum all the numbers • The normalized weight Rank/Sum • The percent weight is: Rank*100/Sum
- 50. Step 4: Identifyand Evaluate the Competition: How satisfied is the customer now? • The goal is to determine how the customer perceives the competition’s ability to meet each of the requirements – it creates an awareness of what already exists – it reveals opportunities to improve on what already exists The design: 1. does not meet the requirement at all 2. meets the requirement slightly 3. meets the requirement somewhat 4. meets the requirement mostly 5. fulfills the requirement completely Customer Evaluation Units Targets This Product This Product Who Whats Who vs. Whats Hows vs Hows Hows Whats vs Hows Now Now vs What How Muches Hows vs How Muches
- 51. Step 5: GenerateEngineering Specifications: How will the customers’ requirements be met? • The goal is to develop a set of engineering specifications from the customers’ requirements. Restatement of the design problem and customer requirements in terms of parameters that can be measured. Each customer requirement should have at least one engineering parameter. Customer Evaluation Units Targets This Product This Product Who Whats Who vs. Whats Hows vs Hows Hows Whats vs Hows Now Now vs What How Muches Hows vs How Muches
- 52. Step 6: RelateCustomers’ requirements to Engineering Specifications: Hows measure Whats? • This is the center portion of the house. Each cell represents how an engineering parameter relates to a customers’ requirements. Customer Evaluation Units Targets This Product This Product Who Whats Who vs. Whats Hows vs Hows Hows Whats vs Hows Now Now vs What How Muches Hows vs How Muches 9 = Strong Relationship 3 = Medium Relationship 1 = Weak Relationship Blank = No Relationship at all
- 53. Step 7: IdentifyRelationships Between Engineering Requirements: How are the Hows Dependent on each other? • Engineering specifications maybe dependent on each other. Customer Evaluation Units Targets This Product This Product Who Whats Who vs. Whats Hows vs Hows Hows Whats vs Hows Now Now vs What How Muches Hows vs How Muches 9 = Strong Relationship 3 = Medium Relationship 1 = Weak Relationship -1 = Weak Negative Relationship -3 = Medium Negative Relationship -9 = Strong Negative Relationship Blank = No Relationship at all
- 54. Step 8: SetEngineering Targets: How much is good enough? • Determine target value for each engineering requirement. – Evaluate competition products to engineering requirements – Look at set customer targets – Use the above two information to set targets Customer Evaluation Units Targets This Product This Product Targets Who Whats Who vs. Whats Hows vs Hows Hows Whats vs Hows Now Now vs What How Muches Hows vs How Muches