Understanding Requirements: Lessons from FreeOpen Source Software Development Projects

1
Understanding Requirements
Lessons from Free/Open Source Software
Development Projects

• Walt Scacchi
• Institute for Software Research
• University of California, Irvine
• Irvine, CA 92697-3455 USA
• http//www.ics.uci.edu/wscacchi

2
(No Transcript)
3
BG Justice, Open Source Software Challenges
Delivering Warfighter Value, Mar 07.
4
F/OSS processes for Requirements/Design

• F/OSS Requirements/Designs are
• not explicit
• not formal
• F/OSS Requirements/Designs are embedded within
  informalisms
• Example F/OSS informalisms will follow, but
  first, the F/OSS requirement process

5
F/OSS processes for Requirements

• Post-hoc assertion of requirementsdesign after
  implementation
• Reading, sense-making, accountability
• Continually emerging webs of discourse
• Condensing and hardening discourse
• Global access to this discourse

6
(No Transcript)
7
(No Transcript)
8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
11
Traditional vs. F/OSS processes for Requirements

• Elicitation
• Analysis
• Specification and modeling
• Validation
• Communicating and managing

• Post-hoc assertion
• Reading, sense-making, accountability
• Continually emerging webs of discourse
• Condensing and hardening discourse
• Global access to discourse

12
Software Informalisms

• Community communications
• Threaded discussion forums
• Email (list servers)
• Newsgroups
• IRChat/Instant messages
• Developer blogs
• Community digests (Kernel Traffic)

13
(No Transcript)
14
Software Informalisms

• Scenarios of Usage as linked Web pages

15
Software Informalisms

• How-To guides, To-Do lists, FAQs
• Traditional software user documentation
• Unix/Linux man pages
• External publications
• trade articles
• scholarly research papers
• books (cf. OReilly Books)

16
Software Informalisms

• F/OSS Web Sites
• Community Web sites
• Community Software Web sites
• Project Web sites
• Project Wikis
• Source code Webs/Directories

17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
(No Transcript)
21
Software Informalisms

• Software bug reports
• Ad hoc report Web
• Bugzilla (database tracking)
• Issue tracking
• Issuezilla

22
(No Transcript)
23
Software Informalisms

• Software extension mechanisms
• Inter-application scripting
• Csh, Perl, Python, Tcl scripting
• Pipelines (cf. CXCDS)
• Intra-application scripting (e.g., UnrealScript)
• Plug-in architectures
• Apache server architecture

24
Software Informalisms

• Free/OSS licenses institutionalizing F/OSS
  culture (values, norms, and beliefs)
• GNU Public License (GPL)
• BSD, and more than 60 others (http//opensource.or
  g)
• Creative Commons Project at Stanford Law School
  developing public license framework

25
(No Transcript)
26
Implications

• Software informalisms are the media of software
  requirements/design
• Software informalisms are the subject of software
  requirements/design
• F/OSS requirements/design tasks are implied
  activities or capabilities
• (Re)reading, reviewing, and reinterpreting
  informalisms is a prerequisite to writing OSS.

27
Implications

• Developing F/OSS requirements is a community
  building process
• not just a technical development process
• F/OSS peer review creates a community of peers
• F/OSSD processes often iterate daily versus
  infrequent singular (milestone) SLC events
• frequent, rapid cycle time (easier to improve)
  vs. infrequent, slow cycle time
  (hard to improve)

28
Implications

• Determining the quality of F/OSS
  requirements/designs
• not targeted to consistency, completeness,
  correctness
• instead focusing attention to
• community building
• freedom of expression
• ease of informalism navigation (traceability),
• implicit vs. explicit informalism structuring

29
Implications

• F/OSS requirements are decentralized
• Requirements are distributed across many software
  informalisms, not in a single document
• Requirements decentralization is a strategy for
  demonstrating commitment to project effort
• F/OSS requirements are retrospective
• Perhaps we need to start to address software
  system provisions
• Provisions -- that which is provided rather than
  requested