Gustafson (2002) apresenta de maneira sistemática e exemplificada as diversas técnicas disponíveis para a representação e documentação dos requisitos de software. No Quadro 5 é apresentado um resumo das especificidades de cada técnica. Devido à falta de espaço e estas técnicas serem amplamente difundidas em textos de engenharia de software, recomenda-se ao leitor que busque maiores detalhes na referência. # L !" !" # Nome Descrição Data Flow Diagram (DFD)
Surgida na década de 1980, esta modelagem tem como objetivo representar o fluxo de dados num sistema. O DFD busca exibir quais dados estão disponíveis para cada componente e quais são as saídas do mesmo. Deste modo pretende indicar a função do componente e o que se espera que o mesmo faça.
Modelo de Objetos
Representam entidades e as relações entre entidades. Cada entidade é descrita em função de seus atributos e ações características. Cada classe de objetos retrata um elemento do problema que está sendo abordado. Esta é uma técnica mais recente que a técnica do DFD, possuindo características fortemente técnicas, que muitas vezes não são bem compreendidas pelos usuários que colaboram com os analistas nesta fase de levantamento de requisitos.
Modelos de Descrição de Comporta- mento
Não existe apenas um modelo com essa abordagem. No entanto, conceitualmente são similares, e buscam representar o comportamento do sistema de um ponto de vista do usuário. Os modelos existentes são os seguintes:
Caso de uso: utilizando representações gráficas, esta técnica descreve como o usuário executará as funções no software.
Protótipos: são modelos semi funcionais representativos do software a ser desenvolvido. Um protótipo é desenvolvido com base em requisitos preliminares previamente identificados e utilizado para refiná-los ao mesmo tempo que permite a identificação de novos requisitos.
Cenários: são descrições narrativas das regras de negócios típicas da atividade que se quer informatizar e que portanto deverão estar previstas no software em projeto. Diagramas de estado: exibem o estado atual do sistema, representado por seus dados, e a transição de um estado para outro.
Dicionário de Dados
Nesta técnica elabora-se uma tabela contendo informações sobre cada elemento do sistema. Cada elemento é descrito por meio de seus dados básicos, que devem ser acompanhados por tipo de dados, tamanho e atributos.
Fundamental na comunicação entre analistas e programadores, que esta talvez seja a técnica menos adequada para comunicação com usuários.
Diagramas de Sistema
São diagramas mais informais usados para complementar as descrições formais e produzir representações ilustrativas do software ou de um módulo do mesmo. Justamente devido a informalidade desses diagramas é comum verificar o uso de elementos do DFD e dos Casos de Uso em suas representações.
Nome Descrição Padrão IEEE 830 – 1993 para Especificação de Requisitos
Trata-se de um conjunto de tópicos organizados de forma hierárquica que oferece entradas para a descrição de cada parte do software, bem como é flexível a ponto de permitir que os analistas o ampliem para incorporar todos os funcionais e não funcionais.
Observação: Algumas das técnicas elencadas acima visam apenas a descrição de requisitos funcionais.
Trabalhos recentes na área de requisitos de software tratam de evoluir o conhecimento na área em dois caminhos bem definidos:
a) O aprimoramento na comunicação entre analistas e usuários; e
b) A influência mútua entre Requisitos e Arquitetura do Software.
O segundo ítem apontado acima é relatado em trabalhos como Rosa et.al. (2000), Lamsweerde (2003), Bastos e Castro (2005). Este aspecto está relacionado ao tamanho e complexidade crescentes, diversidade de formas de distribuição e heterogeneidade verificadas nos softwares atuais. Estas características causam impacto nos requisitos não funcionais e sua relação com a arquitetura do software. Este aspecto não será estendido em demasia aqui, pois estabeleceu-se um escopo de arquitetura de software para a construção do Simulador, que o coloca em condições bastante controladas quanto ao seu grau de complexidade arquitetural. Isto foi feito justamente para evitar que arquiteturas muito complexas inviabilizem sua construção. Num processo futuro de amadurecimento pode-se evoluir o software, aí sim introduzindo elementos de arquitetura que por hora serão deixadas de lado. Para esclarecer o leitor quanto a esses aspectos que podem introduzir complexidades de desenvolvimento, imagine-se que seja definido que o software deva trabalhar com todos os bancos de dados disponíveis no mercado, bem como ser capaz de trabalhar sem nenhum deles, neste caso armazenando os dados em arquivos XML. Este exemplo mostra um requisito de arquitetura que introduz
complexidade de desenvolvimento e testes, no caso, a previsão de trabalho com variados “engines” de banco de dados, que não acrescenta qualquer valor à pesquisa e ao desenvolvimento do Simulador. Com isso, na análise de requisitos estabeleceu-se que será usado uma determinada tecnologia de armazenamento de dados, deixando-se de lado todos os outros.
Quanto ao primeiro ítem mencionado acima, um problema significativo da fase de análise de requisitos, é a interação entre os analistas de software e os usuários. Como apontam Bahn, et.al. (2002), frequentemente, a diferença de linguagem e terminologia existente entre analistas e usuários produz falhas de comunicação, que levam a deficiências de entendimento e, em última instância, a especificações de requisitos incompletas e deficientes.
Esforços têm sido realizados no sentido de minimizar os efeitos dessas falhas de comunicação. Uma tendência descrita por esses autores, que neste texto será designada pelo termo “Projeto Participativo”, busca trazer os usuários para a equipe de desenvolvimento do software, envolvendo-os fortemente nesta fase de análise de requisitos. O objetivo desta tendência é obter do usuário um “feedback” contínuo, consistente e o mais preciso possível. Isto tem sido conseguido com o emprego de duas técnicas:
.1 Melhorias nas descrições e representações de software preparadas pelos analistas, para serem revisadas pelos usuários;
.2 Padronização e direcionamento do modo pelo qual os usuários revisam os requisitos e relatam as divergências.
Neste contexto, segundo Bahn (2002), protótipos e cenários enquadram-se como instrumentos que estimulam o “feedback” por parte dos usuários e permitem
uma melhor interação entre analistas e usuários. Para definição do que são protótipos e cenários vide Quadro 5 – ítem “Modelos de Descrição de Comportamento”.