modelagem-de-requisitos
13 pág.

modelagem-de-requisitos


DisciplinaAnálise e Projeto de Sistemas371 materiais6.531 seguidores
Pré-visualização5 páginas
Análise \u2013 1 
 http://erinaldosn.wordpress.com 
Modelagem de Requisitos: Casos de 
Usos 
 
Um caso de uso é uma situação em que o sistema é usado para preencher um ou mais 
dos requisitos do seu usuário, um caso de uso captura um pedaço de funcionalidade que o 
sistema proporciona. Os casos de uso estão no centro do seu modelo, mostrado na figura 
abaixo, uma vez que eles afetam e guiam todos os outros elementos dentro da modelagem do 
seu sistema. 
 Os casos de uso são um excelente ponto de partida 
ara a faceta quase todos os desenvolvimento de sistema 
orientado a objetos, projeto, testes e documentação. Eles 
descrevem os requisitos de um sistema estritamente a partir 
do olhar de fora, eles especificam o valor que o sistema 
oferece aos usuários. Como os casos de uso são requisitos 
funcionais do sistema, que deve ser a primeira saída 
sério de seu modelo depois que um projeto é iniciado. 
Afinal, como você pode começar a desenhar um sistema 
se você não sabe o que vai ser obrigado a fazer? 
Os casos de uso especificar apenas o que seu 
sistema deve fazer, ou seja, os requisitos funcionais do sistema. Eles não especificam o que o 
sistema não deve fazer, ou seja, requisitos não-funcionais do sistema. Os requisitos não 
funcionais geralmente incluem metas de desempenho e linguagens de programação, etc. 
Quando você está trabalhando com os requisitos de um sistema, muitas vezes surgem 
perguntas como se o sistema tem uma exigência particular. Os casos de uso são um meio para 
trazer essas lacunas nos requisitos do usuário para o primeiro plano no início de um projeto. 
É ainda melhor quando a exigência é apresentada como um caso de uso e a parte 
interessada (stackholder) vê que a exigência tem pouco ou nenhum valor para o sistema. Se um 
stackholder pode descartar exigências desnecessárias, tanto dinheiro e tempo são poupados. 
Casos de uso podem ajudar a gerenciar a carga de trabalho de um projeto. Seus casos de 
uso podem ser atribuídos às equipes ou pessoas a serem implementadas e, uma vez que um caso 
de uso representa um valor usuário tangível, você pode acompanhar o andamento do projeto por 
casos de uso entregues. Se e quando um projeto tem problemas de cronogramas, casos de 
uso podem ser descartados ou atrasados para entregar o de valor mais alto mais rápido. 
Os casos de uso também ajudam construir os testes de para o seu sistema. Os casos de 
uso fornecem um excelente ponto de partida para a construção de seus casos de teste e 
procedimentos, porque precisamente capturaram os requisitos do usuário e critérios de sucesso. 
Capturando um requisito do sistema 
Os termos obrigação e deve tem um significado especial e exato quando se trata de 
requisitos. Um requisito obrigatório deve ser cumprido, se o recurso que implementa um 
requisito obrigatório não está no sistema final, então o sistema não atende a esse requisito. 
Um requisito que deveria existir implica que o requisito não é crítico para o funcionamento do 
sistema, mas ainda é desejável. Se o desenvolvimento de um sistema está funcionando 
com problemas que irá causar atrasos na entrega, então os requisitos que deveriam existir são 
muitas vezes sacrificados em primeiro lugar. 
Suponha que você está definindo requisitos para um sistema de gerenciamento de 
conteúdo weblog (SGC). 
2 \u2013 Modelagem de Requisitos: Casos de Uso 
 http://erinaldosn.wordpress.com 
Requisito 1: O sistema de gerenciamento de conteúdo deve permitir que um 
administrador crie uma nova conta de blog, desde que os dados pessoais do novo blogueiro 
sejam verificados usando o banco de dados de credenciais de autor. 
Não há realmente uma "melhor maneira" específica para começar a analisar um 
requisito, mas é útil em um primeiro passo olhar para as coisas que interagem com o sistema. 
Em casos de uso, essas coisas externas são chamadas de atores. 
Atores 
Um ator é desenhado em notação UML usando um "homem vara" ou uma caixa 
estereotipada e é rotulado com um nome apropriado. 
O requisito contém um ator Administrador que 
interage com o sistema para criar uma conta de blog. O 
administrador interage com o sistema e não faz parte do 
sistema e, portanto, o administrador é definido como um ator. 
Os atores não têm que ser pessoas reais. Enquanto 
um ator pode ser uma pessoa, ela também poderia ser um sistema de terceiros. Pense em um 
ator como uma caixa preta: você não pode mudar um ator e você não está interessado em saber 
como ele funciona, mas ele deve interagir com o sistema. 
Nem todos os atores são sistemas externos ou pessoas óbvias que interagem com o 
sistema. Um exemplo de um ator comum complicado é o relógio do sistema. O nome por si 
só implica que o relógio faz parte do sistema, mas é realmente? 
É difícil determinar se o relógio do sistema é um ator, porque o relógio não está 
claramente fora do seu sistema. Como se vê, o relógio do sistema é frequentemente descrito 
como um ator, porque não é algo que você pode influenciar. Além disso, descrevendo o 
relógio como um ator vai ajudar ao demonstrar que o sistema precisa realizar uma tarefa com 
base no tempo atual. 
 
Aqui estão algumas perguntas a perguntar-se quando se tenta identificar um ator: 
Identidade uma "coisa" de um de seus requisitos 
A "coisa" é uma pessoa 
real interagindo com o sistema? 
A "coisa" é algo que eu posso 
mudar no projeto do sistema? 
 
Sim Não A "coisa" provavelmente é 
 Análise \u2013 3 
 http://erinaldosn.wordpress.com 
um ator. Tenha cuidado 
quando se trata de pessoas, 
algumas pessoas podem ser 
consideradas parte de seu 
sistema. 
Não Sim A "coisa" provavelmente não 
é um ator. Qualquer coisa 
que você pode afetar e ter 
algum controle sobre ao 
projetar seu sistema é 
susceptível de ser considerada 
uma parte do seu sistema. 
Se você focar apenas os usuários óbvias de seu sistema, então você pode esquecer de 
outras pessoas, tais como auditores, instaladores, mantenedores, atualizadores, e assim por 
diante. Esses atores podem ter poder de veto ou eles podem ter de cumprir importantes 
requisitos não-funcionais, como uma atualização em uma janela de tempo de inatividade de 10 
minutos do sistema e uma atualização sem desligar o sistema, etc. Se estes atores são ignorados, 
estas funções importantes do seu sistema não serão documentadas, e corre o risco de acabar 
com um sistema inútil. 
Alguns atores estão relacionados uns aos outros. 
 
Casos de uso 
Depois de ter capturado um conjunto inicial de atores que interagem com seu sistema, 
você pode montar o modelo exato dessas interações. O próximo passo é encontrar casos onde o 
sistema está sendo usado para completar um trabalho específico para um ator. Os casos de uso 
podem ser identificados a partir dos requisitos do usuário. 
Um caso de uso, ou trabalho, pode ser tão simples como permitir que o usuário efetue 
login ou tão complexo como a execução de uma transação distribuída em vários bancos de 
dados globais. A coisa importante a lembrar é que um caso de uso, a partir da perspectiva do 
usuário, é um uso completo do sistema, haver alguma interação com o sistema, bem como 
alguns resultados dessa interação. 
Um caso de uso em UML é desenhado como uma forma oval com um 
nome que descreve a interação que ele representa. O caso de uso é 
provavelmente a única construção mais poderosa em UML para garantir que o 
sistema faz o que é previsto fazer. 
Há uma regra que pode ser usada para especificar um bom caso de uso: 
Um caso de uso é algo que dá algum resultado mensurável para o usuário ou um 
sistema externo. 
Qualquer parte do comportamento do sistema que atende a esse teste simples é provável 
que seja um bom candidato para um caso de uso. 
4 \u2013 Modelagem de Requisitos: Casos de Uso 
 http://erinaldosn.wordpress.com 
Linhas de comunicação 
Vamos mostrar que o ator Administrador participa do caso de uso Criar uma nova Conta 
de Blog usando linhas de comunicação. 
A linha de comunicação