Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The page is intended to summarize all the requirements for Guilin Release.

These requirements have been prioritized by the TSC to realistically fit within the Guilin Release Timeline.

The Release Scope should be finalized during the M1 Release Planning milestone on TBD

TSC Prioritization (Ranking)

  • RANK #0  – Special GO - quick wins, fully covered by involved companies
  • RANK #1 – TSC Must Have – Mandatory for the release
  • RANK #2 – Continuity  - Items continued from previous releases
  • RANK #3 – PTL Go – items that PTLs is OK to include since team has bandwidth
  • RANK #4 – NO GO – items not approved for various reasons

Use Cases 

Release 6 (Guilin) proposed use cases and functional requirements

M1 Scorecard:

  • Green: Use Case will be fully implemented and tested
  • Yellow: Use Case will be partially implemented. It is possible to identify capabilities for this use case that can be tested (phasing approach).
  • Red: Use Case can not be partially delivered, min. requirements can not be met in order to define a testing strategy.

Architecture:

  • Pink - NO  GO
  • Purple - GO
  • Green - Considered OK not requiring architecture review
  • Black - Architecture not yet performed

...

numberOfFixedRows1
numberOfFixedColumns4
decimalMark. (point)

...

JIRA link (REQ)

One issue per requirement.

Instructions

...

M1

Scorecard

...

T-Shirt Size (star)

...

Committed (C)/ Partially Committed (P) or not (N) per impacted project

including non functional contribution

...

Company

Engagement

...

(star) T-Shirt Size: Ballpark estimation for assessing the development/testing activities performed by the project team; not the integration team

  • XS - <4 Man/Weeks;
  • S - ~6 Man/Weeks;
  • M - ~8 Man/Weeks;
  • L - ~12 Man/Weeks;
  • XL - > 12 Man/Weeks.

Requirements

M1 Scorecard:

  • Green: The requirement will be fully implemented and tested
  • Yellow:  The requirement will be partially implemented. It is possible to identify capabilities for this functional requirement that can be tested (phasing approach).
  • Red: The requirement can not be partially delivered, min. requirements can not be met in order to define a testing strategy

Architecture:

  • Pink - NO  GO
  • Purple - GO
  • Green- Considered OK not requiring architecture review
  • Black - Architecture not yet performed

...

numberOfFixedRows1
numberOfFixedColumns4
decimalMark. (point)

...

JIRA link (REQ)

One issue per requirement.

Instructions

...

Committed (C)/Partially Committed (P) or not (N) per Impacted projects

including non functional contribution

...

  • XS - <4 Man/Weeks;
  • S - ~6 Man/Weeks;
  • M - ~8 Man/Weeks;
  • L - ~12 Man/Weeks;
  • XL - > 12 Man/Weeks.

POC / Experimentation

POC definition

...

numberOfFixedRows1
numberOfFixedColumns4
decimalMark. (point)

...

(star)T-Shirt Size: Ballpark estimation for assessing the development/testing activities performed by the project team; not the integration team

...

Note:  we will no longer be using a Confluence table to track requirements.  Instead, we will be documenting requirements in JIRA and using a JIRA dashboard to track requirements.  More information here.