Tags: , , | Categories: Engenharia de Requisitos, Metodologia Posted by Rafael on 15/05/2011 09:22 | Comentários (5)

Olá pessoal!

Eu gostaria de compartilhar com vocês, nesse pequeno post, na diferença entre Requisito e Requerimento.

Requisito é a necessidade, ou seja, o problema a ser resolvido. Já Requerimento é o pedido formal de uma solução de um determinado problema, para um determinado Requisito. Simplificando, o artefato nasce como Requisito e depois da análise vira um Requerimento.

É comum que as empresas considerem apenas o termo Requisito para ambos os estados (ou momentos) do artefato. Porém, se algum dia você encontrar alguém se referindo a um Requerimento, considere que o Requisito já foi analisado e refinado, transformou-se em Requerimento, ou pedido, para posterior definição da solução do problema ou requisição. O Requerimento pode conter uma proposta de solução, ou não.

Pra quem não sabia, fica aí a dica.

Por hoje é só!

Até a próxima!

Tags: , , , , | Categories: Engenharia de Requisitos, Metodologia Posted by Rafael on 25/02/2011 05:39 | Comentários (0)

Olá pessoal!

Hoje eu gostaria de compartilhar com vocês uma dúvida muito simples, porém interessante na minha opinião, que surgiu durante a confecção de um Diagrama de Use Case em UML 2.0. Eu uso o astah, um aplicatico muito bacana, e o que é melhor, free! O astah, assim como qualquer ferramenta de modelagem UML 2.0, possui dois tipos de Use Case: O Use Case de Sistema e o de Negócio, que são representados pelos seguintes objetos:

Pesquisei um pouco sobre e encontrei uma ótima definição:

"Use cases may be described at the abstract level (business use case, sometimes called essential use case), or at the system level (system use case). The differences between these is the scope.

  • A business use case is described in technology-free terminology which treats system as a black box and describes the business process that is used by its business actors (people or systems external to the process) to achieve their goals (e.g., manual payment processing, expense report approval, manage corporate real estate). The business use case will describe a process that provides value to the business actor, and it describes what the process does. Business Process Mapping is another method for this level of business description.
  • A system use case describes a system that automates a business use case or process. It is normally described at the system functionality level (for example, "create voucher") and specifies the function or the service that the system provides for the actor. The system use case details what the system will do in response to an actor's actions. For this reason it is recommended that system use case specification begin with a verb (e.g., create voucher, select payments, exclude payment, cancel voucher). An actor can be a human user or another system/subsystem interacting with the system being defined."

Fonte: http://en.wikipedia.org/wiki/Use_Case#Business_vs._System_Use_Cases

É uma dica muito simples, mas que eu achei interessante compartilhar com vocês.

Até a próxima!

Tags: , , , | Categories: Engenharia de Requisitos, Metodologia Posted by Rafael on 17/10/2010 01:46 | Comentários (6)

Já ouvi diversas vezes as pessoas falarem: “Este é o Modelo de Casos de Uso do sistema XYZ”, ou então, “Este é o Diagrama de Casos de Uso do sistema XPTO”. Mas, afinal de contas, Modelos e Diagramas são a mesma coisa? Na verdade, Modelos e Diagramas não são a mesma coisa.

Quando dizemos que determinado documento é um Modelo, estamos dizendo que ele contém a definição de todo o sistema, ou seja, é um único documento que possui todas as informações de um sistema, relativas àquele artefato (Caso de Uso, Seqüência, Atividades, etc.). Por exemplo, um Modelo de Caso de Uso de um sistema, possui todos os casos de uso de um sistema.

Diagramas são perspectivas de um determinado Modelo. Criamos Diagramas para facilitar o entendimento (e conseqüentemente o desenvolvimento) de um sistema, ou seja, criamos perspectivas de um determinado modelo. Assim, quando dizemos que determinado documento é um Diagrama de Casos de Uso, sabemos que se trata de uma perspectiva do Modelo de Casos de Uso.

Por isso, sistemas possuem apenas um Modelo de Caso de Uso, e diversos Diagramas de Caso de Uso. O mesmo é verdadeiro para os demais artefatos.