sábado, 13 de março de 2010

Requisitos como Promessas da Aplicação

Ajuda pensar em requisitos no sentido de "promessas que uma aplicação" faz para o usuário? Tenho experimentado isso nas aulas (grad e pós) e o efeito tem sido muito positivo. Ao forçar a leitura como "a aplicação promete fazer isso para o usuário", o modelador tende a identificar um requisito funcional mais claramente. Da mesma forma, ao forçar a leitura "a aplicação promete fazer isso obedecendo aquilo para o usuário", um novo requisito regulatório (não-funcional) é identificado.

Além disso, a palavra "promessa" também sugere a possiblidade de não ser cumprida: o modelador conseguirá chegar em uma arquitetura que cumpra todas as promessas feitas pela aplicação para o usuário? Eventualmente, algumas promessas poderão ser cumpridas (alocando-se responsabilidades aos objetos) e outras não, as quais sofrerão um processo de negociação conjunta com o usuário.

Em relação às promessas regulatórias, uma classificação adicional pode auxiliar na identificação de requisitos:
  • promessas de negócio (regras e leis de negócio)
  • promessas de produto (URPS)
  • promessas de metodologia (processo de desenvolvimento, ferramentas, técnicas, práticas e linguagens)... P(Ftp)L

Nenhum comentário:

Postar um comentário