O artefato
Glossário, contido na
disciplina de requisitos do
Rational Unified Process e do
OpenUP, costuma ter pouca utilização prática dentro das empresas. Pouca gente conhece sua potencial utilidade e, neste artigo, tratarei sobre esse assunto. Provavelmente essas idéias ajudarão muitos analistas de requisitos e analistas de sistemas a melhorar a qualidade de seus requisitos.
As informações que passarei foram sumarizadas e baseadas no livro
Use Case Modeling de Bittner e Spence, no livro
Patterns for Effective Use Cases de Cockburn et al e na apostila do treinamento oficial "
Mastering Requirements Management with Use Cases" da IBM Rational.
Quando a técnica de modelagem de casos de uso é utilizada para especificar requisitos funcionais de um sistema, muitos analistas de sistemas acham que a definição todos os atributos, tamanhos e domínios das entidades não está sob sua responsabilidade. Mas é claro que esses elementos fazem parte dos requisitos a se levantar junto com os usuários.
Por exemplo, vamos supor que se esteja definindo os requisitos de um sistema de e-commerce. Se o analista de requisitos disser em um caso de uso que o cliente pode alterar as informações de perfil de cliente, porém não incluir quais são essas informações, o que o desenvolvedor fará? Ele irá perguntar para o analista de requisitos. E o analista de requisitos fará o que? Perguntará para o usuário :-) !
Portanto esses atributos e seus respectivos tamanhos e domínios precisam estar documentados. Mas se eu inserir estas informações na especificação de caso de uso o que ocorrerá?
ProblemasExemplo de especificação de caso de uso "complicada":
...
Passo 4 - O cliente informa ao sistema os dados de Nome, Endereço e Sexo do Perfil do Cliente.
Passo 5 - O sistema valida os dados do Perfil do Cliente. Nome deve ter 40 posições - alfanumérico; Endereço deve ter 2 linhas de 60 posições cada uma - alfanumérico; Sexo deve ter 1 posição - caractere - domínio: F para Feminino ou M para Masculino.
...
Terei dois problemas graves:
1 - Especificações de casos de uso gigantes, com dezenas de páginas.
2 - O mais grave: quando você utilizar uma entidade em vários casos de uso você gerará duplicação de informações em diferentes artefatos. Essa falha levará a sérias dificuldades na manutenção dessa documentação e ocasionará possíveis erros quando alguém esquecer de alterar um atributo em todos os casos de uso que o referenciam.
SoluçãoColoque, além de uma definição simples acerca da entidade, TODOS os atributos e seus respectivos tamanhos e domínios dentro do Glossário. Dessa forma você centralizará essas informações em um único artefato. O Glossário então se tornará um elemento essencial para o desenvolvimento do sistema e atuará também como uma espécie de dicionário de dados do negócio.
ExemploExemplo No Glossário:
Entidade Perfil do Cliente -> entidade que representa as informações básicas de um cadastro realizado pelo próprio usuário do site de e-commerce.
Atributos:
Nome: 40 posições - alfanumérico
Endereço: 2 linhas de 60 posições cada uma - alfanumérico
Sexo: 1 posição - caractere - domínio: F para Feminino ou M para Masculino
...
Na especificação de caso de uso a dica é usar algo para realçar uma entidade que está descrita no Glossário. Defina um padrão para seu projeto. No exemplo abaixo eu padronizei que todas as entidades descritas em uma especificação de caso de uso estarão em itálico.
Exemplo em uma especificação de caso de uso:
...
Passo 4 - O cliente informa ao sistema os dados do
Perfil do Cliente.
Passo 5 - O sistema valida os dados do
Perfil do Cliente....
Portanto, usem o glossário como uma ferramenta essencial da documentação de requisitos. Vocês notarão a melhoria no entendimento dos casos de uso e a facilidade de manutenção que essa técnica proporcionará.
Marcadores: caso de uso, OpenUP, requisitos, RUP
