1 / 21

Requirements Gathering

Requirements Gathering. How do we find out what we are supposed to be building?. Why good Specs are 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

nelly
Download Presentation

Requirements Gathering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Gathering How do we find out what we are supposed to be building?

  2. Why good Specs are 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

  3. Starter Questions • What is a "requirement"? • How do we determine the requirements?

  4. Types of Requirements • 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 • Explicit • ex – required features • Implied • ex – software quality • Forgotten • ex – exists in current process • Unimagined

  5. Questions • What makes a particular requirement good or bad? • Why is requirements engineering difficult?

  6. Requirements of Requirements • Clear • Measurable • Feasible • Necessary • Prioritized • Concise

  7. Req Gathering Problems • Accommodating changing reqs • Being complete, without being constraining • Conflicting views • Ease of omitting obvious info • Identifying the experts and getting authority to talk to people • Incomplete understanding of the problem on the part of the user/customer • Sticking with “what” and not “how” • Determining what is critical • Avoiding mission creep

  8. Requirements WILL Change

  9. Requirements Engineering Tasks • Inception • Elicitation • Elaboration • Negotiation • Specification • Validation • Management Software Engineering: A Practitioner’s Approach by Roger Pressman

  10. Inception • Project starts due to a business decision • Software Engineer Asks: • Why do you want this • What is the basic problem • Who wants a solution • Nature of solution • First Questions: • Who is behind the request for work? • Who will use the solution? • What will be the economic benefit of success? • Is there another source for the solution?

  11. Elicitation Methods • Interviews • Use Cases • Formal Requirement Engineering Techniques

  12. Elicitation via Interviews

  13. Elicitation via Interviews • Difficulties: • Ill-defined project scope • Unnecessary details that confuse • Not sure what they need • Poor understanding of capabilities • Omitting the “obvious” • Requirements that conflict with other people’s requirements • Requirements Change!!!

  14. Elicitation via Interviews • Recommended Practices: • The list of involved stakeholders must be broad!!! • Be sure to use real end-users. • Use agendas that cover the important points yet encourage flow of ideas • Ahead of time, the participants should build a partial list of the functions, performance criteria, environment factors, … • Start with scope and context, move to functions • Use visuals such as wall-stickers, flip-charts, … • Meetings with stakeholders should include the SwEngs

  15. Elicitation via Use Cases • Diagrams composed of Actors and Actions Logout Anonymous User Registered User Create Account Manage Account Credit Card System

  16. Elicitation via JAD Joint Application Design • JAD Sessions Participants: • Executive Sponsor • Project Leader • Facilitator – trained and experienced • Recorder • Participants • Observers – developers who sit on sideline and don’t talk • Outputs of sessions: • Data flow diagrams • Data requirements • List of assumptions • etc

  17. Elicitation via QFD Since 1966, Quality Function Deployment (QFD) has been used world wide in nearly every industry and sector to: • Prioritize spoken and unspoken customer wows, wants, and needs; • Translate these needs into actions and designs such as technical characteristics and specifications; and • Build and deliver a quality product or service by focusing various business functions toward achieving a common goal and customer satisfaction. www.qfdi.org • QFD uses interviews, surveys, and data (problem reports) to build a table of requirements called the Customer Voice Table. • Functional Deployment – value of each function • Information Deployment – identify the input and output • Task Deployment – examine system behavior • Value Analysis – prioritize the requirements

  18. Elaboration • Goal is to create a model that defines: • information • functions • Models could be • ER Diagrams • Use Cases • Data Flow Diagrams • all of the above http://www.camsp.com/cornerstone/assets/images/resources/when_use_maps_sm.png

  19. Negotiation • Goal is to resolve requirements that are • Conflicting • Costly • Unrealistic • Identify the subsystem’s stakeholders • Determine their win conditions • Negotiate their win conditions into win-win conditions for everyone

  20. Specification and Validation • Specification yields the SRS • Format of SRS is our next class • Validation reviews the SRS

  21. Review of Tonight Requirements Engineering Tasks • Inception • Elicitation • Elaboration • Negotiation • Specification • Validation • Management

More Related