1. Does RE Apply to Open Source Development? A requirements person's view Ian Alexander http://www.scenarioplus.org.uk

2. © Ian Alexander 20092 Cathedral vs Bazaar Classical Software Development or Open Source O'Reilly, 2001

3. © Ian Alexander 20093 Cathedral vs Bazaar Classical SW Development shaped / scarred by "the software crisis" deliberate, thorough, carefully documented "carefully crafted by individual wizards or small bands of mages working in splendid isolation" Eric Raymond

4. © Ian Alexander 20094 Cathedral vs Bazaar Open Source shaped / scarred by painful experience of closed software, strict hierarchy, slow response "a great babbling bazaar of differing agendas and approaches" Eric Raymond

5. © Ian Alexander 20095 RE for OSD? 1.How to compare RE processes? 2.Three kinds of Software Development 3.What is Distinctive about OSD?

6. © Ian Alexander 20096 1.How to compare RE processes? Al Davis: –201 Principles of Software Development ! Kotonya & Sommerville: –a set of "Requirements Engineering Processes" Beyer & Holtzblatt: –Contextual Design (5 major processes) … etc …

7. © Ian Alexander 20097 Competing RE Processes? Process BasisHow it Describes NeedSchools of ThoughtDisadvantages Stakeholder Analysis Political, economic, social, and cultural drivers Soft Systems MethodologyUnverifiable; unsuitable for contracts Goal ModellingSays what stakeholders want KAOS; i* Ignores timing relationships (scenarios) between goals Event-Driven Analysis Identifies events at interfaces Event-Driven methodsIgnores soft systems issues and conflicting stakeholder goals Scenario Analysis Says how design will deliver results to humans Cockburn-style Use Cases; Agile (user stories) Over-emphasises behaviour; ignores non-functional aspects Standards & Templates Defines typical non- functional requirements Standardization, Regulation, Quality Assurance Does not cover functions and innovative behaviour Rationale Modelling Explains why design is needed (eg for safety) Compendium; GSN, CAE (for safety) Ignores timing; risk of rationalizing an already-chosen solution Data Modelling Defines data, rules and relationships UML class modelling; entity- relationship modelling Lack of end-to-end vision, context, purpose MeasurementShows what results the design must provide Traditional “The system shall…” requirements Whole burden carried by text; lack of context, scenarios Priorities, Trade-offs Most profitable or most needed features Business Case; Benefit/Cost Analysis; Value Engineering Ignores context, purpose, qualities, constraints, non-financial aspects

8. © Ian Alexander 20098 Complementary Elements, Collaborative Contexts

9. © Ian Alexander 20099 2. Three kinds of Software Development A) Large-Scale Custom Development

10. © Ian Alexander 200910 2. Three kinds of Software Development B) Open Source * = informal

11. © Ian Alexander 200911 2. Three kinds of Software Development C) Managing a Product Line Biological EvolutionProduct Evolution MutationInvention of Features SpeciesProduct Natural Selection by survival of the fittest individuals Selection by purchase of the most popular types of product IndividualProduct Variant Speciation by evolution of isolated populations Creation of new Products by choice of combinations of new and existing Features www.nokiamuseum.com

12. © Ian Alexander 200912 3. What is Distinctive about OSD? Custom SystemProduct-LineOpen-Source Source of Requirements Client and other stakeholders Mass-market Stakeholder Roles Analysts, developers, testers, user representatives, safety specialists, etc Product Managers, developers, testers, etc (Volunteer) developers, interested users Documentation‘User’ and ‘System’ requirements documents, test specifications, etc Product requirements, business case, etc Informal communications, Wikis, discussion groups OrganizationClient, ContractorProduct CompanyFreelance, etc FundingDevelopment and Maintenance Contracts CapitalPossibly none; (small- scale) sponsorship, etc Key Requirement Elements Scenarios, MeasurementsGoals, Trade-Offs Goals Key Discovery Contexts Interviews, Workshops, Reuse, etc Prototyping, Observation, etc Internet-mediated dialogue

13. © Ian Alexander 200913 RE for OSD? Parallels with product line RE Distinctively informal Evolution by natural (market) selection Successes, eg Mozilla Can be commercial (eg Linux) Origins: introspection not elicitation –assumes user is like developer –less true as usage widens

14. © Ian Alexander 200914 Future of RE for OSD Wider market, more commercial More need for discovering requirements Heavily-structured RE "not any time soon" But, will need clear requirements to work from

15. © Ian Alexander 200915 Scenario Plus Requirements Training Consultancy Workshop Facilitation www.scenarioplus.org.uk