|
 Os
analistas têm a tarefa crucial de definir os requisitos
para o software a criar ou a adquirir. Essa tarefa é
crucial por várias razões. Se as equipas de software
não definirem requisitos excelentes, os projectos terão
que enfrentar vários problemas, incluindo défices de
qualidade, dificuldades em cumprir a calendarização,
expansão excessiva dos requisitos de utilizador e, finalmente,
insatisfação do cliente.
Os custos financeiros
são enormes. Dependendo dos estudos, os projectos de
software normais gastam cerca de um terço do seu orçamento
global a corrigir erros que tiveram origem nos requisitos.
Independentemente de estarmos a definir requisitos para
software novo, para software que irá ser comprado, ou
para software existente destinado a ser melhorado ou
mantido, é fácil perceber a razão porque uma boa compreensão
dos requisitos é um dos aspectos mais importantes para
o sucesso dos projectos.
Por outro lado, o
trabalho que se tem com a definição de requisitos de
alta qualidade é crucial para todos os stakeholders
do projecto (clientes, utilizadores finais, especialistas
em desenvolvimento, especialistas de testes e gestores).
Os vários anos de experiência na definição de requisitos
levaram ao desenvolvimento de várias técnicas e modelos
destinados a auxiliar este processo.
Entre os modelos,
um dos mais conhecidos é o use case (caso de uso), pelo
que é sobre ele que fala este texto. Quem tem experiência
com casos de uso, sabe como são essenciais para o suporte
de muitas das actividades dos projectos, pelo que o
seu objectivo será melhorar a modelação de casos de
uso para poupar tempo e energia. Contrariamente, quem
não tem experiência com os casos de uso, o mais provável
é querer dispor de uma base de boas práticas para começar.
O objectivo deste artigo é fornecer um aconselhamento
prático aos modeladores de casos de uso, tanto aos mais
experientes, como aos que estão a dar os primeiros passos
nesta área.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|
|
