1 / 30

Effective Requirements Gathering in Software Development

Learn how to find and capture requirements for new software systems by analyzing business domains, conducting user interviews, and creating work products such as problem statements, business cases, storyboards, and use case models.

taniel
Télécharger la présentation

Effective Requirements Gathering in Software Development

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 Rajiv Ramnath Director CERCS for Enterprise Transformation and Innovation (CETI)

  2. Learning Outcomes Requirements

  3. Definition of Requirements The needs or conditions that a new or altered software system must meet, taking into account the possibly conflicting perspectives of the various stakeholders. Requirements

  4. How do you find and capture requirements? • Domain and Problem Analysis • Analyze a piece of the business • Examine value chain activities • Develop Balanced Scorecards • Examine existing business processes and transactions • User and domain expert interviews • “Ethnographic” studies: • Field observations, studies and interviews (Intuit: “follow-me-homes”: http://blog.intuit.com/trends/what-is-a-follow-me-home/) • Could be “longitudinal” • Requirements are then captured - in work-products, or as tacit knowledge Requirements

  5. Requirements Work Products Requirements

  6. Requirements Work Products – Problem Statement • Content: • Business domain, goals, objectives, stakeholders • What are we trying to accomplish, for whom, and why • Not focused on solution • How: • Written with customer, before the project begins • Shared, incomplete, consensus achieved • Format: • Free format text with sections such as: Objectives, Success Criteria, Itemized requirements, Stakeholders etc. Requirements

  7. Problem Statement Excerpt • TheFirm is a firm consisting of 3 business - a law firm, a title company and a processing company, doing high-volume legal work, charging fixed fees and with a larger ratio to staff vs. attorneys. • A high-volume foreclosure law firm is different from a regular law firm; it cannot rely upon the attorney to get the work done. The high-volume law firm is dependent on its case management system to keep track of the cases and to identify what must be done in those cases and when. We are a high-volume law firm. • As a result, we need an automated workflow system, one that tells the user what needs to be done and when. We need a system that allows us to handle the volume of cases with consistency, high quality and efficiency, and integrated with the systems and processes of our customers. Requirements

  8. Requirements Work Products – Business Case • Justification of expense - effort or monetary • Viewpoint from multiple stakeholders • Itemized cost estimates, including opportunity cost • Free format • Could include soft benefits: social, environmental, ethical and political • Structure as: COST vs. BENEFIT Requirements

  9. Example Business Case • Estimated cost: • $1M, based on staffing size and estimated duration of 1 year • Estimated Benefit (over 1 year): • Reduction in training costs: 1 person month per employee * turnover rate = $100,000 • Reduction in penalties due to errors: $250,000 • Increased revenue due to increased capacity from 200 cases to 250 cases • Competitive advantage due to a demonstrable asset • Etc. Requirements

  10. Requirements Work Products – Storyboard • Narrative • Of how the organization would work using the system, OR • Of how the organization currently works Requirements

  11. Requirements Work Products –Use Case Model • Captures functional requirements • Consists of: • Actors (humans, external systems) hierarchy • Use Cases • Extends vs. Uses (SEE NOTES PAGE) • Use Case Diagram – context model • UML Notation • Drives all activity - starting with analysis • Drives acceptance tests Requirements

  12. Example: Actors Hierarchy • Actor: • TheFirm Employee • TheFirm User • Intake Processor • Title Admin • Title Processor • Attorney • Consultant • Title Examiner Requirements

  13. Example Use Cases • Department: Intake • Actors: Intake Processor • Normal Use Cases • Intake Processor Claims Case from Client System • Intake Processor Assigns Attorney • Intake Processor Assigns Title Examiner • Exceptional Use Cases • Change or Correct Attorney Assignment • Change or Correct Examiner Assignment • Attorney leaves TheFirm • Examiner leaves TheFirm Requirements

  14. Use Case Diagram • Shows “context” of system • System boundary • Actors • Use case names • Relationships Requirements

  15. Example Use Case Diagram Intake Processor Client System Requirements

  16. Requirements Work Products - Scenarios • Also known as Flows • Used to refine a Use Case • One path through a Use Case • Happy Path • Unhappy paths • Assumptions • Outcomes Requirements

  17. Example Scenarios • Use Case: Intake Processor Claims Case from Client System • Primary scenario (or Happy Path) • Case is successfully claimed • Alternate scenarios: • Client system has invalid request • Duplicate case is launched • Case is incorrectly launched Requirements

  18. Requirements Work Products –User Stories • Used to capture functional AND non-functional requirements • Format: As an <actor> I want to <action> to achieve <outcome> Requirements

  19. Example Story –Functional Requirement • As an Intake Processor I Evaluate a Case as follows: • I am notified of a new case in the client system • I look through the case to see if it is a valid and new foreclosure case • If it is a new foreclosure case, I can accept the case, thus preventing another company or another intake processor from claiming it • If not, I release it. • so that I may Accept it for Processing or Reject it Requirements

  20. Requirements Work Products –Non-Functional Requirements • Also known as architectural, assurance, or design requirements • VERY important - can break a project • But cannot make it  • Example categories: Performance, Availability, Compatibility, Usability, Security, Cost • Drives DESIGN not analysis • Who does this: • Customer, project manager, team leader • Process: • Make it “real” for the system under consideration • Verify coverage against use cases • Must be testable Requirements

  21. Example Non-Functional Requirements • Performance: • Based on studies of user attention span synchronous tasks must respond within 5s in system steady state • Usability: • Prototypical LawFirm users must be able to learn to use the system within 10 days • Scalability: • User growth rate: +20 users per year • 3000 new cases per year • 2 new company acquisitions per year Requirements

  22. Example Non-Functional Requirements Captured as Stories • As a TheFirm User, I want to be able to run your product on all versions of Windows from Windows 95 on. • As the TheFirm Systems Administrator, I want the system to use our existing orders database rather than create a new one sot that we don’t have one more database to maintain. • As a TheFirm User, I want the program to be available from 8 am to 6 pm Mondays through Fridays. • As TheFirm Partner, we might want to sell this product internationally. Reference: User Stories Applied: For Agile Software Development, Mike Cohn, Safari http://is.gd/eyzsl5 Requirements

  23. Requirements Work Products – Prioritized Requirements • Prioritized requirements • How to prioritize: • Customer value • Risk • Priority is a combination of: • Importance or Business Value • Vital, important, would be nice • and Urgency • Other functions depend on it etc • Could be coarse granularity, partitioned by use-case, or fine granularity, partitioned by scenario • Drives prioritization of Acceptance Plan and Project Management work-products Requirements

  24. Requirements Work Products – Acceptance Plan • Acceptance plan • Commits customer to a deterministic way of determining acceptance • Participants: decision makers, stakeholders • Should include time to fix clauses • Less important for internal projects Requirements

  25. Example Acceptance Plan • All functional requirements in the released system must pass acceptance testing • Performance: • Based on studies of user attention span synchronous tasks must respond within 5s in system steady state • Test with: • 5 concurrent users • 10000 cases in database • Usability: • Prototypical LawFirm users must be able to learn to use the system within 10 days • Test with Joe, Sarah, Barack and John • Scalability: • User growth rate: +20 users per year • 3000 new cases per year • 2 new company acquisitions per year • Question: How will we test these elements? Are these requirements under-specified? Requirements

  26. Agile Processes and Requirements • Live users (serve as tacit holders of requirements) • User stories • System tests • Any work-product from a structured process, but developed in an agile way • E.g. Whiteboard sketches Reference: Beck, K. Extreme Programming eXplained: Embrace Change. Safari. Requirements

  27. Use Case Sketch Partnership for Performance

  28. What have we learned? Requirements

  29. References • Developing Object-Oriented Software – An Experience-Based Approach (online): • Chapters 9 on Requirements – REQUIRED Requirements

  30. Thank you! Requirements

More Related