*Title* - Requirement document - v2
===================================

###### tags: `Requirements Document` `Fedora`

[toc]

# Point of contacts

**Requester**: The person submitting this initiative
**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 document: what and why?

## 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.

As the requester you are expected to be involved for the lifecycle of the project. You should be available for clarifications, to address any points in the spec, and participate during the software development phase of this project.

## 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 with that.

## 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.

## 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 failure. To protect both the team and indeed the requested feature, call out any assumptions the requester is making in the spec.

| Assumption | Raised By | Plan of Action |
|:------ |:----------- |:----------- |
| Everyone 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.

### Actors

Clearly outline the Actors, who are the end users of the requested work. Differentiate any User Stories from a functionality point of view. We call these 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 | | |
|... | | | |
|... | | | |

# Requirements document: Technical solutions

## Approach #1

### Description
### Pros
### Cons

## Approach #2

### Description
### Pros
### Cons
...

## Preferred solution

# 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