Obrigado por visitar a devmedia.com.br!

Precisamos de você para divulgar nossos vídeos e cursos gratuitos para a comunidade.

Se você gosta da devmedia.com.br por favor dê-nos o seu clique para o Google+ e ajude outros desenvolvedores ao redor do mundo.



Obrigado por seu apoio!
Equipe DevMedia

sair sem compartilhar (x)
DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:

  #Este é um post fechado

Este post está disponível para assinantes da Engenharia de Software Magazine. Clique aqui para saber mais sobre como abrir este post!




Artigo Engenharia de Software 5 - Especificação de Requisitos com Casos de Uso

Artigo da Revista Engenharia de Software edição 05.

GLB: 1
BRK##: 25 - 26

Esse artigo faz parte da revista Engenharia de Software 5 edição especial. Clique aqui para ler todos os artigos desta edição

 

Engenharia de Requisitos

Especificação de Requisitos com Casos de Uso

Alguns exemplos prontos que você pode tomar como base ao especificar seus requisitos

De que se trata o artigo:

Este artigo apresenta alguns exemplos reais de especificação de casos de uso.

Para que serve:

Seu objetivo é explicitar de forma prática como estas descrições podem ser efetuadas em um nível de detalhe tal que informações importantes para outras etapas do desenvolvimento como planejamento de testes, projeto e desenvolvimento não sejam omitidas.

Em que situação o tema é útil:

O assunto abordado é útil no dia a dia do analista de requisitos na realização de suas atividades.

 

 

A atividade de identificação e especificação de requisitos do software é uma atividade bastante desafiadora. É complexo:

·         Identificar as reais necessidades do cliente;

·         Lidar com clientes;

·         Formalizar as necessidades do cliente através da especificação de requisitos de forma que esta seja de fácil entendimento para o cliente e forneça as informações requeridas pela equipe de desenvolvimento;

·         Lidar com domínios desconhecidos. Entende-se por domínio o contexto para o qual o software está sendo desenvolvido. Por exemplo: contabilidade, medicina, controle de estoque. Para ilustrar esta dificuldade, imagine-se elaborando a especificação dos requisitos de um módulo estatístico para um sistema do mercado financeiro.

 

A lista apresentada não é completa, mas fornece indícios reais da complexidade desta atividade. Existem diversas abordagens que podem ser trabalhadas em conjunto para lidar com estas dificuldades, por exemplo: análise de domínio, prototipação, casos de uso.

O objetivo deste artigo não é apresentar um referencial teórico sobre como lidar com cada questão envolvida nas atividades diárias de um analista de requisitos. Focaremos em um ponto específico de seu trabalho que é a atividade de descrição (especificação) dos requisitos. Faremos isto de forma totalmente prática através da apresentação de um conjunto de casos de uso especificados que poderão servir de inspiração para suas atividades como analista de requisitos.

Contextualização dos Exemplos

As especificações de casos de uso apresentadas neste artigo são fruto da experiência prática dos autores como analistas de requisitos. Eles não objetivam servir de gabarito para futuras atividades de especificação, ao invés disso, podem ser considerados um bom ponto de partida para que possamos ver na prática como podemos escrever casos de uso efetivos. Entende-se por efetivo neste caso o fato do caso de uso conter informações necessárias para que as equipes de projeto e desenvolvimento possam desempenhar satisfatoriamente suas atividades a partir da descrição dos casos de uso.

É importante estar atento também ao fato de que os casos de uso apresentados neste artigo refletem as características de escrita dos autores. Estas características que envolvem itens como nível de detalhamento, informações contidas nos casos de uso, dentre outras, costumam mudar também de organização para organização. Mesmo assim, os exemplos são bastante válidos uma vez que o núcleo básico envolvido na descrição de casos de uso (fluxos principal e alternativos) está presente.



ATENÇÃO! A exibição deste artigo foi interrompida.


  #Este é um post fechado

Este post está disponível para assinantes da Engenharia de Software Magazine. Clique aqui para saber mais sobre como abrir este post!








    2 COMENTÁRIOS

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.



Luiz Cesar De Almeida
Olá Rodrigo e Eduardo,
 
Em primeiro lugar, parabéns pela revista e pelos artigos que vocês vêm escrendo. Estão sendo muito úteis, principalmente para aqueles que estão iniciando nas atividades de gerência de requisitos.
 
Com relação ao artigo desta edição nº 5 da revista, tenho algumas considerações que pretendo fazer apenas para enriquecer o assunto e, claro, ouvir a opinião de vocês a respeito.
 
Bom, para começar vou falar da abordagem que vocês utilizaram para escrever os casos de uso utilizando como base as "telas" do sistema. Esta abordagem me parece adequada somente quando utilizamos a técnica de prototipação para levantar requisitos, pois nem sempre teremos um protótipo de tela para tomar como base na hora de escrever os casos de uso. Outra coisa que acho importante ressaltar é que um caso de uso deve ter como premissa ser independente da sua forma de implementação, e usar "telas" como base pode induzir o analista a direcionar a forma de implementação na descrição do caso de uso. Isso não foi o que aconteceu no exemplo de vocês, claro. Vocês apenas quiseram mostrar como os detalhes dos campos podem ajudar nas atividades de implementação e testes, e fizeram isso muito bem.
 
A segunda consideração diz respeito à forma como documentaram as Regras de Negócio. Como algumas regras podem se aplicar a mais de um caso de uso, eu adotei documentar estas regras separadas dos casos de uso e depois faço a rastreabilidade, como vocês fizeram com os requisitos funcionais. Para isso, eu adotei numerar as regras de negócio sequencialmente, evitando assim, que exista as regras RN1 com duas descrições diferentes em documentos diferentes (como nos exemplos do artigo).
 
Por último, fiquei na dúvida quanto ao termo "criticalidade" usado nos casos de uso. Não seria "criticidade"?
E o exemplo do caso de uso 4 faz referência ao requisito funcional RF3. Acho que houve um erro aí. Me pareceu mais lógico que fosse o requisito RF4.


em 22/9/2008 11:59 - Responder

 

  Devmedia0000
Oi Luiz,

Obrigado pelos comentários! Todos bastante pertinentes. Vamos a eles:


"Bom, para começar vou falar da abordagem que vocês utilizaram para escrever os casos de uso utilizando como base as "telas" do sistema. Esta abordagem me parece adequada somente quando utilizamos a técnica de prototipação para levantar requisitos, pois nem sempre teremos um protótipo de tela para tomar como base na hora de escrever os casos de uso. Outra coisa que acho importante ressaltar é que um caso de uso deve ter como premissa ser independente da sua forma de implementação, e usar "telas" como base pode induzir o analista a direcionar a forma de implementação na descrição do caso de uso. Isso não foi o que aconteceu no exemplo de vocês, claro. Vocês apenas quiseram mostrar como os detalhes dos campos podem ajudar nas atividades de implementação e testes, e fizeram isso muito bem."
 
Quanto ao uso de protótipos, de fato facilita bastante as atividades do analista de requisitos. Ajuda ainda mais a equipe de projeto e desenvolvimento. Não é trivial construir um sistema complexo contando apenas com as informações descristas nos casos de uso (por isso temo utilizado protótipos). Além disso, um outro motivador para termos utilizados prototipos foi facilitar o entendimento do artigo. Fica muito mais fácil para o leitor fazer a leitura do caso de uso e entender seu objetivo ao observar como ele poderia ser representado visualmente.

"A segunda consideração diz respeito à forma como documentaram as Regras de Negócio. Como algumas regras podem se aplicar a mais de um caso de uso, eu adotei documentar estas regras separadas dos casos de uso e depois faço a rastreabilidade, como vocês fizeram com os requisitos funcionais. Para isso, eu adotei numerar as regras de negócio sequencialmente, evitando assim, que exista as regras RN1 com duas descrições diferentes em documentos diferentes (como nos exemplos do artigo)."
 
Perfeita sua colocação. São duas variantes bastante utilizadas para organização das regras de negócio (descritas por caso de uso ou referenciadas no caso de uso)

"E o exemplo do caso de uso 4 faz referência ao requisito funcional RF3. Acho que houve um erro aí. Me pareceu mais lógico que fosse o requisito RF4."

Perfeito. A referência está errada e deveria apontar para o RF4!


em 24/9/2008 20:07 - Responder
 



Autor
Rodrigo Oliveira Spínola

Doutor e Mestre em Engenharia de Sistemas e Computação (COPPE/UFRJ). Diretor de Operações da Kali Software (www.kalisoftware.com). Editor Chefe das revistas Engenharia de Software Magazine, SQL Magazine e Web Mobile.


Space do autor
Estatísticas
Favorito:
Comentários:
Feedback:
Utilidade:
1   0
[Fechar]

Você precisa estar logado para dar um feedback.

Clique aqui para efetuar o login
[Fechar]
Este post está disponível somente para quem é assinante da Engenharia de Software Magazine.
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2012 - Todos os Direitos Reservados a web-03