Rastreabilidade de Requisitos - Desenho2018-1/pan-pan GitHub Wiki

Histórico de edição

Autor Data
Fabíola Fleury 15/03
Fabíola Fleury 17/03
Josué Nascimento 27/03

1. Rastreabilidade

Os requisitos são divididos de acordo com os três níveis definidos pelo processo: Portfólio, Programa e Time. É definido entre eles também uma rastreabilidade.

1.1 Habilitadores (Hxx00)

Os habilitadores existem nos três níveis, também conhecidos como requisitos não-funcionais, são responsáveis por habilitar e dar suporte para o negócio. Serão a depender dos níveis em que se encontram, por exemplo:

  • EH00 (Épico Habilitador)

  • FH00 (Feature Habilitadora)

  • USH00 (História de usuário habilitadora)

1.2 Épicos (E00)

São definições que guiam a visão do portfólio do produto, sendo de maior generalização. Eles são documentados utilizando uma adaptação do Lightweight Business Case definido pelo SAFe, demonstrado pela tabela a seguir.

Lightweight Business Case

1.3 Features (F00)

São funcionalidades que endereçam problemas do usuário, derivadas dos épicos. São descritas por meio de uma frase.

História de Usuário (US00)

Descrevem, em nível de time, as features. Podem haver histórias originadas no backlog do time, para atender alguma necessidade específica. São escritas utilizando voz de usuário:

Eu como [papel] desejo [atividade] para [valor]

2. Rastreabilidade

Fundamental para a análise de impacto de mudanças, entendimento da relação do requisito em relação ao todo do projeto, suas precedências e prioridades, a rastreabilidade dos requisitos nesse projeto será feita de forma horizontal e vertical, como ilustrado abaixo.

Rastreabilidade

Além disso, será também rastreável a evolução do requisito em relação ao tempo e suas possíveis alterações. Todos esses dados e análises serão mantidos dentro do github, por meio da integração com a ferramenta ZenHub e a utilização de issues.

Cada issue representará um requisito, e possuirá uma label que indicará o seu nível (épico, feature ou história de usuário), além de identificação caso seja não funcional (habilitador), e se depende de outros requisitos. Em cada issue, também é guardado um histórico de alterações e seu caminho percorrido pelo quadro kanban.

3 Referencial teórico

  • SCALED AGILE. SAFe® 4.0 Introduction Overview of the Scaled Agile Framework® for Lean Software and Systems Engineering​. A Scaled Agile, Inc. White Paper July, 2018.