300 likes | 376 Views
Requirements. Rajiv Ramnath Director CERCS for Enterprise Transformation and Innovation (CETI). Learning Outcomes. Definition of Requirements. The needs or conditions that a new or altered software system must meet, taking into account the possibly conflicting perspectives
E N D
Requirements Rajiv Ramnath Director CERCS for Enterprise Transformation and Innovation (CETI)
Learning Outcomes Requirements
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
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
Requirements Work Products Requirements
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
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
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
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
Requirements Work Products – Storyboard • Narrative • Of how the organization would work using the system, OR • Of how the organization currently works Requirements
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
Example: Actors Hierarchy • Actor: • TheFirm Employee • TheFirm User • Intake Processor • Title Admin • Title Processor • Attorney • Consultant • Title Examiner Requirements
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
Use Case Diagram • Shows “context” of system • System boundary • Actors • Use case names • Relationships Requirements
Example Use Case Diagram Intake Processor Client System Requirements
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
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
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
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
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
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
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
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
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
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
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
Use Case Sketch Partnership for Performance
What have we learned? Requirements
References • Developing Object-Oriented Software – An Experience-Based Approach (online): • Chapters 9 on Requirements – REQUIRED Requirements
Thank you! Requirements