Comparativo de Modelos de Qualidade de Especificação de Requisitos de Software

Apresenta-se neste capítulo um comparativo entre os modelos de qualidade de especificação de requisitos de software. O objetivo desse comparativo é extrair atributos de qualidade e características que possam servir de regra de elaboração de um modelo de caso de uso e que possam ser verificáveis através de um processo de inspeção.

Analisando os modelos definidos pelo Institute of Electrical and Electronics Engineers - IEEE (1998), Davis et al (1993) e Fabbrini et al (2001), é feito um comparativo, conforme mostra a Tabela 4.

Atributo de qualidade (IEEE, 1998) Atributo de qualidade (DAVIS et al, 1993) Atributo de qualidade

(FABBRINI et al, 2001) Definição

Não ambigüidade (Item 2.12.1.2) Não ambigüidade (Item 2.12.2.1) Compreensibilidade (Item 2.12.3.3)

Termos que dão margem a múltiplas

interpretações devem constar em glossário, com clara definição.

Completeza (Item 2.12.2.2)

Contemplação de todos os requisitos. Completeza

(Item 2.12.1.3)

Definição de resposta do sistema para as entradas de dados em todas as situações, considerando valores válidos e inválidos. Completeza

(Item 2.12.1.3)

Consistência (Item 2.12.3.2)

As referências devem estar numeradas e os documentos anexos devem estar referenciados. Completeza

(Item 2.12.1.3)

Compreensibilidade (Item 2.12.3.3)

Deve haver explicações para todas as figuras, tabelas, diagramas, acrônimos e unidades de medida.

Correção (Item 2.12.1.1)

Correção (Item 2.12.2.3)

A especificação deve representar exatamente o que o sistema deve fazer.

Compreensibilidade (Item 2.12.2.4)

Os requisitos devem ser entendidos pelos envolvidos com o mínimo de explanação. Verificabilidade (Item 2.12.1.1) Verificabilidade, Precisão (Itens 2.12.2.5 e 2.12.2.9) Testabilidade (Item 2.12.3.1)

Todo requisito deve ser preciso, para verificação futura se foi atendido.

Testabilidade (Item 2.12.3.1)

A especificação deve evitar presença de opiniões pessoais, palavras que indicam opção, sentenças com verbos que não exprimem ações, menção a funcionalidades ainda não especificadas. Consistência (Item 2.12.1.4) Consistência interna e consistência externa (Itens 2.12.2.6 e 2.12.2.7)

Os requisitos não podem se conflitar com requisitos do mesmo sistema ou de sistemas externos.

Completeza (Item 2.12.1.3)

Consistência (Item 2.12.3.2)

As referências devem estar numeradas e os documentos anexos referenciados. Também deve haver explicações para todas as figuras, tabelas e diagramas, e definição de todos os termos e unidades de medida.

Alcançabilidade, Prototipação (Itens 2.12.2.8 e 2.12.2.14)

A especificação deve ser acompanhada de protótipo de interface.

Independência de ferramenta (Item 2.12.2.10)

Deve haver mais de uma ferramenta de interface capaz de viabilizar o requisito

Rastreabilidade para frente

(Item 2.12.1.8)

Rastreabilidade (Item 2.12.2.11)

Cada requisito tem que ter um único nome ou nº de referência.

Rastreabilidade para trás

(Item 2.12.1.8)

Cada requisito tem que ter sua origem em documentos iniciais do projeto.

Modificabilidade (Item 2.12.1.7) Modificabilidade, Não redundância (Itens 2.12.2.12 e 2.12.2.18)

A especificação deve ser organizada de forma a ser facilmente modificável. Também deve ser simples, evitando redundâncias.

Modificabilidade (Item 2.12.1.7)

Armazenamento eletrônico (Item 2.12.2.13)

A especificação deve estar eletronicamente armazenada, de forma organizada. Classificação por importância (Item 2.12.1.7) Classificação por importância e por estabilidade (Itens 2.12.2.15 e 2.12.2.16)

Os requisitos devem ser classificados para ajudar na priorização de esforços

Referência à versão (Item 2.12.2.17)

O requisito deve ter referência a qual versão será implementado.

Compreensibilidade (Item 2.12.3.3)

As sentenças devem ter quantidade limitada de palavras e evitar mais de um verbo principal.

A Tabela 4 compara os atributos de qualidade, comparando os nomes dados por cada modelo de qualidade, assim como provê uma síntese das definições atribuídas a cada atributo.

Analisando o comparativo, é possível perceber vários aspectos, descritos a seguir.

O atributo não ambigüidade é definido por IEEE e Davis et al. para a característica de que termos que dão margem a múltiplas interpretações devem constar em glossário com clara definição. A mesma característica é chamada de compreensibilidade por Fabbrini et al.

Fabbrini et al também utiliza compreensibilidade para qualificar a quantidade de palavras na sentença e outras características, tornando, assim, o termo compreensibilidade bastante genérico. Fazendo uma análise do sentido da palavra, é possível interpretar que compreensibilidade é um atributo que engloba os outros atributos, visto que todos os defeitos de uma especificação afetam sua compreensibilidade. A compreensabilidade envolve também aspectos de padronização do caso de uso, que se atendidas aumentam a compreensibilidade para todos os envolvidos.

O atributo completeza, para Davis et al. significa a contemplação de todos os requisitos, enquanto para IEEE significa a definição de fluxos alternativos e a correta referência a anexos, assim como explicações para todas as figuras, tabelas, diagramas, acrônimos e unidades de medida. A contemplação de todos os requisitos deve ser avaliada por usuários finais ou clientes solicitantes do requisito.

O atributo correção diz respeito a uma especificação refletir exatamente a funcionalidade que o sistema deve fazer, e deve ser avaliada por usuários finais ou clientes solicitantes do requisito.

O atributo verificabilidade é mencionado pelas três fontes, com diferenças de denominação, como precisão e testabilidade, e refere-se à precisão das informações, considerando como defeito toda especificação impossível de quantificar, como “pouco, muito” etc.

O atributo consistência é mencionado pelas três fontes, porém com algumas diferenças de interpretação. Para IEEE e Davis et al., a consistência caracteriza requisitos que não se conflitam com outros requisitos, enquanto para Fabbrini et al, a consistência se refere às referências da especificação, que devem se referenciar a documentos numerados.

O atributo prototipação aparece na referência de Davis et al. e também como um documento importante para o acompanhamento da especificação, já que facilita o entendimento do funcionamento do sistema para o usuário e para a equipe de desenvolvimento, desta forma aumentando a compreensibilidade.

O atributo independência de ferramenta é mencionado por Davis et al. e remete a uma característica própria do caso de uso que deve focar em o quê o sistema deve fazer e não em como ele deve fazer, incluindo as ferramentas que deverá utilizar (Spence e Bittner, 2003 p.202 a 203).

O atributo rastreabilidade é diferenciado por IEEE em rastreabilidade para frente e rastreabilidade para trás, sendo que para frente refere-se a cada requisito ter uma identificação, tal como um nome ou um número, e para trás refere-se ao requisito ter a informação de sua origem em outros documentos iniciais do projeto. Davis et al. menciona como atributo de qualidade apenas a rastreabilidade para frente, a qual denomina apenas rastreabilidade.

organização da especificação, manifestada através de índices e referências, e simplicidade, manifestada através da não redundância. Tanto IEEE como Davis et al. consideram que o armazenamento eletrônico é indispensável para alcançar o atributo de modificabilidade.

O atributo classificação por importância é mencionado por IEEE e Davis et al. e se baseiam na idéia de que os requisitos devem ser classificados por importância para poderem ser priorizados. Davis et al. também considera que os requisitos devem ser classificados por estabilidade, ou seja, à probabilidade de mudança do requisito.

O atributo referência à versão é sugerido por Davis et al., que o considera útil quando a entrega do sistema é planejada em mais de uma versão.

Após o comparativo, selecionaram-se os seguintes atributos para compor o modelo de qualidade de modelo de caso de uso: compreensibilidade, completeza, precisão, não ambigüidade, consistência, independência de ferramenta e de interface, rastreabilidade, objetividade. O atributo representação de valor foi adicionado ao modelo, advindo das diretrizes de elaboração de caso de uso. O atributo prototipação recebeu o nome de compreensibilidade, visto ser a compreensibilidade o objetivo da prototipação. Do atributo de modificabilidade foi considerada a definição de que a especificação deve evitar redundâncias, passando o atributo a se chamar compreensibilidade. Os atributos de classificação por importância e referência à versão não foram considerados viáveis no contexto restrito de inspeção de qualidade do modelo de caso de uso, por terem uma utilização voltada para o gerenciamento do processo de desenvolvimento e não restrita à qualidade do caso de uso em si.