Requisitos de Usuário x Requisitos Funcionais

[James Mommensohn]

Pessoal

Qual é a diferença entre os requisitos de usuário e requisitos
funcionais? Como diferenciá-los no momento da elicitação? Existe
alguma técnica que possa facilitar o analista de negócios?

Abraços,

James

[Claudio Br (Kerber)]

No livro do Howard (The BA Handbook) existe alguma diferenciação, mas nunca vi vantagem em separar as coisas.

Requisito do usuário [User requirement]

“Os requisitos do usuário descrevem necessidades de um grupo específico de partes interessadas em relação à solução proposta. Eles podem ser usados para descrever como um conjunto particular de usuários de uma solução irão interagir com ela e como um produto irá atender as necessidades de diferentes grupos de clientes.

Um requisito do usuário é aquele satisfeito por uma solução de TI escrito da perspectiva do usuário. Uma prática recomendada é documentar os requisitos do usuário como casos de uso de sistema.   Os requisitos do usuário são um componente dos requisitos funcionais documentados pelo BA e empacotados em documentos como o DRN. (Veja requisito funcional).

---

[1] A Guide to the Business Analysis Body of Knowledge[r], Release 1.6 [c]2006, International Institute of Business Analysis, p. 192.

Requisito funcional [Functional requirement]

“Os requisitos funcionais definem as funcionalidades do software que os desenvolvedores devem construir para permitir que os usuários realizem as suas tarefas.”[1] “Tipicamente os requisitos são amplamente caracterizados como funcionais ou não funcionais. Os requisitos funcionais descrevem as capacidades que o sistema será capaz de desempenhar em termos de comportamentos ou operações – uma resposta ou ação específica do sistema. Requisitos funcionais são melhor expressados utilizando-se verbos.”[2]

Por favor note que o uso do termo requisito funcional não é uniforme; em algumas aplicações ele se refere apenas aos requisitos da perspectiva do sistema. A seguir a definição usada neste livro:   Um requisito funcional descreve o que o sistema deve ser capaz de fazer; ele é um comportamento externamente visível que um sistema deve ser capaz de desempenhar. Os requisitos funcionais incluem recursos e comportamentos escritos da perspectiva do cliente, usuário e do sistema.   Os casos de uso são um meio recomendado para a representação de requisitos funcionais. Um exemplo de um requisito funcional da perspectiva do sistema é “O sistema deve ser capaz de designar um número único para cada pedido”.   O BA é responsável por elicitar, documentar, validar e verificar requisitos funcionais.   Os requisitos funcionais são um componente dos requisitos documentados pelo BA e é empacotado em documentos como o DRN.

---

[1] Wiegers, Software Requirements, p. 8.

[2] A Guide to the BABOK[r], 4/7/2005 (IIBA), p. 4.

Também existe uma confusão com o termo "requisitos do negócio", uns usam como requisitos no nível do negócio, como desenhos de processos de negócio, outros usam como sendo quaisquer requisitos que tenham como origem o pessoal do lado do negócio (o que para mim é 99% dos requisitos da solução).


Aproveito para anunciar que a versão em português do BA Handbook está na editora e em breve será vendida no Brasil.


abraço,
Claudio Br

--
Mensagem do grupo AN-BR {Análise de Negócios}.
Para publicar mensagens, mande um email para: an...@googlegroups.com
Para cancelar sua participação, mande um email para: an-br-un...@googlegroups.com
Para mais opções, visite a página do grupo: http://groups.google.com/group/an-br?hl=pt-BR

Este grupo é administrado pelo Capítulo SP do IIBA - http://www.theiiba.org.br/

--
Atenciosamente,
Claudio Br

"Above us only ROI..." http://bit.ly/9Pqwoj

........_˜Ô
...._  \ >_
...(_) /  (_)

Siga-me no Twitter @oclaudiobr, mas aviso: também estou perdido.

[Fabrício Laguna]

James,

A literatura é realmente confusa nessa divisão. Não há uma definição clara que se aplique a todas as situações.
De maneira geral poderíamos entender da seguinte maneira:

• Requisitos de negócio: Objetivos da organização (Ex: Gerenciar estoque)
• Requisitos de stakeholder (ou de usuário como em Wiegers): Objetivos de uma classe de usuários (Ex: Consultar lista de itens com estoque menor que o mínimo)
  
• Requisitos funcionais: Coisas que o sistema deve fazer (Ex: Listar os itens em ordem alfabética)

O que faz um pouco mais de sentido é uma noção hierárquica desses requisitos:

1 Requisito de negócios gera
vários Requisitos de Stakeholder e cada um deles gera
vários Requisitos Funcionais

Os requisitos de Stakeholder são portanto algo que faz a ponte entre os de negócio e os funcionais.

Na prática, muitas organizações desencanam dessa classificação de requisitos e acaba adotando outras que fazem mais sentido para sua realidade prática.

Eu gosto da seguinte visão que relaciona técnicas de análise com os tipos de requisitos:

• Requisitos de negócio: Processos organizacionais
  
• Requisitos de stakeholder: Diagrama de casos de uso
  
• Requisitos funcionais: Passos de sistema na descrição de casos de uso

Outras estruturas podem ser propostas. O importante é a adequação para a maneira como a organização irá entender, comunicar e gerenciar os requisitos e que a rastreabilidade possa ser mapeada.

Um abraço,

   inté

     Fabrício

[Anderson Valentim de Bastos]

Desencana desta classificação.. ela é confusa mesmo.

O importante é o resultado.

[Claudio Br (Kerber)]

Em suma, o Anderson disse tudo.

Em 11 de fevereiro de 2011 21:27, Anderson Valentim de Bastos <anderso...@gmail.com> escreveu:

Desencana desta classificação.. ela é confusa mesmo.

O importante é o resultado.

--

Mensagem do grupo AN-BR {Análise de Negócios}.
Para publicar mensagens, mande um email para: an...@googlegroups.com
Para cancelar sua participação, mande um email para: an-br-un...@googlegroups.com
Para mais opções, visite a página do grupo: http://groups.google.com/group/an-br?hl=pt-BR
 
Este grupo é administrado pelo Capítulo SP do IIBA - http://www.theiiba.org.br/