Does RE Apply to Open Source Development? A requirements person's view Ian Alexander

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

© Ian Alexander 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

© Ian Alexander 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

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

© Ian Alexander 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 …

© Ian Alexander 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

© Ian Alexander Complementary Elements, Collaborative Contexts

© Ian Alexander Three kinds of Software Development A) Large-Scale Custom Development

© Ian Alexander Three kinds of Software Development B) Open Source * = informal

© Ian Alexander 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

© Ian Alexander 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

© Ian Alexander 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

© Ian Alexander 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

© Ian Alexander Scenario Plus Requirements Training Consultancy Workshop Facilitation