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

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

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

4. © Colin Potts A-4 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

5. © Colin Potts A-5 Course objectives l Introduce a representative selection of techniques to understand and manage requirements l Afterward, you should be able to: »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

6. © Colin Potts A-6 Course outline l Day 1 »Introduction to requirements »Human-oriented techniques –Organizational –Team-based –Ethnographic –Marketing-based l Day 2 »Engineering techniques –Documentation –Objectives-based techniques and trade- off analysis –Process-oriented and information-oriented techniques –Future trends »Conclusions

7. © Colin Potts A-7 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

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

9. © Colin Potts A-9 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? Book Library patron borrows (0,1) (0,6)

10. © Colin Potts A-10 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

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

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

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

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

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

16. © Colin Potts A-16 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.

17. © Colin Potts A-17 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)