How to hear this lecture

1. How to hear this lecture Click on the icon: to hear the narration for each slide. Partnership for Performance

2. fisher.osu.edu Fisher logo Requirements Dr. Rajiv Ramnath Director Collaborative for Enterprise Transformation and Innovation (CETI) Department of Computer Science and Engineering, College of Engineering The Ohio State University Ramnath.6@osu.edu http://www.ceti.cse.ohio-state.edu Partnership for Performance Partnership for Performance

3. Requirements

4. How do you find requirements? • Interview users • Examine value chain activities • Do “ethnographic” studies: • Observations (Intuit: “follow-me-homes”) • Embedded field studies • “Longitudinal” research • In-depth interviews Partnership for Performance

5. Capturing Requirements Using Structured Processes

6. Selected Structured Requirements Work-Products • Problem statement • Business case • Storyboard • Use cases • Scenarios • Nonfunctional requirements • Prioritized requirements • Acceptance Plan Partnership for Performance

7. 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. Partnership for Performance

8. 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. Partnership for Performance

9. 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 Partnership for Performance

10. Example Business Case • Estimated cost: • $1M, based on staffing size and estimated duration of 1 year • 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. Partnership for Performance

11. Requirements Work-Products - Storyboard • Narrative • Of how the organization would work using the system, OR • Of how the organization currently works Partnership for Performance

12. 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 Partnership for Performance

13. Example: Actors Hierarchy • Actor: • TheFirm Employee • TheFirm User • Intake Processor • Title Admin • Title Processor • Attorney • Consultant • Title Examiner Partnership for Performance

14. 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 Useful to characterize Partnership for Performance

15. Use Case Diagram • Shows “context” of system • System boundary • Actors • Use case names • Relationships Partnership for Performance

16. Example Use Case Diagram Intake Processor Client System System Partnership for Performance

17. Requirements Work Products: Scenarios • AKA Flow • Used to refine a Use Case • One path through a Use Case • Happy Path • Unhappy paths • Assumptions • Outcome Partnership for Performance

18. 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 Partnership for Performance

19. Requirements Work-Products – Non-Functional Requirements • AKA architecture, assurance, 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 Partnership for Performance

20. 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 Partnership for Performance

21. Requirements Work-Products cont. • 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 Partnership for Performance

22. Requirements Work-Products cont. • 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 Partnership for Performance

23. 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? Partnership for Performance

24. Requirements Using Agile Processes

25. Agile Work-Products • Customers • Roles: Intake Processor, Attorney, Title Examiner • Live people to play these roles • User stories • Capture functional AND non-functional requirements • Format: As <role> I want <goal> so that <outcome> • System Tests • Any work-product from a structured process, but developed in an agile way • Whiteboard sketches, photographed Ref: eXtreme Programming eXPlained, Kent Beck, Safari Partnership for Performance

26. 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 Ref: User Stories Applied: For Agile Software Development, Mike Cohn, Safari Partnership for Performance

27. 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. Ref: User Stories Applied: For Agile Software Development, Mike Cohn, Safari http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories Partnership for Performance

28. Thank you! Partnership for Performance