Comments on: Casos de Uso, Requisitos Funcionais e Probleminhas [Atualizado]

By: Luiz David Szilagyi

Luiz David Szilagyi — Mon, 22 Feb 2010 17:25:32 +0000

Eu acho interessante o debate, mas acho que as escolas estão misturadas. o Cockburn, é um dos pais do XP, e quando ele fala sobre casos de uso, o enfoque metodológica é diferente. O Wiegers, também era agnóstico até pouco tempo atrás, quando ele emprestou o seu conhecimento para a Microsoft. Outro ponto, para que não haja confusão é que o caso de uso puro, como foi inventado pelo Jacobson, tem por intuito descrever os requisitos funcionais. Existe um bom compêndio a respeito de separação de requisitos funcionais (hoje a normal e amplamente aceita da IEEE), do Swebok. Obviamente existem diversas tentativas de conversão de um para outro e etc.
Particularmente sou da opinião que uma vez adotada uma linha, não se deve mudar, e um pouco mais além, não se deve comparar. Depois de dar muita aula sobre engenharia de requisitos pura, descobri que quanto mais falava de Jacobson, mais especialistas em Cockburn apareceiam com dúvidas.
Outra coisa que acho que deve ser separa são casos de uso de negócio. Finalmente não posso deixa de dizer, que se sua abordagem é mais ampla, como por exemplo o processo unificado, ou qualquer um dos seus sabores, terá que ser considerado a visão 4+1, disciplinas que vêm antes e depois (aliás pelo que me lembro o Bitner trabalhou na Rational). Nessa situação o caso de uso, nunca vai dizer como fazer, pois isso é papel da disciplina de design.

By: Ronan Lucio

Ronan Lucio — Wed, 02 Jul 2008 12:48:36 +0000

Paulo,

Concordo em gênero, número e grau com a sua linha de pensamento.
Mais especificamente com as colocações:

“i) Os Casos de Uso “são realmente os requisitos”; e ii) Mas não representam todos os requisitos.”

“um caso de uso deve se limitar a explicar o QUE o usuário precisa, não COMO sua necessidade será satisfeita.”

Penso que o real conjunto de requisitos funcionais e não-funcionais são aqueles que levarão ao alcance das metas e objetivos do negócio.

Portanto, mesmo que um (alguns?) requisito não tenha sido previsto na etapa de análise, tanto pelo Analista de Negócios quanto pelo cliente, ele ainda é um requisito, uma vez que ele deveria ser parte integrante da solução proposta para o alcance mas metas e objetivos desejados.

O objetivo do negócio não deve (ou pelo menos não deveria) deixar de ser atingido devido a uma falha de Análise de Negócio (seja por ineficiência do AN ou por omissões do cliente).

Sei que o parágrafo acima soa estranho, mas a realidade é que somos humanos, e como tal é importante termos um processo de desenvolvimento que nos permita correções e ajustes em busca da melhor solução.

Ronan

By: Rendiconti: O Seminário GP e o Caso Criado » finito

Rendiconti: O Seminário GP e o Caso Criado » finito — Wed, 14 May 2008 16:54:12 +0000

[...] n’água”, um terrível engano deste que aqui rascunha? Tentarei responder no próximo post. Inté! Está aqui a versão completa da apresentação (PPT – 3mb). Completa: Inclui as fotos de [...]