From e942d967c1b462bb137924ae6038773461619231 Mon Sep 17 00:00:00 2001 From: Pierre-Yves Chibon Date: Oct 28 2020 13:29:15 +0000 Subject: Remove the template.md to not be confusing Signed-off-by: Pierre-Yves Chibon --- diff --git a/template.md b/template.md deleted file mode 100644 index 028c251..0000000 --- a/template.md +++ /dev/null @@ -1,111 +0,0 @@ -# *Title* - Requirement document - -###### tags: `Requirements Document` `Fedora` - -[toc] - -## Point of contacts - -**CPE Appointed Owner**: To drive the initiative -**CPE Appointed Manager**: To help unblock -**CPE Collaborators**: To help working on it -**Key Stakeholder**: To be consulted -**IRC Channel**: -**Taiga Link**: -**hackmd Link**: - - -## Document History - - -It is important to keep track of the evolution of the requirements document. Here, we can track key changes and milestones. - -**Version**: 1.0 - YYYY-MM-DD -**Authors**: *username* -**Details**: *Summary of the changes* - -**Version**: 1.1 - YYYY-MM-DD -**Authors**: *username* -**Details**: *Summary of the changes* - -... - -## Requirements Guidelines - -When writing a requirements document intended for the CPE team, a number of key items need to be included in order to help with initial reviews and later prioritization and scheduling. - -The following sections are required before this doc is ready for the team to consume. An example spec for reference is the Rawhide Gating [spec](https://fedoraproject.org/wiki/Infrastructure_2020/Rawhide_Gating). The sections below are not exhaustive, and the CPE team should evolve them based on their domain knowledge. The principle of each heading in this Template should be used to guide the requirements. If a heading is omitted, the spirit of what it is trying to achieve should be included in other sections. - - -## Goals - -The high level goals of the work. This should explain clearly WHAT is being requested. State the problem to be solved and/or the offering this feature provides in this section. Please set the goals clearly in bullet point format for consideration. Please do not give technical implementation details at this point. A member of the CPE team will assist you in that matter. - -## Value Proposition & Background - -Provide background and context for the request -- WHY it needs to be done. The CPE team will use this information to determine the value to the community and stakeholders we serve. We will also ensure it’s something this team should actually be handling. Be specific about whom the work benefits, and how. - -## Who is requesting this - -The requester should expect to be involved for the lifecycle of the project. They should be available for clarifications, to address any points in the spec, and participate during the software development phase of this project. - -## Assumptions - -We want to avoid surprises to the development team in the middle of working on a request. At best a surprise can add more time to a project, at worst, it can lead to it failing. A big part of protecting both the team and indeed the feature being requested is calling out any Assumptions that the requester is making while putting together the spec. - - -| Assumption | Raised By | Plan of Action | -|:------ |:----------- |:----------- | -| Everyoe loves this spec | Leigh Griffin | Circulate for reviw -| ... | | -| ... | | - -## User Stories - -A set of overview User Stories which covers the requested feature/enhancement in full. The details here can be at a high level and initially do not need to have Acceptance Criteria at this point in time. - -### Actors - -Clearly outline the Actors, whom are the end users of this. Differentiate any User Stories from a functionality point of view. We call this Personas, for example: - -* As a User, I want… -* As an Admin User, I want…. -* As a CPE team member, I want…. - -### User Stories - -| Story Number | Group | User Story | Importance | Acceptance Criteria -|:------------ |:----- |:---------- |:-----------|:-------------------| -|Can be as easy as 1,2,3 | Security | As a User, I want…. | Must Have |TBD -|Can be more formal like US.1.0 | UI | | | -|Can use story group references Backend.001 | Backend | | | -|Can be a format you prefer | Frontend | | | -|... | | | | -|... | | | | - -## Open Questions - -Please log and track any Open Questions here - -## Risks Identified - -Have we identified any risks for this work that we need to be aware of? - -## Descoped - -We don’t throw things away. The User Story list above should be our Minimum Viable Product (MVP), anything descoped should be copied from the Table above to the Table here so we can potentially have a Phase II. - -| Story Number | Group | User Story | Importance | Acceptance Criteria -|:------------ |:----- |:---------- |:-----------|:-------------------| -|1 | Security | As a User, I want... | Must Have | TBD -| | UI | | | -|... | | | | -|... | | | | - -## Decision Log - -Have we come to any important decisions that need to be recorded here for longer term consideration and as a point of reference? - -## Next Steps - -The initial User Stories will be explored by the team and the stakeholder who has requested the story. The initial stories will act as a conversation point and will be used as a guideline to create more Stories of varying granularity. The goal here is to have a more fleshed out story list which will serve as the starting point of formal requirements. The goal here is to examine the Minimum Viable Product (MVP) which is the minimum set of features and functionalities which represents the critical path for development. The goal here is to have a version of the feature available as early as possible and release it in phases. The overall requirements can then be documented in a similar manner to the sample below. This will allow us to schedule work on the items in a fact based manner, with estimations and schedules being derived from a completed requirements list.