How to hear this lecture Click on the

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

Fisher logo fisher. osu. edu 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 2

Requirements College of Engineering The Ohio State University

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 4

Capturing Requirements Using Structured Processes College of Engineering The Ohio State University

Selected Structured Requirements Work-Products • • Problem statement Business case Storyboard Use cases Scenarios Nonfunctional requirements Prioritized requirements Acceptance Plan Partnership for Performance 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. Partnership for Performance 7

Problem Statement Excerpt • The. Firm is a firm consisting of 3 business - a law firm, a title company and a processing company, doing highvolume 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 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 Partnership for Performance 9

Example Business Case • Estimated cost: • $1 M, 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 10

Requirements Work-Products - Storyboard • Narrative – Of how the organization would work using the system, OR – Of how the organization currently works Partnership for Performance 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 Partnership for Performance 12

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

Example Use Cases Department: Intake Actors: Intake Processor Normal Use Cases 1. 2. 3. Intake Processor Claims Case from Client System Intake Processor Assigns Attorney Intake Processor Assigns Title Examiner Exceptional Use Cases 1. 2. 3. 4. Useful to characterize Change or Correct Attorney Assignment Change or Correct Examiner Assignment Attorney leaves The. Firm Examiner leaves The. Firm Partnership for Performance 14

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

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

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

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 19

Example Non-functional Requirements • Performance: • Based on studies of user attention span synchronous tasks must respond within 5 s in system steady state • Usability: • Prototypical Law. Firm 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 20

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 21

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 22

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 5 s in system steady state • Test with: • – 5 concurrent users – 10000 cases in database • Usability: • Prototypical Law. Firm 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 23

Requirements Using Agile Processes College of Engineering The Ohio State University

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 I want so that • • System Tests • Any work-product from a structured process, but developed in an agile way • Whiteboard sketches, photographed Ref: e. Xtreme Programming e. XPlained, Kent Beck, Safari Partnership for Performance 25

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 26

Example Non-Functional Requirements Captured as Stories • As a The. Firm User, I want to be able to run your product on all versions of Windows from Windows 95 on. • As the The. Firm 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 The. Firm User, I want the program to be available from 8 am to 6 pm Mondays through Fridays. • As The. Firm 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 27

Thank you! Partnership for Performance 28