...
- The list will be very high level. For example: “Add a visualization suite to VIVO replacing the existing visualizations.
- The list should include “end user” features -- very visible to faculty, staff and students who use VIVO in their daily work, as well as “owner” features that are designed to make VIVO a better citizen in a constellation of applications at an institution, as well as “technical” features that are designed to make VIVO easier to develop.
- Features may include any kind of activity necessary to deliver value to the community. Generally features involve development as well documentation, but feature may also include training or other activities necessary to enhance the value of VIVO.
- Each feature should have an estimated number of person months to complete. This is a preliminary estimate based on preliminary, high-level scope. Work on a feature will involve use case development, design, and technical specifications. The work may revise the initial estimate of the effort required, or required changes in scope based on available effort.
- Sources of features will include meeting notes including leadership, steering, workgroup and task forces, listserv discussions, JIRA issues, summaries of previous “requirements” and “use case” materials in the wiki, and previous roadmap presentations.
- All features should be consistent with the value proposition and with the strategic plan.
- Features will be briefly described -- 2-3 sentences -- what is the feature, and possibly why is it important to the VIVO community.
The project director presented a draft of this process to the Steering Group at their May 22 meeting, along with a the initial list of features from the community documents in the wiki and other VIVO assets. See checklist below for a list of the sources used to identify possible features.
...