No post anterior iniciamos a discussão sobre como conseguir minimizar os problemas enfrentados com os requisitos de software.
A solução mais aplicada é o Gerenciamento dos Requisitos e anteriormente vimos como que deve ser identificado um requisito de software para conseguir realizar o devido gerenciamento.
Recapitulando, cada requisito de software necessita ter uma identificação única, uma espécie de ID de identificação.
Não existem padrões bem formalizados sobre como determinar este ID de identificação, mas, algumas ferramentas de gerenciamento de requisitos, que veremos posteriormente, sugerem algumas identificações.
Hoje, lhes apresentarei o seguimento dos conceitos sobre gerenciamento de requisitos, abordando o conteúdo de relacionamento entre requisitos, fundamental para se conseguir efetivamente aplicar o gerenciamento de requisitos. Contudo, vale lembrar que se tratando de produtos de software, existem diversos tipos de requisitos funcionais e não funcionais e todos podem ser relacionados no processo de gerenciamento de requisitos. Para relembrar, revejam o post sobre O que são Requisitos de Software?.
Relacionamento entre Requisitos de Software:
Os requisitos de sistema possuem muitas relações entre si e entre informações relativas ao projeto. Em razão disso, quando são propostas modificações é preciso avaliar o impacto destas mudanças sobre os requisitos e sobre o projeto do sistema. Assim, a facilidade de rastreamento é importante e trata-se de uma propriedade da especificação dos requisitos que reflete na facilidade de se encontrar requisitos que são relacionados. Existem três tipos de informações básicas sobre a facilidade de rastreamento que podem ser mantidas (SOMMERVILLE, 2003):
-Rastreamento da Origem: vinculam os requisitos aos stakeholders que propuseram os requisitos. Quando é sugerida uma mudança nos requisitos é possível consultar os envolvidos na sua definição inicial para avaliação desta mudança;
-Rastreamento de Requisitos: vinculam requisitos dependentes entre si. Estas informações permitem avaliar quantos requisitos poderão ser afetados com a solicitação de mudança proposta, bem como a extensão das mudanças conseqüentes nos requisitos que podem ser necessárias;
-Rastreamento do Projeto: vinculam os requisitos aos módulos do projeto em que estes requisitos estão implementados. Estas informações são utilizadas para avaliar o impacto das mudanças nos requisitos, as propostas para o projeto e a implementação do sistema;
A representação das facilidades de rastreamento normalmente é realizada com o uso de matrizes que relacionam os requisitos aos stakeholders, os requisitos entre si e aos módulos do projeto. Utilizando de exemplo a representação da relação dos requisitos entre si, cada requisito será representado por uma linha e por uma coluna na matriz. Onde houver a dependência entre os requisitos ela seria apontada na intersecção entre a coluna e a linha, conforme FIGURA 1 (SOMMERVILLE, 2003).
A solução mais aplicada é o Gerenciamento dos Requisitos e anteriormente vimos como que deve ser identificado um requisito de software para conseguir realizar o devido gerenciamento.
Recapitulando, cada requisito de software necessita ter uma identificação única, uma espécie de ID de identificação.
Não existem padrões bem formalizados sobre como determinar este ID de identificação, mas, algumas ferramentas de gerenciamento de requisitos, que veremos posteriormente, sugerem algumas identificações.
Hoje, lhes apresentarei o seguimento dos conceitos sobre gerenciamento de requisitos, abordando o conteúdo de relacionamento entre requisitos, fundamental para se conseguir efetivamente aplicar o gerenciamento de requisitos. Contudo, vale lembrar que se tratando de produtos de software, existem diversos tipos de requisitos funcionais e não funcionais e todos podem ser relacionados no processo de gerenciamento de requisitos. Para relembrar, revejam o post sobre O que são Requisitos de Software?.
Relacionamento entre Requisitos de Software:
Os requisitos de sistema possuem muitas relações entre si e entre informações relativas ao projeto. Em razão disso, quando são propostas modificações é preciso avaliar o impacto destas mudanças sobre os requisitos e sobre o projeto do sistema. Assim, a facilidade de rastreamento é importante e trata-se de uma propriedade da especificação dos requisitos que reflete na facilidade de se encontrar requisitos que são relacionados. Existem três tipos de informações básicas sobre a facilidade de rastreamento que podem ser mantidas (SOMMERVILLE, 2003):
-Rastreamento da Origem: vinculam os requisitos aos stakeholders que propuseram os requisitos. Quando é sugerida uma mudança nos requisitos é possível consultar os envolvidos na sua definição inicial para avaliação desta mudança;
-Rastreamento de Requisitos: vinculam requisitos dependentes entre si. Estas informações permitem avaliar quantos requisitos poderão ser afetados com a solicitação de mudança proposta, bem como a extensão das mudanças conseqüentes nos requisitos que podem ser necessárias;
-Rastreamento do Projeto: vinculam os requisitos aos módulos do projeto em que estes requisitos estão implementados. Estas informações são utilizadas para avaliar o impacto das mudanças nos requisitos, as propostas para o projeto e a implementação do sistema;
A representação das facilidades de rastreamento normalmente é realizada com o uso de matrizes que relacionam os requisitos aos stakeholders, os requisitos entre si e aos módulos do projeto. Utilizando de exemplo a representação da relação dos requisitos entre si, cada requisito será representado por uma linha e por uma coluna na matriz. Onde houver a dependência entre os requisitos ela seria apontada na intersecção entre a coluna e a linha, conforme FIGURA 1 (SOMMERVILLE, 2003).
FIGURA 1 – Matriz de Facilidade de Rastreamento (SOMMERVILLE, 2003)
Na FIGURA 1 são apresentadas letras para relacionar os requisitos entre si. A letra “U” ilustra que o requisito na linha utiliza os recursos especificados no requisito nomeado na coluna (SOMMERVILLE, 2003).
A letra “R” representa a relação fraca entre requisitos. Por exemplo, ambos os requisitos podem definir partes de um mesmo subsistema (SOMMERVILLE, 2003).
A matriz de facilidades de rastreamento pode ser utilizada quando um pequeno número de requisitos precisa ser gerenciado. Porém, se torna onerosa a sua utilização para manusear um grande número de requisitos. Para sistema com grande quantidade de requisitos, precisamos registrar as facilidades de rastreamento em um banco de dados de requisitos, onde cada requisito é explicitamente vinculado a requisitos relacionados. O impacto da mudança seria verificado através de recursos de visualização do banco de dados. Em razão disso é que se utilizam ferramentas CASE para realizar este apoio no processo de gerenciamento de requisitos (SOMMERVILLE, 2003).
Na terceira parte, pretendo lhes apresentar as técnicas efetivas de realização do rastreamento de requisitos. Aguardem!
Cordialmente,
Marcelo Schumacher
http://isosoftware.blogspot.com/
Bibliografia:
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.
Bibliografia:
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.
Olá,
ResponderExcluirRealmente está questão de relacionamento entre requisitos causa uma grande dependência entre registros impedindo muitas vezes de atualizarmos uma informação sem fazer o update em outras.
Não tenho conhecimentos práticos de relações com complexidade mas com certeza esse tipo de mapeamento apresentado é de grande valia até mesmo em nossos trabalhos de aula para pegarmos o bom hábito assim quando necessitar para uma aplicação de cunho comercial conseguiremos monitorar e documentar as relações entre os ID's.
Abraços,
Thiago Corrêa