Requirements & Challenges: Status and Open Questions

1. Requirements & Challenges:Status and Open Questions Hilmar LappNational Evolutionary Synthesis Center DRIADE Workshop, Dec 5, 2006

2. The Four Virtues

3. Challenges vs Virtues

4. Requirements • “[…] a singular documented need of what a particular product or service should be or do.” quoted from Wikipedia • Requirements gathering is only one step • e.g., preceded by conceptual analysis • e.g., followed by requirements analysis • Requirements are divided into types • Functional - things a system must do • Non-functional - properties a system must have • Constraints - implementation limits

5. Good requirements are … • Necessary – must be included or an important feature or property will be missing • Unambiguous – only one interpretation. • Concise – brief and easy to read, yet conveys the essence of what is required. • Consistent – does not contradict other requirements and uses language consistent with other requirements. • Complete – stated entirely in one place. • Reachable – implementation is feasible. • Verifiable – must be able to determine that the requirement has been met. based on Wikipedia

6. Requirements are central • Ensure an engineered system meets the expectations of users and stakeholders. • Determine the features a system will have. • Determine which challenges must be overcome, and to which extent. • Can be prioritized to determine the order • in which features are developed • in which challenges are addressed

7. Gathering Requirements • Costs a significant amount of time • for both the engineer and user or stakeholder. • This time can be wasted if the requirements • are later ignored, or • change before the implementation completes. • Adaptive gathering depth • Gather details on recognizably invariant (‘hard’) requirements • Use agile approach (get the bottom line, then iterate) for those anticipated to change

8. Expressing Requirements • Stating ‘good’ requirements is an engineering art, not a common trait • ‘Use cases’ and ‘user stories’ provide the bridge • Expressed in common language • Need not be concise, unambiguous, complete etc. • Reflect expectations of the user or stakeholder, or a hypothetical scenario from a user perspective • Engineers will transform a set of use cases into requirements (which may require iteration)

9. Use case example • Use case: Submitting a paper with suppl. material. “Author will be taken to the repository to upload her suppl. data in status ‘pending publication’, one file at a time. After uploading, the repository issues a receipt token confirming the deposition. The paper submission site will accept the receipt token for the user to complete the submission.” • User story: “I go to the repository to upload the data for a paper I’m submitting, consisting of a file of sequences, and a series of morphological images for N taxa. The results are summarized in a phylogenetic tree with bootstrap values and a table. The repository lets me upload every file, asks pertinent question about what the data is in the file, who created it, and how it was obtained. It then goes ahead and deposits the sequences in Genbank, the images in MorphBank, and the tree in TreeBase. It returns to me the accession numbers for each of those submissions, and the accession number for the data table.”

10. Role for Journals and Soc. • Scope of repository is published data, hence • Journals are the major stakeholder • Authors will be the major users • Need to gather requirements of journals for • Submission process • Data preservation • Data access • Need help in gathering requirements for creating an incentive for authors to comply • Often opportunities can be better gleaned from behavior than elicited through interviewing