Passo 2.1 – Coletar Requisitos

Requisitos são descrições das necessidades ou dos desejos para um produto. O objetivo básico da fase de requisitos é identificar e documentar o que realmente é necessário, em uma forma que comunica claramente essa informação ao cliente e aos membros da equipe de desenvolvimento (Larman, 1999).

Os requisitos definidos por apenas uma pessoa não refletirão as reais necessidades que deverão ser atendidas pelo framework, assim é interessante a composição de uma equipe formada por pessoas da área de desenvolvimento, área usuária e se possível pessoas com experiência no domínio. As informações poderão ser obtidas através de entrevistas e reuniões. Informações valiosas também podem ser obtidas a partir de aplicações já existentes no domínio.

Uma estratégia proposta por Landin e Niklasson (1995) é listar separadamente os requisitos de cada aplicação, identificar os requisitos gerais das aplicações e colocá-los

Passo 1: Análise de Domínio

Entrada: Obter informações sobre o domínio do problema através da observação, entrevistas, padrões já existentes e através de pessoas com conhecimento no domínio.

Procedimentos:

• Descrever suscintamente o objetivo do framework.

• Identificar seus limites.

• Descrever seus benefícios.

• Representar os objetos do domínio no modelo estático.

Saídas:

• Modelo do Domínio

o Definição do escopo do domínio.

o Modelo estático preliminar.

Figura 3.2 – Separação dos requisitos nas aplicações e no framework.

Caso não sejam identificadas aplicações relacionadas para se extrair os requisitos do framework, estes poderão ser abstraídos da análise do domínio em que residirá o framework, pois a análise fornece ao desenvolvedor um entendimento detalhado dos conceitos relevantes do domínio e da funcionalidade que o framework possuirá (Figura 3.3).

Figura 3.3 – Identificação dos requisitos do framework a partir do domínio

Funcionais Requisitos Não Funcionais

Uma técnica que melhora a compreensão dos requisitos é a criação de casos de uso (descrições narrativas de processos do domínio). Estes são identificados através da revisão dos documentos da especificação de requisitos.

Os ciclos de desenvolvimento podem ser organizados em torno dos casos de uso (Figura 3.4). A cada ciclo o caso de uso pode ser expandido para representar novos requisitos ou são criadas versões simplificadas quando o caso de uso é muito complexo para ser atacado em único ciclo (Larman, 1999).

Figura 3.4 – Alocando casos de uso a ciclos de desenvolvimento (Larman, 1999)

Os casos de uso são divididos em casos uso concretos e abstratos. Os caso de uso concretos são iniciados por um ator para produzir um resultado e os abstratos contém uma seqüência de ações que são compartilhadas por outros casos de uso.

Em se tratando de frameworks, cujo uso não será por usuários finais (Capítulo 2), o mais adequado durante o seu desenvolvimento é a criação de casos de uso abstratos, já que estes não são utilizados por atores, mas por casos de uso concretos (da aplicação) ou outros casos de uso abstratos.

Um caso de uso concreto ou abstrato pode usar vários casos de uso abstratos para completar a seqüência de ações (Figura 3.5).

Ciclo de

Desenvolvimento

Ciclo de

Desenvolvimento

Caso de Uso A Versão 1 --- ---

Caso de Uso A Versão 2 --- ---

Figura 3.5 – Casos de uso abstrato e concreto

A qualidade do modelo de caso de uso terá impacto na qualidade de outros documentos subseqüentemente produzidos no processo de desenvolvimento. Assim, as seguintes recomendações devem ser observadas (Bente e outros, 2001):

• O caso de uso deve ser fácil de ler.

• As descrições não devem incluir qualquer menção ao projeto ou implementação.

• Eventos que não estão relacionados ao objetivo do caso de uso não devem ser descritos.

• A descrição deve ser completa.

• A estrutura deve ser correta e não ambígua.

• A terminologia deve ser consistente.

Também a própria especificação de requisitos para servir de base a um produto de boa qualidade deve satisfazer a uma série de características de qualidade, a seguir citamos as características propostas por Pádua (2001), mas não entraremos nos detalhes de como executar ou avaliar a qualidade dos requisitos.

• Correta: todo requisito presente realmente é um requisito do produto a ser construído.

• Precisa: todo requisito presente possui uma única interpretação.

• Completa: reflete todas as decisões de especificação que foram tomadas.

• Consistente: não há conflitos em nenhum subconjunto de requisitos presentes.

Caso de Uso Abstrato

Caso de Uso concreto

usa

• Verificável: todos os requisitos têm um processo finito, que possa ser executado por uma pessoa ou máquina.

Como os requisitos serão utilizados para desenvolver o framework as inconsistências e ambigüidades deverão ser encontradas e resolvidas nessa etapa.

A documentação gerada nessa fase é a Especificação dos Requisitos onde os requisitos devem ser descritos de forma sucinta, sem entrar nos detalhes. A sua definição produz uma lista de todos os requisitos funcionais e não funcionais.

Deve-se observar que os requisitos não funcionais de um framework são diferentes dos requisitos não funcionais das aplicações, pois os usuários do framework são os desenvolvedores. Assim, por exemplo, a linguagem de programação, os padrões e outros itens podem fazer parte destes requisitos.

Resumo:

Passo 2.1 : Coleta de Requisitos

Entrada: Modelo do domínio, aplicações existentes, usuários e pessoas com conhecimento no domínio

Procedimentos:

• Obter informações sobre os requisitos a partir de diversas fontes, tais como grupos de usuários e pessoas com conhecimento no domínio através de entrevistas e reuniões.

• Verificar, nas aplicações existentes, os requisitos funcionais e não funcionais comuns e gerar a lista de requisitos do framework.

• Verificar características relevantes do domínio e abstraí-las para a lista de requisitos do framework.

• Criar casos de uso abstratos, através da revisão dos documentos da especificação de requisitos.

Saída:

• Modelo de Requisitos

o Especificação de Requisitos.

o Casos de Uso abstratos.