# Requirements Document

## 1 INTRODUCTION

This document defines the requirement for the Phylogeny Explorer program that is being developed. The purpose of this document is to represent the system requirements in a readable way so that clients and stakeholders can understand them and verify them for correctness but with enough detail that developers can design and implement a software system from them.

This document doesn’t address _project_ issues such as schedule, cost, development methods, development phases, deliverables and testing procedures. Those are addressed in a separate project overview.

### 1.1 Overview

It is ‘A visual, navigable, online encyclopedia of the entire evolutionary tree of life.’

As a source of high quality information related to evolutionary biology, which will be taken over by specialists and be used as a resource for science, teachers and students alike, the goal will never be complete, as long as new nodes and fossils are discovered, but given that knowledge, it will be a/the primary source and resource of related information, and for a wide (not just specialists), inclusive (SEND/age/academic ability friendly), international
(multi-lingual) audience of varied user types, from schools and the general public, students, teachers and specialists alike, by use of dedicated dashboards. It will also, as far as possible, be free to all and non-profit. It will be closely linked to an on-line school, biological on-line, ‘theme park’ and a range of other edutainment type resources and links to clubs, a shop, societies, outings, visits, presentations and related. To exemplify the primary functions/features, one will be able to examine, evidentially, the relationship between all of life, and trace any aspect of it.

The Phylogeny Explorer system is a web-based tool that will be an educational, scientific, evidence based academic source of information about the evolution and relationship of all life, logged onto a visual map as a resource for everyone to see, use and enjoy for free, from specialists, researchers, teachers, students, schools and the wider public. It is unique, scholarly, and aimed at being a one stop location for this aspect of biology.

### 1.2 Goals and Objectives

Making the goals and objectives of the product explicit guides developers and gives direction to the project. During the development of even a small system, developers make hundreds of tiny decisions (consciously and unconsciously) not specifically addressed by the formal requirements. Knowing the goals and objectives will help them make the best decisions for the product.

Goals and objectives also help keep the project on track. Without a clear set of goals and objectives the scope of the project can grow or shift as new information arrives. Shifting the focus of the project isn’t bad if it is done open and explicitly with everyone in agreement.

The three main goals of the Phylogeny Explorer are:

<ol>
<li>
<span style="font-weight: bold;">
Provide a simple, feature rich view of the tree of life with multiple views of the data including the following. All these views will be filterable by various methods:
</span>
<ol style="list-style-type: lower-alpha;">
<li>A navigable tree view with the ability to navigate forwards and backwards along the branches, drill into more detailed views.
</li>
<li>Tabular views with the ability to sort the view and download in various formats.
</li>
<li>Graphical views showing the nodes place on the geologic time scale.
</li>
<li>Additional graphic notations including such things as a picture of how the earth looked at the time the nodes existed.
</li>
</ol>
</li>
<li>
<span style="font-weight: bold;">
Provide a robust mechanism for trained data entry personal to maintain the data including adding, editing, rearranging and deleting nodes:
</span>
<ol style="list-style-type: lower-alpha;">
<li>Ability to upload data in various standard formats.
</li>
<li>All changes to the data should be fully logged including who, when, and what was done.
</li>
</ol>
</li>
<li style="font-weight: bold;">
Provide an administrative system to allow the systems administrators to control all aspects of the system including security, data validation, and statistical reporting.
</li>
</ol>

### 1.3 Scope

The scope defines the boundaries of the product – what it will and will not do. Clients and other stakeholders need a clear understanding what to expect. It’s at the boundaries of the system where there is the most opportunity for misunderstandings regarding what is and is not going to be implemented.

The Requirements described below do specify exactly what will be included in the system; however, it is not presented in a way that makes clear functionality at the boundaries of the system.

### 1.4 Definitions

This section defines potentially unfamiliar or ambiguous words, acronyms and
abbreviations. If terms such as “shall”, “should” and “may” are used to indicate importance
the meaning of these terms should be defined here.

#### 1.4.1 Process Definitions

<style>
td:first-child {
font-weight: bold;
white-space: nowrap;
}
</style>

<table>
<tr>
<td>Use case</td>
<td>Describes a goal-oriented interaction between the system and an actor. A use case may define several variants called scenarios that result in different paths through the use case and usually different outcomes.</td>
</tr>
<tr>
<td>Scenario</td>
<td>One path through a use case.</td>
</tr>
<tr>
<td>Actor</td>
<td>User or other software system that receives value from a use case.</td>
</tr>
<tr>
<td>Role</td>
<td>Category of users that share similar characteristics.</td>
</tr>
<tr>
<td>Product</td>
<td>What is being described here; the software system specified in this document.</td>
</tr>
<tr>
<td>Project</td>
<td>Activities that will lead to the production of the product described
here. Project issues are described in a separate project plan.</td>
</tr>
<tr>
<td>Shall</td>
<td>Adverb used to indicate importance; indicates the requirement is
mandatory. “Must” and “will” are synonyms for “shall”.</td>
</tr>
<tr>
<td>Should</td>
<td>Adverb used to indicate importance; indicates the requirement is
desired but not mandatory.</td>
</tr>
<tr>
<td>May</td>
<td>Adverb used to indicate an option. For example, “The system may be
taken offline for up to one hour every evening for maintenance.” Not
used to express a requirement, but rather to specifically allow an
option.</td>
</tr>
<tr>
<td>Control</td>
<td>The individual elements of a user interface such as buttons and check
boxes.</td>
</tr>
<tr>
<td>User Story</td>
<td></td>
</tr>
<tr>
<td>Epic</td>
<td></td>
</tr>
</table>

#### 1.4.2 Project Specific Definitions

<table>
<tr>
<td>Node</td>
<td></td>
</tr>
<tr>
<td>Clade</td>
<td></td>
</tr>
<tr>
<td>Nodes</td>
<td></td>
</tr>
<tr>
<td>Ancestor</td>
<td></td>
</tr>
</table>

### 1.5 Document Conventions

This section describes presentation conventions use in the document.

Portions of this document that are incomplete will be marked with TBD. Each TBD item will have an owner and estimated date for resolving the issue.

### 1.6 Assumptions

In this section list any assumptions on which the requirements, as they are described here, depend. Assumptions are conditions, usually outside the control of the performing organization, that are taken for granted.

Be careful to only document assumptions that are outside the control of the performing organization. For example, the following is not a valid assumption for the requirements document: “We assume that all requirements will be documented.” You might be _assuming_ this but there is no point in documenting it as an assumption here because it is something that is primary within the scope and control of the performing organization. The purpose of
this section is to document assumptions that are outside the control of the performing organization—conditions that should be noted because someone will be taking responsibility for ensuring they hold.

A distinction can also be made between assumptions that pertain to the requirements and those that pertain to the project as a whole. The software project management plan is the most logical place to document assumptions that pertain to the project as a whole.

**_Example:_**

It is assumed that the client has an ODBC compliant database installed and this database will be accessible from the machine where the system will run.

It is assumed that the web hosting ISP will allow server-side scripts to access the file system.

## 2 GENERAL DESIGN CONSTRAINTS

### 2.1 Product Environment

Most software systems don’t exist in isolation. They interact with other systems and are part of a larger system or environment. This section describes the boundaries between the proposed system and its environment. The product context may include other hardware/software systems or a general business context. It may be helpful to specify the product environment with a block diagram that shows the major interfaces between the system under development and its environment.

If the system will use an existing database management system describe the interface here.

Note the user interface, which characterizes an interface between the system and its environment, is described below.

**_Example:_**

The innovative publishing system will be a component of the existing online course management system used in the computer science department at UMKC. The online course management system has built-in support for authentication. The innovative publishing system will use the existing course management system to identify and authenticate readers. The online course management system also includes a relational database which will be used through the JDBC/ODBC interface.

### 2.2 User Characteristics

It’s important for developers to have a complete and accurate image of the end users. Even when the requirements of the user interface are described in detail the developer will still make many tiny design decisions during design and implementation. Knowing the general characteristics of the end users will help the developer make better decisions.

If the specific users of the system are known list them here. More likely there will be user roles or categories of uses. For each group of users list their responsibilities, characterize their knowledge of the domain and describe their characteristics including technical sophistication, background and education.

Prioritize users if necessary. This is especially important when user characteristics conflict. For example, if the system must accommodate experienced users as well as novices it is important to know which should be given priority in case it’s not possible to accommodate both groups.

* **Visitor** – Views the data in the system. Does not have to be logged in. If the Visitor registers and logs in, their user type can be saved and used on subsequent log ins. If not logged in, the user will be allowed to select viewing experience category or be presented with a default view if nothing selected.
* This should be broken down into more detailed roles so the user experience can be customized to their needs as defined in the User Characteristics section above.
* Scientist
* Secondary school teacher
* Highschool student
* Etc.
* **Editor** – Edits the data in the system. Must be signed in with the appropriate security roles.
* **Site Administrator** – Administers aspects of the system. Must be signed in with the appropriate security roles.
* **Data Administrator** – Administers the data including validation. Must be signed in with the appropriate security roles.

### 2.3 Mandated Constraints

Ideally requirements will be specified in terms of functionality needed and developers will have free rein to design and implement a solution. In practice there are constraints on the eventual design and implementation.

Constraints may be mandated technologies. For example, the client may specify that a specific database management system, programming language, and/or operating system be used.

Constraints limit design and implementation options.

Constraints might be absolute, desirable or optional. If constraints aren’t absolute the motivation for the constraint should also be given.

[TBD]

### 2.4 Potential System Evolution

The resulting software system should be maintainable and extensible. Knowing the types of anticipated changes aids significantly in establishing an architecture that will accommodate the types of expected changes. This section suggests ways the system is likely to be extended or modified in the future.

## 3 NONFUNCTIONAL REQUIREMENTS

Nonfunctional requirements are properties the system must have. Nonfunctional
requirements tend to be orthogonal to functional requirements. For example, a system may have the nonfunctional requirement that it be offline no more than 15 minutes at a time and not more than ½ hour each week. The realization of this requirements isn’t limited to one spot in the code. This nonfunctional requirement crosscuts some or all functional requirements.

[TBD]

### 3.1 Legal Requirements

Some security and safety requirements may also be legal requirements. For example, laws protect the confidentiality of personal information records.

**_Example:_**

Student social security numbers will not be visible to other students.

### 3.2 Other Quality Attributes

There are specific sections above for non-functional quality attributes such as security, performance, etc. In this section describe any other non-functional quality attributes such as portability, availability, etc.

[TBD]

### 3.3 Documentation and Training

An important part of the total system is the documentation and training that is provided with the system. This section should describe the types and quantity of documentation and training that will be provided with the product.

[TBD]

### 3.4 External Interface

External interfaces may be user interfaces or software interfaces.

[TBD]

#### 3.4.1 User Interface

The requirements document shouldn’t contain design or implementation details. The _logical_ user interface should be described here. The description here shouldn’t unnecessarily constrain design and implementation options.

The general personality of the interface should be described here. For example, should the interface convey a conservative, professional, authoritative or fun attitude? What is the look and feel? Style? User characteristics were given above in section 2.2 but it may be helpful to characterize the average user here as adult, teenager or child.

User interfaces may contain a mixture of media types. It may be helpful to describe the desired/permissible user interface in terms of media elements.

Should the interface be intuitive or will training be provided. If training is required what types of training will be provided (online help, separate user manual, formal classroom training).

Ease-of-use requirements should be stated in a way that can be verified. For example, “the product should be easy to use” isn’t verifiable because it’s impossible to define “easy” in a measurable way. Must better is “75% of users will be able to use 80% of the features within 20 seconds without prior training”.

#### 3.4.2 Software Interface

The software interfaces may be locally addressable API’s or remote interfaces using technologies such as web services.

**_Example:_**

The operations defined by use case 4-7 below will also be available programmatically via XML over HTTP. The exact protocol is described the WSDL document at xyz.

#### 3.4.3 External Services

Use Google Analytics

## 4 REQUIREMENTS

The core requirements of the system are listed in this section. This template recommends organizing requirements by features rather than use cases. Features are system behaviors from the user’s point-of-view. The requirements of a feature are described by one or more use cases plus any additional narration that is necessary.

Requirements should be ranked and listed in priority order by the stakeholders and project administration. Priority is determined using the MoSCoW system

#### Prioritization

| MoSCow&#160;System | |
| ------------- | ------------|
| Must | Without this, the product would not function or be useful |
| Should | High priority requirement that should be included if possible, within the delivery timeframe |
| Could | This is a desirable or nice-to-have requirement (time and resources permitting) but the solution will still be accepted if the functionality is not included |
| Won't | This represents a requirement that stakeholders want to have, but have agreed will not be implemented in the current version of the system |

#### Status

Each story will be in one of the following statuses with all new requirements starting as pending. Since this is an existing system, all requirements that are already implemented will be marked as _Confirming_ and will move to finished when verified.

| Status | Description |
| ------ | ----------- |
| Pending | The Pending state is the initial state of any user story. In this state, the user story has nothing more than a short description of user's need. The only purpose of user story, for now, is for reminding all parties for a future discussion of user's request written in this user story (card). It is possible that the user story will be discarded in the future. |
| Backlog | When a user story is agreed to be addressed by development that user story is said to be in the backlog which works like a queue. Business owners move things into the backlog when they are ready for development. No detailed discussion has yet been carried out in this state. |
| Discussing | When a user story is in the Discussing state, the product owner will communicate to the development team in confirming the requirements as well as to define the acceptance criteria. Development team will write down the requirements or any decisions as conversation notes. UX specialist may create wireframes or storyboards to let user preview the system, and to feel it. |
| Developing | Once the requirements are clarified, the development team will design and implement the feature to fulfill user's requests. |
| Confirming | Once the development team has implemented a user story, the user story will be confirmed by the product owner. He/she will be given access to the testing environment or a semi-complete software product (sometimes known as an alpha version) for confirming the feature. Confirmation will be performed based on the confirmation items written when detailing the user story. Until the confirmation is done, the user story is said to be in the Confirming state. |
| Finished | Once the feature is confirmed done, the user story is said to be in the Finished state. Typically, this is the end of the user story. If user has a new requirement, no matter it is about a new feature or an enhancement, the team should. |

### 4.1 Accessibility Requirements

It’s hard to image a software system that doesn’t have usability as one of its highest nonfunctional quality requirements. It’s not enough to just say that the system should be usable though. Usability requirements must be stated in a quantifiable and testable way.

One method of specifying usability requirements is to specify efficiency, effectiveness and satisfaction goals for specific scenarios of use (section 4) carried out by representative users (section 2.2). A simpler alternative is to design a survey to measure user satisfaction and get consensus on who will take the survey and what will be considered an acceptable aggregate
score.

[TBD] This is the place to specify using S.E.N.D and a short description of the aspects of it with references to more detailed knowledge

#### REQ 1001 SEND principles must be adhered to

#### REQ 1002 The user interface must be available in multiple languages

### 4.2 Security Requirements

#### REQ 2001 All changes to the data must leave a clear audit trail.

#### REQ 2002 All data must be backed up on a periodic basis

#### REQ 2003 All data must be secured from malicious access

#### REQ 2004 All users editing the data must be authorized

#### REQ 2005 Different levels of authorization editing are required.
(i.e. Create, Edit, Delete and which sets of nodes are authorized (i.e. Whole tree, a set of clades, etc.)

#### REQ 2006 Must support application administration roles (configuring lists, adding new editors)

#### REQ 2007 Must support System level administration
Maintaining users, permissions, etc.

### 4.3 Data Requirements

This section will describe the data that will need to be captured for a node. It does not describe any audit trail data which will be shown in the Solution Architecture as a standard implementation detail

#### REQ 3001 Scientific Name

* ##### REQ 3001-1 Name
Scientific name(s) found in the scientific literature; italicized binomial name
* ##### REQ 3001-2 Author Name
* ##### REQ 3001-3 Naming Date

#### REQ 3002 Common Names
Colloquial names given by modern languages
Example: Rabbits, Hares, Pikas

#### REQ 3003 Description

#### REQ 3004 Extant/Extinct

#### REQ 3005 Assets

#### REQ 3006 Attributions

* ##### REQ 3006-1 Type
* ##### REQ 3006-2 Is Implied
* ##### REQ 3006-3 Names
* ##### REQ 3006-4 Date
* ##### REQ 3006-5 Sensu Clade

#### REQ 3007 Characteristics

* ##### REQ 3007-1 Cell Type
- Eukaryotes
- Prokaryotes
* ##### REQ 3007-2
- Multicellular - Groups animals, fungi, plants together
- Unicellular - Groups basal animals, plants, protists and prokaryotes together
* ##### REQ 3007-3
- Heterotrophic - Groups animals, fungi, some plants, protists, and prokaryotes
- Autotrophic - Groups plants, prokaryotes and some protists together
* ##### REQ 3007-4 True Tissues?
- Groups eumetazoans together
* ##### REQ 3007-5 Symmetry
- Bilateral/Radial
- Separates bilaterians from non-bilaterians
* ##### REQ 3007-6 Jaws
- Yes - Groups gnathostomes together
- No
* ##### REQ 3007-7 Fin Type
- None
- Lobe - Groups sarcopterygians together
- Ray – Groups actinopterygians together
* ##### REQ 3007-8 Number of Appendicular Limbs
- Groups tetrapods or hexapods together
* ##### REQ 3007-9 Skin Covering
- Fur - Groups mammals together
- Scales – Groups non-mammalian reptiles together
* ##### REQ 3007-10 Reproduction
* ###### REQ 3007-10-1 Reproductive Strategy
- R-Selective
- K-Selective
* ###### REQ 3006-10-2 Sexual Dimorphism
- Differences between sexes, if any
- Example: Male Larger, female coloration
* ###### REQ 3007-10-3 Reproduction Type
- Viviparity
- Ovoparity
- Ovovivoparity
* ###### REQ 3007-10-4 Litter Size
- How many offspring typically born
* ###### REQ 3007-10-5 Gestation Period
- Average Pregnancy length
* ##### REQ 3007-11?
- Poikilotherm – Constant body temperature
- Homeotherm - Variable body temperature
* ##### REQ 3007-12?
- Ectotherm - Body temperature from external sources
- Endotherm – Body temperature from internal sources
* ##### REQ 3007- 13 Mesothermy?
- Overall body temperature comes from outside body, but still creates localized heat internally
* ##### REQ 3007- 14 Development
- Deuterostomic - Groups deuterostomes together
- Protostomic - Groups protostomes together
* ##### REQ 3007-15 Backbone?
- Yes - Groups vertebrates together
- No
* ##### REQ 3007-16 Milk production?
- Yes – Groups Mammals together
- No
* ##### REQ 3007-17 Diet
- Herbivore
- Carnivore
- Omnivore
- Detritivore
* ##### REQ 3007-18 Venomous
* ###### REQ 3007-18-1 Venomous?
- Yes
- No
* ###### REQ 3007-18-2 Method of Envenomation
- Jaws
- Fangs
- Spines
- Sting
- Legs
- Spur
- Tentacle
- Dart
- Saliva
* ##### REQ 3007-19 Poisonous
* ###### REQ 3007-19-1 Poisonous?
- Yes
- No
* ###### REQ 3007-19-2 Method of Poisoning
- Eating
- Certain Body parts
* ##### REQ 3007-20 Flight?
- Yes
- No
- Maybe (e.g. chickens)
* ##### REQ 3007-21 Biome
Ideal habitat circumstances (area + climate)
- Forrest
- Wood
- jungle
- savannah
- desert
- mountains
- coastal
- pond
- lake
- river
- saltwater/sea/ocean
- polar
- tropical
- sub-tropical
- temperate
* ##### REQ 3007-22 Special abilities
What sense specializations does it have, if any?
- Sonar
- echolocation
- heat
- sight
- hearing
- smell
- taste
- touch
- electromagnetic field
- electric
- flashing
- colour change
- texture change
- light emitting.

* ##### REQ 3007-23 Breathing mechanism(s)
How does it breathe?
Multiple select list:
- Lungs
- Gills
- Skin
* ##### REQ 3007-24 Misc. features
Any notable records or unique features
Example: Fewest neck vertebrae, fastest swimmer
* ##### REQ 3007-25 Average weight
* ##### REQ 3007-26 Average size
* ##### REQ 3007-27 Life span
Average number of years for an individual
Input pattern # - #
* ##### REQ 3007-28 Life cycle waypoints?
Does it metamorphosize?
Example: Larva (how long?), Pupa (how long?), adult
* ##### REQ 3007- 29 Method of locomotion
Main mode of locomotion
- Crawl
- Walk
- Swim
* ##### REQ 3007-30 Mutualism?
Any mutualistic interactions with other species (name associated)
* ###### REQ 3007-30-1 Type of Mutualism
- Commensalism
- Parasitism
- Cooperation
* ###### REQ 3007- 30 - 2 Species Name

#### REQ 3008 IUCN Rating
Conservation status of taxon, linked to their corresponding IUCN page

Example: Least concern

#### REQ 3009 Earliest known Occurrence

Oldest period of time with known taxon specimens

Example: Late Paleocene

#### REQ 5010 Location/Distribution

Locations where taxon is found

Example: Worldwide except Antarctica

#### REQ 5011 Number of Descendent Clades

#### REQ 5012 Number of Species

#### REQ 5013 Taxonomy

* ##### 5013-1 Linnaean Rank
Approximate rank in Linnaean hierarchy
Example: Order
* ##### 5013-2 Linnaean Taxonomy Levels

#### 5014 Genomics

* ##### 5014-1 Genome Assemblies
* ##### 5014-2 Average Number of Genes
* ##### 5014-3 Number of Chromosomes
* ##### 5014-4 Genome Size

#### 5015 MRCA-SC Adaptations

* ##### REQ 5015-1 Pathogen?
Primary/opportunistic (host)
* ##### REQ 5015-2 Parasitic?
Primary/opportunistic (host)
#### REQ 5016 Energy Production

* ##### REQ 5016-1 Mitochondrion or Hydrogenosome
* ##### REQ 5016-2 Presence of Plastids
This will mostly be mitochondrion, however hydrogenosomes are indicative of a specially adapted parasitic life cycle or can stem from clades diverging prior to the mitochondrion endosymbiotic event

### 4.6 Application Requirements

This section lists the requirements for features in the PEP application. All features should be described at a high-level from the users’ standpoint with no reference to technology or how they will be implemented.

They will be marked with their MoSCoW priority symbol after being assigned and the tracked with a status indicator as they proceed through the development process.

#### REQ 6001 Tree View Requirements

* ##### REQ 6001-1 Select a visible node in tree view
* ##### REQ 6001-2 Show Summary view of selected node
* ##### REQ 6001-3 Show detailed view of selected node
* ##### REQ 6001-4 Highlight the path from the selected node to the tree root
* ##### REQ 6002-5 Filter the nodes shown in the tree
Provide the visitor with a mechanism to perform a search for a set of nodes using (REQ 6003-2 Search for a set of Nodes by multiple data elements – Simple) or (REQ 6003 - 3 Search for a set of Nodes by multiple data elements – Advanced) and either highlight those nodes or restrict the tree to showing only those nodes.
* ##### REQ 6002-6 Adjust Zoom Level of the tree
* ##### REQ 6002-7 Configure number of levels to display
* ##### REQ 6002-8 Export tree view
* ##### REQ 6002-9 Create image of tree view for pasting

#### REQ 6002 Tabular View Requirements

* ##### REQ 6002-1 Select the data elements to show
* ##### REQ 6002-2 Configure the number of rows to view per page
* ##### REQ 6002-3 Sort Table
* ##### REQ 6002-4 Export table
* ##### REQ 6002-5 Save Table

#### REQ 6003 Searching

These searching mechanisms can be used in various parts of the application such as

* ##### REQ 6003-1 Search a single Node by one of its Names
Provide a Visitor with a method to search for a single node to display using one of its names. This is already implemented in the tree but can be expanded to other data views as they are implemented.
* ##### REQ 6003-2 Search for a set of Nodes by multiple data elements – Simple
Provide a Visitor with a Method to search for a set of nodes by using multiple selection criteria. These can be any of the data elements such as the names, characteristics such as Eukaryote, flies, Autotroph, etc. This type of search will provide no complex Boolean logic, just return a set of nodes that match any or all the criteria. This will be a choice for the user to make.
* ##### REQ 6003-3 Search for a set of Nodes by multiple data elements – Advanced
Provide a Visitor with a Method to search for a set of nodes by using multiple selection criteria and Boolean operators such as and, or, not, etc. These can be any of the data elements such as the names, characteristics such as Eukaryote, flies, Autotroph, etc. This type of search will provide the ability to construct complex searches like: (Is extinct and A mammal and Not lives in a Jungle or ocean) This could be provided one or more ways such as a UI to build the search, or, typing it in as a Boolean stamen for more advanced users.
* ##### REQ 6003-4 Save Searches
Provide a Visitor with a Method to save search criteria for later use, Visitor must be logged in.
* ##### REQ 6003-5 Apply Searches
Provide a Visitor with a Method to retrieve and apply a saved search.

#### REQ 6005 Editing

* ##### REQ 6005-1 Create a single node
Provide a method for the Editor to manually create a new node either by selecting a node in one of the data views (becomes the parent node to the new node) or navigating to the page to create a node and selecting the parent node.
**Permissions** : Create Node, Create Node in Clade X
* ##### REQ 6005- 2 Modify a single node
Provide a method for the Editor to edit the data elements of a single node
**Permissions** : Modify Node, Edit Node in Clade X
* ##### REQ 6005-3 Delete a single node
Provide an Editor with the ability to delete a single node
**Permissions** : Delete Node, Delete Node in Clade X
* ##### REQ 6005-4 Create Multiple Nodes
Provide and Editor with the ability to create multiple nodes using an spreadsheet like grid where they can select a parent node, then mass enter a number of descendants either through manual typing or cut and paste.
**Permissions** : Crete Node, Create Node in Clade X
* ##### REQ 6005- 5 Modify Multiple Nodes
Provide an Editor with the ability to edit multiple nodes using an spreadsheet like grid where they can select a set of nodes using the search mechanism, then mass edit them
**Permissions** : Modify Node, Modify Node in Clade X
* ##### REQ 6005-6 Delete Multiple Nodes
Provide an Editor with the ability to select a set of nodes and delete them.
**Permissions** : Delete Node, Delete Node in Clade X
* ##### REQ 6005-7 Import New Nodes
Provide an Editor with the ability to import a set of nodes from various formats such as Newick, NEXUS, CSV, etc. These will be added as descendants of a descendant clade of the parent node selected by the Editor
**Permissions** : Import Nodes
* ##### REQ 6005-8 Import/Update Multiple Nodes
Provide an Editor with the ability to modify multiple nodes by importing a set of data in various formats. A mechanism will need to be created to map the new nodes to existing nodes and map the data element names.

## 5 USER STORIES

User stories are used to capture product functionality from the end users’ perspective to clearly show what a specific user type can do with an application.

User stories will be structured as follows:

- **Epics -** An epic is a large user story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller user stories.
- **User stories -** short requirements or requests written from the perspective of an end user.
- **Sub Stories –** If a story is too large, it will be broken down into smaller sub stories

#### Method

The INVEST method will be used to aid in writing good user stories.

- **Independent**: Each story should be independent (no overlapping) so it can be developed and delivered separately
- **Negotiable**: Details will be clarified by the cooperation of the developers and customers
- **Valuable**: It needs to be valuable for the users
- **Estimable**: The story should be estimated. It doesn’t have to set exact time frame just a good estimate to schedule it in the project
- **Small**: The stories need to be small enough to accurately estimate work it requires
- **Testable**: It needs to be tested easily. Which also indicates that the requirements are well-defined.

#### Prioritization

Each story will be categorized using the MoSCoW method as described above.

Use these badges in user stories to mark priority:
[](#Prioritization) [](#Prioritization) [](#Prioritization) [](#Prioritization)

#### Status

Each story will be in one of the statuses detailed above.

Use these badges in user stories to mark status:
[](####Status) [](####Status) [](####Status) [](####Status) [](####Status) [](####Status)

### 5.1 Actors

An actor specifies a role played by a user or any other system that interacts with the PEP
data. These will be used in the user stories and use cases later in the document.

- **Visitor** – Views the data in the system. Does not have to be logged in. If the Visitor registers and logs in, their user type can be saved and used on subsequent log ins. If not logged in, the user will be allowed to select viewing experience category or be presented with a default view if nothing selected.
- This should be broken down into more detailed roles so the user experience can be customized to their needs as defined in the User Characteristics section above.
* Scientist
* Secondary school teacher
* Highschool student
* Etc.
- **Editor** – Edits the data in the system. Must be signed in with the appropriate security roles.
- **Site Administrator** – Administers aspects of the system. Must be signed in with the appropriate security roles.
- **Data Administrator** – Administers the data including validation. Must be signed in with the appropriate security roles.

## 6 Epics

Epics are large groupings of functionality in PEP and are broken down into User Stories and sub stories where needed.

Each user story will be look like this:

---

### {Reference Number} {Title}
[](https://shields.io/) [](#Prioritization)

**As a** {who}
**I want to** {what}
**So that** {why}

##### Acceptance Criteria

Scenario: <title>
  Given <state>
  When <event>
  Then <expected outcome>
  And <extend previous step>

#### Conversation

---

* **Reference Number**: Used in other documents to reference this story. The format is
* US for user story
* 1-1 Epic Number – Sequence number
* **Title**: A simple title to describe the story
* **As a**: Which actor this story is for
* **I Want To**: What the actor wants to accomplish
* **So That**: The reason the actor wants to do it
* **MoSCoW Priority**: As describe above
* **Acceptance Criteria**: A list of criteria that must be met to accept the story as fully developed and deployed
* **Status**: As described above
* **Conversation**: Notes captured while discussing the story to give further details

### Epic 1: View data as a tree

All of the user stories in this epic deal with viewing the data in the tree format including navigating through the tree, etc.

---

#### US 1-1 View the tree
[](####Status) [](#Prioritization)

**As a** visitor
**I want to** view the phylogenetic tree and navigate through the nodes
**So that**

##### Acceptance Criteria

Scenario: View the tree
  Given modern browser
  When visitor goes to phylogenyexplorerproject.com
  Then subtree from root is displayed
  And 3 generations are open
Scenario: Reveal actions
  Given subtree has loaded
  When visitor hovers over node
  Then action buttons/icons are shown
Scenario: Reveal more nodes
  Given node is being hovered and there are hidden children
  When visitor clicks on circle/+ next to node
  Then hidden children will open
  And grandchildren are loaded in the background so successive clicking is quick (500ms or an)

##### Conversation
Large (> 10?) lists of children can be hidden by default and be loaded same as hidden grandchildren

To do:

- Define modern browser
- Define subtree and and root
- Add backend requirements

---

#### US 1-2 Adjust zoom level

[](####Status) [](#Prioritization)

**As a** visitor
**I want to** I Want To to zoom in and out on the tree
**So that**

##### Acceptance Criteria

Scenario: Adjust zoom level
  Given Given tree has loaded
  When user scrolls with mouse wheel
  Then tree will zoom in and out

##### Conversation

---

#### US 1-3 Jump to the root of the tree

[](####Status) [](#Prioritization)

**As a** visitor
**I want to** As a viewer I want to be able to jump directly to the root of the tree
**So that** I can reorient myself

##### Acceptance Criteria

Scenario: Adjust zoom level
  Given Given tree has loaded
  When user scrolls with mouse wheel
  Then tree will zoom in and out

##### Conversation

---

### Epic 2: Filter tree view

#### US 2-1 Filter Nodes

**As a** visitor
**I want to** be able to filter the nodes that will be shown in the tree
**So that** I can reorient myself

##### Acceptance Criteria

Scenario: Filter Nodes
  Given Given tree has loaded
  When user clicks on filters icon in toolbar
  Then filters sidebar will show

The user should be able to filter the tree based on:
- Characteristics such as method of locomotion,
reproductive type, etc.
- The user should be allowed to select multiple criteria

##### Conversation

---

#### US 1-3 Search for a Nodes by name

As a Viewer
I Want To be able to search for a nodes by name and have the tree
displayed at that point.
So That
Acceptance Criteria
Status
Conversation

#### US 1-4 Search for a nodes by characteristics

As a Viewer.
I Want To search for a nodes using multiple criteria to narrow down my
choices and have the tree displayed at that point
So That I can see only the data I want to see
Acceptance Criteria
Status
Conversation

#### US 1-5 Trace a path to the root

As a Viewer
I Want To view the path from my currently selected node back to the root
of the tree.
So That
Acceptance Criteria
Status
Conversation

#### US 1-6 Configure number of tree levels to view

As a Viewer
I Want To configure how many levels of descendants to display on the
tree
So That
Acceptance Criteria
Status
Conversation

#### US 1-7 Graphically identify certain nodes

As a Viewer
I Want To highlight nodes of the tree based on criteria I select.
So That
Acceptance Criteria
Status
Conversation

#### US 1-8 Show Geological time scale

As a Viewer
I Want To view when a nodes existed on the geological time scale.
So That
Acceptance Criteria
Status
Conversation

#### US 1-9 Show how the earth looked

As a Viewer
I Want To view an imagine of how the Earth looked during the time a nodes
existed
So That
Acceptance Criteria
Status
Conversation

#### US 1-10 View a summery description of nodes

As a Viewer
I Want To view a summary description of a nodes
So That
Acceptance Criteria
Status
Conversation

#### US 1-11 View a detailed description of nodes

US 1- 1 View a detailed description of nodes
As a Viewer
I Want To view detailed information about a nodes
So That
Acceptance Criteria
Status
Conversation

### Epic 2: View data in tabular form

As a viewer I want to select data to be displayed in a table format

US 2 - 1 Filter data to view in a table
Description As a viewer I want to be able to filter data to view in a table using one or
more criteria
Acceptance Criteria
Epic Table View
Status

US 2 - 2 Filter data by characteristics
Description As a viewer I want to be able to filter nodes for the table view by one or
more characteristics.
Acceptance Criteria
Epic
Status

US 2 - 3 Filter nodes by descendants
Description As a viewer I want to be able to display a nodes and all its descendants
Acceptance Criteria
Epic
Status

US 2 - 4 Select columns to display
Description As a viewer I want to be able to select which columns of data will be
displayed in the table
Acceptance Criteria
Epic
Status

US 2- 5 Sort the table
Description As a viewer I want to sort the data in the table by one or more columns
Acceptance Criteria
Epic
Status

### Epic 3: Maintain the data

As an editor I want to be able to insert, edit, and delete Nodes data

#### US 3-1 Insert a new nodes

Description As an editor I want to insert a new nodes
Acceptance Criteria
Epic
Status

#### US 3-2 Delete nodes

Description As an editor I want to delete one or more nodes
Acceptance Criteria
Epic
Status

#### US 3-3 Edit nodes

Description As an editor I want to edit one or more nodes
Acceptance Criteria
Epic
Status

### Epic: 4 Administer the site

### Epic 5: Administer the data