Introduction to Customer Requirements Colin Potts Georgia Tech

Introduction to Customer Requirements Colin Potts Georgia Tech © Colin Potts A-1

What this course is about l Approaches to defining, managing and analyzing requirements for softwareintensive information systems and products © Colin Potts A-2

Who this course is for l Roles » IS or software developers » IS or software project management » Product conception, marketing or contract experts © Colin Potts l Activities » How to define » How to reach agreement » What questions to ask » How to document thoroughly » How to model » How to manage A-3

Why the subject is important l Misunderstood requirements lead to poor-quality products » Misunderstood requirements are very expensive to correct » If not corrected, misunderstood requirements can doom a product l Requirements are underemphasized in engineering and business education © Colin Potts A-4

Course objectives Introduce a representative selection of techniques to understand manage requirements l Afterward, you should be able to: l » Apply these techniques in practice » Choose the right ones for your organization and integrate them into a coherent process » Know how to find out more © Colin Potts A-5

What are requirements? l Properties of a planned system or product that are desired by its customer » What kinds of properties? – Functional / quality requirements » What is the scope of the system? – System / environment; software / process » Are requirements absolute? What if they conflict? – Requirements / preferences » Who are the customers? What if they disagree? – Stakeholders / viewpoints. Trade-offs / negotiation © Colin Potts A-7

“Is” and “Ought” statements l “Is” statements » What is the case (true or false) » “Standard office hours are between 8 am and 6 pm” l “Ought” statements » What is desired (worthwhile or not) » “The MSS shall select the earliest schedulable time for the meeting within standard office hours” © Colin Potts A-8

A graphical “statement” l Is this “statement” about what is the case or what is required? » Does it describe the way things are in the host organization (a library) or a new policy that the system should enforce? © Colin Potts Library patron (0, 1) borrows (0, 6) Book A-9

Requirements-related activities l Requirements definition » Discovering and recording requirements l Requirements management » Keeping track of dependencies among requirements & design decisions l Requirements analysis and validation » Checking for consistency, desirability and feasibility © Colin Potts A-10

Requirements management and process maturity 5: Optimizing SEI CMM levels 4: Managed 3: Defined 2: Repeatable Key practices: - requirements management - project planning - project tracking & oversight - subcontract mgt. - quality assurance - configuration management 1: Initial © Colin Potts A-11

CMM Requirements Management: key practices l Goals l » Software reqts. are baselined » Reqts. are honored l l » Review reqts. before incorporation » Base product on reqts. » Review & incorporate changes Commitment » Organizational policy exists for managing reqts. l © Colin Potts Measurements » Keep track of reqts. mgt. activities Abilities » Responsibility for managing reqts. » Reqts. are documented » Resources are available for reqts. mgt. » Staff are trained in reqts-related responsibilities Activities l Verifications » Sr. mgt. periodically reviews reqts. mgt. procedures » Project mgt. regularly reviews reqts. mgt. procedures » SQA reviews & audits process & products A-12

Requirements and system fitness l Well-understood requirements © Colin Potts l Poorly understood requirements A-13

Requirements and the system lifecycle l “What” vs. “How” Vague ideas l Product Spec. Reqts. Design (“What”) (“How”) Requirements, prototypes and system evolution Vague ideas © Colin Potts Devt. (incl. prototyping) Product Firmer ideas A-14

Customer relationships system © Colin Potts . . (much later) system/ service product idea Developer reqts. Developer detailed reqts. Customer proposal request for help Developer Customer solicitn. Market-based Proxy Customer In-house Actual Market Contractual product/ service A-15

Engineering and human-oriented approaches l Requirements occur at boundary between the human and the engineered » “Soft” and “hard” / “Wet” and “dry” l Human-oriented issues » Understanding the system’s context, reaching consensus, tracking issues, etc. l Engineering-oriented issues » Documentation quality, modeling, feasibility analysis, etc. © Colin Potts A-16

Requirements: How to find out more l General texts » Davis: Software Requirements » Macaulay: Requirements Engineering » Wieringa: Requirements Engineering l Readings » Jirotka & Goguen, Reqts. Engineering » Thayer & Dorfman, IEEE Tutorial (2 vols) © Colin Potts A-17