how to hear this lecture

1Partnership for Performance

How to hear this lecture

Click on the icon: to hear the narration for each slide.


fisher.osu.edu

Fisher logoRequirements

Dr. Rajiv RamnathDirector

Collaborative for Enterprise Transformation and Innovation (CETI)Department of Computer Science and Engineering, College of EngineeringDepartment of Computer Science and Engineering, College of Engineering

The Ohio State UniversityThe Ohio State University

[email protected]@osu.edu

http://www.ceti.cse.ohio-state.eduhttp://www.ceti.cse.ohio-state.edu

Partnership for PerformancePartnership for Performance

College of EngineeringThe Ohio State University

Requirements


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


Capturing Requirements Using Structured Processes


Selected Structured Requirements Work-Products

• Problem statement• Business case• Storyboard• Use cases• Scenarios• Nonfunctional requirements• Prioritized requirements• Acceptance Plan


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.


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 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


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.


Requirements Work-Products - Storyboard

• Narrative– Of how the organization would work using the

system, OR– Of how the organization currently works


Requirements Work-Products – Use Case Model

Captures functional requirementsConsists 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 analysisDrives acceptance tests


Example: Actors Hierarchy

• Actor:• TheFirm Employee

–TheFirm User–Intake Processor–Title Admin–Title Processor–Attorney

• Consultant–Title Examiner


Example Use Cases

Department: IntakeActors: Intake ProcessorNormal Use Cases

1. Intake Processor Claims Case from Client System2. Intake Processor Assigns Attorney3. Intake Processor Assigns Title Examiner

Exceptional Use Cases1. Change or Correct Attorney Assignment2. Change or Correct Examiner Assignment3. Attorney leaves TheFirm4. Examiner leaves TheFirm

Useful to characte

rize


Use Case Diagram

•Shows “context” of system

–System boundary–Actors–Use case names–Relationships


Example Use Case Diagram

Intake Processor

Client System

System

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


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


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 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


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


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 Using Agile Processes


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


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


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, Safarihttp://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories


Thank you!

how to hear this lecture

Documents