Uma Proposta para Melhorar o Rastreamento de Requisitos
Uma Proposta para Melhorar o Rastreamento de Requisitos
Uma Proposta para Melhorar o Rastreamento de Requisitos
Requisitos
1. Introdução
Classificação Meta-modelo
Rastreamento
de
Requisito
Processo Modelo intermediário
Inintermediário
2. Trabalhos relacionados
Elemento Relacionamento
nome : String
descrição : String
Agregação
1 especialização
ElementoGeneralizável
éAbstrato : Booleano pai Alocado
éRaíz : Booleano
*
éFolha : Booleano
1 Generalização
destino filho descritor : String
origem
*
generalização Associação
AdornoClasseAssociativa
2
Classe grau
AdornoAssociação
arvore
nivelInformação
multiplicidade : String
ClasseAssociativa 2
informação ou um elemento físico. Por exemplo, uma proposta de mudança usa como
recurso de informação os requisitos do sistema.
Uma instância da meta-associação Responsabilidade visa capturar a participação,
responsabilidade e ação das pessoas sobre artefatos ou elementos do processo de
software. Por exemplo, a participação e responsabilidade de uma pessoa com relação
a um susbsistema, pode ser classificada como analista e programador.
A representação dos requisitos nas linguagens de modelagem, ou de programação,
é natural no processo de desenvolvimento de software. Para capturar a representação
dos requisitos em outras linguagens, propomos uma associação chamada
Representação.
Uma instância da meta-associação Alocado é uma associação que expressa que a
classe origem está relacionada com uma instância da classe destino, que representa
um subsistema.
Finalmente, o relacionamento de agregação ajuda a expressar que um elemento
está composto de outros elementos.
Os objetivos desta seção são: fornecer uma visão geral do modelo intermediário e
identificar alguns dos seus benefícios. Um modelo intermediário é um modelo de
rastreamento, que não é básico, nem avançado para incluir todos os elementos de
todos os possíveis modelos de rastreamento de diversos sistemas. Este modelo é
resultado de uma combinação de fatores, tais como: boas práticas, estudos de casos,
abstração, aplicação do nosso meta-modelo e dos níveis de informação, e uma
extensão do trabalho de Ramesh ([Ramesh, 2001]). A Figura 5 apresenta o modelo
intermediário. No modelo, existem algumas notações para identificar os diferentes
tipos de relacionamentos: Satisfação (<sat>), Recurso (<rec>), Responsabilidade
(<resp>), Representação (<rep>), e Alocado (<alo>).
Na Figura 5, a raiz da estrutura hierárquica é a classe Informação e algumas das
suas subclasses são: InformaçãoAmbiental, InformaçãoOrganizacional,
ObjetivoSistema, Tarefa, Requisito, Diagrama, Programa e Subsistema.
A classe InformaçãoAmbiental é uma abstração de todos os possíveis tipos de
informações do nível de informação ambiental. A classe InformaçãoOrganizacional
é uma abstração das informações do nível de informação organizacional. As classes
Tarefa e ObjetivoSistema, representam algumas das informações do nível de
informação gerencial. As classes: Requisito, Diagrama, Programa e Subsistema,
representam algumas das informações do nível de informação de desenvolvimento.
O relacionamento recursivo dep_recurso_para, sobre a classe Informação, é
herdado pelas suas subclasses. Conseqüentemente, o modelo de rastreamento de um
projeto pode expressar diretamente uma relação de dependência de recurso entre as
subclasses da classe Informação. Por exemplo, os objetivos, estratégias e/ou regras de
uma organização podem ser recursos de informação para criar os objetivos de um
sistema.
O relacionamento dep_informação (de InformaçãoOrganizacional para
InformaçãoAmbiental) é uma abstração das possíveis dependências de recurso das
200 WER 2002
Restrição
InformaçãoAmbiental
0..n 0..n
dep_informação
satisfeita_por
<rec>
<sat>
0 0..n
dep_recurso_para InformaçãoOrganizacional
<rec> 1..n
1..n 0..n 0..n
0..n 0..n
Informação
dep_propMud
dep_info_org dep_infor <sat>
<rec> <rec>
0..n 0..n
0..n 0..n
fonteInformação ObjetivoSistema PropostaMudança
Requisito
0..n Programa
Tarefa
Organizacional ObjetivoOrganizacional
Pessoa
Gerencial
ObjetivoSistema
Requisito Diagrama, Programa
Desenvolvimento
Subsistema
[OBO-1] <A;A;cri>
[OBO-2] <A;A;cri>
[OBO-3]
[OBO-4] <A;A;cri>
[OBO-7] <A;A;cri>
[OBO-8]
[OBO-9] <A;A;cri>
[OBO-10]
Fig. 7. Exemplo do uso da nomesclatura
[REQ-1] O sistema deverá permitir a inclusão de usuários com os seguintes campos de informação:
Código de Pessoa, Nome Completo, Endereço,……
[REQ-2] O sistema deverá permitir a inclusão de dados referentes ao usuário, caso este seja um
operador do sistema de bibliotecas com o seguinte campo de formação: Nível de acesso.
[REQ-3] O sistema deve permitir a consulta dos dados do usuário pelos campos: Nome,
Sobrenome ou Nº de identificação. O retorno da consulta mostra todos os dados do usuário.
[REQ-4] O sistema deve permitir alterar os dados do usuário. O único campo que não pode ser
alterado é o Código da Pessoa Física.
0..n
dep_rec_org ObjetivoOrganizacional
ObjetivoSistema
0..n <rec> 0..n
0..n Programa
1 0 ..n
responsavel_por
representado_em <resp>
<rep> 1 ..n
dep_objetivoSistema Pessoa
0..n
<rec> 1..n
responsavel_por_req
<resp> fonteInformação_para
0..n
<rec>
1..n 1..n
0..n 0..n
Requisito
0..n 0..n 0..n 0..1
representado_em_diag alocado_em
depende_de <alo>
<rep>
0..n <rec> 0..n
Diagrama Subsistema
Diretriz 15: Definir uma matriz para cada relacionamento do modelo. O objetivo
desta diretriz é desenvolver várias matrizes ou listas para representar os
relacionamentos do modelo de rastreamento. A Figura 7 é um exemplo da
representação matricial de um relacionamento.
Requisitos Programas
(Caminho lógico)
8. Conclusões
Finalmente, este trabalho foi aplicado em vários projetos desenvolvidos com e sem
orientação a objeto. Em ambos, os estudos de casos têm contribuído para melhorar
várias partes do nosso trabalho. Futuros trabalhos visam relatar os resultados obtidos
em nossos estudos de cas os e nas aplicações feitas em [Castro, 2002] e [Pinto, 2001].
Uma Proposta para Melhorar o Rastreamento de Requisitos 209
Referências