Community Platform Engineering/Requirements

Engaging with the CPE team

Guidelines will be issued for how to feed in requirements into the CPE team. This section will be updated in due course.

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 prioritisation and scheduling.

The following are required before they are deemed ready for the team to consume:

Goals

The high level goals of the work. This should explain clearly the WHAT and WHY of the work. The problem that this proposed solution will solve and / or the offering that this feature will provide should make up this section.

Background and Strategic Fit

Any relevant background to this request that will give context should be included. Strategically, where this work fits in for the team should be outlined in a clear manner. The strategic fit is one of the key indicators to help us gauge priority.

Who is requesting this

The stakeholder who is requesting this.

Assumptions

Requirements typically begin with an elicitation phase and several Assumptions may exist at this point. Calling out Assumptions in a clear manner will allow the team clarify, confirm or reject the assumptions put forward. This is key to save the team figuring out in the middle of developing work that a fundamental assumption was incorrect and not known.

Initial 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 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

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 points 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 schedule work on the items in a fact based manner, with estimations and schedules being derived from a completed requirements list.

#	Title	User Story	Phase	Related Taiga Issue	Notes
PRD.100	Login	As a User, I want to use the FAS Login for my credentials	1	http://somelink.here	Typical Login flow

• Title

An easy to communicate title

• User Story

The User Story / Epic that this relates to

• Phase

The goal is to evolve a Minimum Viable Product (MVP) which represents Phase I. Can we identify the critical path and put some features out to later phases?

• Related Taiga Issue

Links to more granular realisation of the User Stories where the development team can track and work in their own tooling

• Notes

Relevant notes / questions / clarifications

Overall State

The goal would be to have a page as a landing page for tracking all project. A quick reference list could show us the state of each spec. For example:

• WORKING DRAFT: this indicates that the document is being worked on currently, but the initial draft has not been released.
• UNDER REVIEW: this indicates that the document is released for review comments.
• READY FOR DEV: this indicates that the review has been completed and development can commence on this.
• IN DEVELOPMENT: this indicates that the document is currently in the Development phase.
• RELEASED: this indicates that the requirements which were in scope were developed tested and released as part of the product.
• PARKED: this specification is currently parked. There is no ongoing work on it.