A Partnership for Performance

Partnership for PerformanceHow to hear this lectureClick on the icon: to hear the narration for each slide.

#1Partnership for Performancefisher.osu.eduFisher logoRequirementsDr. Rajiv RamnathDirectorCollaborative for Enterprise Transformation and Innovation (CETI)Department of Computer Science and Engineering, College of EngineeringThe Ohio State UniversityRamnath.6@osu.eduhttp://www.ceti.cse.ohio-state.edu

Partnership for Performance

#2RequirementsCollege of EngineeringThe Ohio State University

#Software requirements are the documented needs that a software system has to fulfill.3Partnership for PerformanceHow do you find requirements?Interview usersExamine value chain activitiesDo ethnographic studies:Observations (Intuit: follow-me-homes)Embedded field studiesLongitudinal researchIn-depth interviews

#Capturing Requirements Using Structured Processes

College of EngineeringThe Ohio State University

#Partnership for PerformanceSelected Structured Requirements Work-ProductsProblem statementBusiness caseStoryboardUse casesScenariosNonfunctional requirementsPrioritized requirementsAcceptance Plan

#Partnership for PerformanceRequirements Work-Products Problem StatementContent:Business domain, goals, objectives, stakeholdersWhat are we trying to accomplish, for whom, and whyNot focused on solutionHow:Written with customer, before the project begins Shared, incomplete, consensus achievedFormat:Free format text with sections such as: Objectives, Success Criteria, Itemized requirements, Stakeholders etc.

#Partnership for PerformanceProblem Statement ExcerptTheFirm 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 PerformanceRequirements Work-Products Business CaseJustification of expense - effort or monetaryViewpoint from multiple stakeholdersItemized cost estimates, including opportunity costFree formatCould include soft benefits: social, environmental, ethical and politicalStructure as: COST vs. BENEFIT

#Partnership for PerformanceExample Business Case Estimated cost:$1M, based on staffing size and estimated duration of 1 yearBenefit (over 1 year):Reduction in training costs: 1 person month per employee * turnover rate = $100,000Reduction in penalties due to errors: $250,000Increased revenue due to increased capacity from 200 cases to 250 casesCompetitive advantage due to a demonstrable assetEtc.

#Partnership for PerformanceRequirements Work-Products - StoryboardNarrativeOf how the organization would work using the system, OROf how the organization currently works

#Partnership for PerformanceRequirements Work-Products Use Case ModelCaptures functional requirementsConsists of:Actors (humans, external systems) hierarchyUse CasesExtends vs. Uses (SEE NOTES PAGE)Use Case Diagram context modelUML NotationDrives all activity - starting with analysisDrives acceptance tests

#12Partnership for PerformanceExample: Actors HierarchyActor:TheFirm EmployeeTheFirm UserIntake ProcessorTitle AdminTitle ProcessorAttorneyConsultantTitle Examiner

#13Partnership for PerformanceExample Use CasesDepartment: IntakeActors: Intake ProcessorNormal Use CasesIntake Processor Claims Case from Client SystemIntake Processor Assigns AttorneyIntake Processor Assigns Title ExaminerExceptional Use CasesChange or Correct Attorney AssignmentChange or Correct Examiner AssignmentAttorney leaves TheFirmExaminer leaves TheFirm

Useful to characterize

#Partnership for PerformanceUse Case DiagramShows context of systemSystem boundaryActorsUse case namesRelationships

#Partnership for PerformanceExample Use Case Diagram

Intake ProcessorClient SystemSystem

#Requirements Work Products: ScenariosAKA FlowUsed to refine a Use CaseOne path through a Use CaseHappy PathUnhappy pathsAssumptionsOutcome

Partnership for Performance

#Example ScenariosUse Case: Intake Processor Claims Case from Client SystemPrimary scenario (or Happy Path)Case is successfully claimedAlternate scenarios:Client system has invalid requestDuplicate case is launchedCase is incorrectly launched

Partnership for Performance

#Partnership for PerformanceRequirements Work-Products Non-Functional RequirementsAKA architecture, assurance, design requirementsVERY important - can break a projectBut cannot make it Example categories: Performance, Availability, Compatibility, Usability, Security, CostDrives DESIGN not analysisWho does this:Customer, project manager, team leaderProcess:Make it real for the system under considerationVerify coverage against use casesMust be testable

#Partnership for PerformanceExample Non-functional RequirementsPerformance:Based on studies of user attention span synchronous tasks must respond within 5s in system steady stateUsability:Prototypical LawFirm users must be able to learn to use the system within 10 daysScalability:User growth rate: +20 users per year3000 new cases per year2 new company acquisitions per year

#Partnership for PerformanceRequirements Work-Products cont.Prioritized requirementsHow to prioritize:Customer valueRiskPriority is a combination of:Importance or Business ValueVital, important, would be niceand UrgencyOther functions depend on it etcCould be coarse granularity, partitioned by use-case, or fine granularity, partitioned by scenarioDrives prioritization of Acceptance Plan and Project Management work-products

#Partnership for PerformanceRequirements Work-Products cont.Acceptance planCommits customer to a deterministic way of determining acceptanceParticipants: decision makers, stakeholdersShould include time to fix clausesLess important for internal projects

#Partnership for PerformanceExample Acceptance PlanAll functional requirements in the released system must pass acceptance testingPerformance:Based on studies of user attention span synchronous tasks must respond within 5s in system steady stateTest with:5 concurrent users10000 cases in databaseUsability:Prototypical LawFirm users must be able to learn to use the system within 10 daysTest with Joe, Sarah, Barack and JohnScalability:User growth rate: +20 users per year3000 new cases per year2 new company acquisitions per yearQuestion: How will we test these elements? Are these requirements under-specified?

#Requirements Using Agile Processes

College of EngineeringThe Ohio State University

#Partnership for PerformanceAgile Work-ProductsCustomersRoles: Intake Processor, Attorney, Title ExaminerLive people to play these roles User storiesCapture functional AND non-functional requirementsFormat: As I want so that System TestsAny work-product from a structured process, but developed in an agile wayWhiteboard sketches, photographedRef: eXtreme Programming eXPlained, Kent Beck, Safari

#Partnership for PerformanceExample Story Functional RequirementAs an Intake Processor I Evaluate a Case as follows:I am notified of a new case in the client systemI look through the case to see if it is a valid and new foreclosure caseIf it is a new foreclosure case, I can accept the case, thus preventing another company or another intake processor from claiming itIf not, I release it.so that I may Accept it for Processing or Reject itRef: User Stories Applied: For Agile Software Development, Mike Cohn, Safari

#Partnership for PerformanceExample Non-Functional Requirements Captured as StoriesAs 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 dont 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, Safarihttp://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories

#Partnership for PerformanceThank you!

#