Especificação de Requisitos de Software

Artefatos do RUP

1 – Artefatos de Requisitos

1.1 – Especificação de Requisitos de Software

A Especificação de Requisitos de Software captura todos os requisitos de software para o sistema ou para uma parte do sistema.

Prós:

• Serve como um meio de comunicação entre clientes, analistas, desenvolvedores, etc.
• A partir dele, é criado os casos de uso do sistema.
• Serve como entrada para o planejamento de iterações.
• Serve como entrada para a implementação de classes.
• Serve para verificar a compatibilidade do sistema.

Contras:

• Consumo de muito tempo com o levantamento de todos os requisitos.

1.2 – Caso de Uso

Define um conjunto de instâncias de casos de uso, no qual cada instância é uma sequência de ações realizada por um sistema que produz um resultado de valor observável para determinado ator.

Prós:

• Utilizados pelos clientes para entenderem o comportamento do sistema e, como eles precisam aprovar o fluxo de eventos do caso de uso, para aprovarem o resultado da modelagem de casos de uso.
• Possíveis usuários utilizarão para compreender o comportamento do sistema.
• Utilizado para identificar a funcionalidade da arquitetura, casos de testes, etc.
• Utilizado para entender o comportamento do sistema e refiná-lo.

Contras:

• Não encontrei.

1.3 – Protótipo da Interface do Usuário

Como o nome diz, refere-se ao protótipo da interface do usuário. Ele pode se manifestar como: esboço em papel ou figuras, imagens feitas com um ferramenta de desenho, etc.

Prós:

• Utilizado para conhecer a interface do usuário referente a um caso de uso.
• Utilizado para saber o impacto da interface do usuário sobre a análise do sistema e o que ela exige do sistema internamente.

Contras:

• Para projetos de pequeno porte ou no qual as ideias estão bem definidas, apenas gera documentação excessiva.

1.4 – Ator

Define um conjunto coerente de papéis que os usuários do sistema podem desempenhar ao interagir com ele. Uma instância de ator pode ser desempenhada tanto por um indivíduo quanto por um sistema externo.

Prós:

• Define as fronteiras do sistema.
• Descreve os casos de uso e suas interações com os atores.

Contras:

• Para projetos de pequeno/médio porte ou no qual os requisitos estão bem definidos, apenas gera documentação excessiva.

2 - Artefatos de Implementação

2.1 – Componente

Representa uma parte física do processo de desenvolvimento: arquivos de algum tipo que contêm código-fonte, configurações, executáveis e outros produtos físicos do desenvolvimento.

Prós:

• Reduz a quantidade de software a ser desenvolvido.
• Entrega mais rápida do sistema.

Contras:

• Se o sistema possui muitos componentes de terceiros, há o problema de atualização do componente ou quebra de compatibilidade na atualização do componente.

2.2 - Build

É uma versão operacional de um sistema ou parte de um sistema que demonstra um subconjunto dos recursos a serem fornecidos no produto final. Ele é constituído de um ou mais componentes.

Prós:

• Os clientes podem usar as builds como protótipos e ganhar experiência, obtendo informações sobre os requisitos dos incrementos posteriores do sistema.
• Risco menor de falha geral do sistema.
• Não é necessário que o cliente espere até a entrega do sistema inteiro.

Contras:

• Não encontrei.

2.3 – Plano de Integração do Build

Fornece um plano detalhado para integração em uma iteração.

Prós:

• Planejamento da ordem em que os componentes e os subsistemas devem ser implementados, o que será liberado para a integração do sistema e quando isso ocorrerá.
• Serve como uma ferramenta de planejamento.

Contras:

• Para projetos de pequeno porte ou no qual as ideias estão bem definidas, apenas gera documentação excessiva.

3 – Artefatos de Teste

3.1 – Lista de Ideias de Teste

É uma lista enumerada de ideias, geralmente formada parcialmente e que identifica possíveis testes úteis a serem conduzidos.

Prós:

• Pode ser usada para capturar as ideias iniciais para possíveis testes, em geral, ideias mal formadas ou parciais.
• Serve para identificar um número suficiente de ideias para validar adequadamente os itens de Teste-Alvo.

Contras:

• Para projetos de pequeno porte ou no qual as ideias estão bem definidas, apenas gera documentação excessiva.

3.2 – Caso de Teste

É a definição de um conjunto específico de entradas de teste, condições de execução e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um Item de Teste-alvo.

Prós:

• Redução no custo do sistema pela minimização de falhas de software.
• Qualidade de software: se o código sofre alterações, deve passar pelo teste já escrito.

Contras:

• Não encontrei.

3.3 – Conjunto de Testes

Usado para agrupar conjuntos de Scripts de Teste, para determinar a sequência da execução dos testes.