Smarana

Discussões sobre Memória Organizacional em ambientes de desenvolvimento de Software

Engenharia Ágil de Requisitos

Há algum tempo eu venho escrevendo um livro de requisitos… paro, recomeço, paro de novo… a coisa tem andado muito devagar com a grande quantidade de atividades em que venho me envolvendo. Mas sairá um dia! Quem viver, verá. 🙂

Comecei nesses dias a tentar dar uma convergência para essas atividades. Uma decisão tomada é escrever os requisitos do projeto Smarana usando minha idéias expostas no livro apenas para atestar a validade ou pelo menos apontar deficiências do modelo que estou visualizando. Comecei a futucar essa ferida e já tenho um caminho mais ou menos traçado. Não vou poder colocar todas as ideias que tenho sobre requisitos aqui, se não vai tomar muito tempo e paciência do leitor. Então, vou direto ao hands-on, iniciando a conversa após o levantamento de User Stories. Alguns elementos estão violando a escola vigente de UML, mas o fiz conscientemente por acreditar ser melhor (no livro, as justificativas e fundamentações). Lembrem-se: aqui estou falando só da descrição (no livro eu trato de toda a atividade).

1. Procure identificar padrões comportamentais. Escreva-os pensando no máximo de reuso. Algumas dicas são:

  • Foque no diálogo e nas atividades de alto nível
  • Esqueça detalhes. Se houver, por exemplo, uma validação a ser feita, apenas aponte sua existência, não informando o que é validado.
  • Esqueça objetos. Se uma ação exige um objeto e ele não for genérico, seu lugar não é no padrão comportamental – indique o objeto em regra ou especialize o comportamento (prefiro a primeira opção)
  • Deixe o mínimo possível para descrever nas especializações. Deixe apenas precondições, gatilhos e poscondições para descrever nelas. Generalize até as referências a Regras de Negócio – dê um nome à regra, de forma que o obrigue a descrevê-la depois para cada especialização. Depois voltarei à organização das regras.

2. Crie Casos de Uso para atender suas User Stories, colocando-os nos diagramas herdando do padrão comportamental que você criou. Quanto melhor descrito for o Caso de Uso genérico, menos terá que descrever a especialização.

3. Crie um pacote para o que eu chamo de “entidades conceituais”. São os objetos trabalhados em cada Caso de Uso. Por exemplo, Setor é uma entidade trabalhada em Criar Setor, Alterar Setor, Consultar Setor, Pesquisar Setor, Excluir Setor, Aprovar Setor etc. Note que o termo entidade não nos remete diretamente à implementação. Estamos identificando que elementos serão manipulados pelo sistema.

4. Crie uma classe para cada entidade conceitual. Ela conterá apenas diagramas e outros elementos indicativos de suas regras de negócio, apontadas pelos Casos de Uso (preferencialmente os genéricos). Depois de concluído o levantamento de requisitos, elas poderão “migrar” para outro pacote, de análise. Assim não há perda da informação do que é pertinente a cada classe (ela vai “evoluindo” conforme o desenrolar do ciclo de vida) e a integridade dos requisitos permanecerá intacta.

5. Inclua na classe todas as regras que precisar – diagramas, texto, arquivos etc.

  • Aqui eu tenho um problema… como estou trabalhando com o Astah Community, não tenho muita opção de agregar tipos diferentes de informação. Por isso, estou criando um Diagrama de Casos de Uso só com anotações de regras de negócio dentro da classe, além dos diagramas já contemplados na UML.

Percebam a atividade pulou praticamente do genérico para as regras de negócio, com uma criação de “bolinhas nos diagramas” para indicar que padrão comportamental representa aquele Caso de Uso. E é mais ou menos isso que acontece. No Smarana eu criei 83 Casos de Uso (ainda tem uns 12 que lembrei hoje) e descrevi apenas 6 (mais 9 Casos de Uso que não avaliei a pertinência de comportamento padrão). Quanto a regras de negócio, não tem mágica… tem que escrever mesmo (nem que seja para referenciar um documento externo, como uma lei).

Tentei incluir imagens para ficar mais claro. Quem quiser, pode ir (depois desse final de semana, quando farei o upload) no Smarana pegar o arquivo com esses requisitos e dar uma fuçada. Ainda não coloquei os gatilhos ou diagramas de navegação. Dêem um desconto… comecei isso tem uns 2 dias só entre trabalho, posts, malhação (não a novela), alfredlibrary… 🙂

Espero que gostem.

Anúncios

Um comentário em “Engenharia Ágil de Requisitos

  1. Rodrigo
    sexta-feira, outubro 1, 2010

    101 Casos de Uso. Apenas 9 desses são padrões comportamentais totalmente descritos.

    Nem sei se serão necessários os gatilhos com a criação do mapa de navegação – mas é algo a se pensar ainda. Se assim o for, 92 Casos de Uso criados e posicionados no diagrama para mostrar interação, responsabilidades e escopo do sistema sem sobrecarregar com a descrição.

    Tudo isso em pouquíssimo tempo (menos de 8h com certeza absoluta).

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Informação

Publicado em quinta-feira, setembro 30, 2010 por em Requisitos.

O Autor

Twitter

Goodreads

Oath of non-allegiance

Oath of non-allegiance

Oath of non-allegiance

%d blogueiros gostam disto: