Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- casos_de_uso:conceitos-uc [02/06/2015 20:02] – criada moises.simoes
+++ casos_de_uso:conceitos-uc [31/08/2017 01:11] (atual) – edição externa 127.0.0.1
@@ Linha 1: / Linha 1: @@
+[[:casos_de_uso|{{casos_de_uso:uc-icon.png?nolink&80 |}}]]
+\\ \\ \\
 ====== Premissas para Especificação e Estimativas de UC ======
@@ Linha 4: / Linha 6: @@
  **Casos de Uso:**
-  * Trata-se do tipo mais comum de representação de cenários na na fase de elicitação de requisitos, deve descrever a o comportamento do sistema em termos de sequência de ações.
+  * Trata-se do tipo mais comum de representação de cenários na fase de elicitação de requisitos. Deve descrever o comportamento do sistema em termos de sequência de ações.
+  * Documento narrativo que descreve a sequência de eventos de um ator, usuário de um software, que vislumbra completar um processo de negócio.
+  * Um caso de uso representa uma unidade discreta da interação entre um usuário (HOMEM ou DISPOSITIVO) e o software.
+  * Um caso de uso deve ser a unidade de um trabalho relevante, como: "autenticação no software", "registrar qualquer informação no software" ou ainda "criar pedidos" são, por definição, todos casos de uso.
+  * Cada caso de uso tem uma descrição da funcionalidade que será construída no sistema proposto.
+  * Um caso de uso pode "usar" outra funcionalidade de caso de uso ou "estender" outro caso de uso com seu próprio comportamento.
+  * Os diagramas de casos de uso, por exemplo, são usados rotineiramente para descrever cenários onde a fronteira separa os atores (usuários ou sistemas no ambiente externo) a partir do comportamento interno, onde cada caso de uso descreve uma funcionalidade do sistema.
+===== Regra Geral =====
+ **Relatórios:**
+  - **Todo o relatório terá seu filtro contido em um único caso de uso**, representado como o fluxo principal. O resultado do filtro será representado como os fluxos secundários, alternativos e de exceção conforme cada situação.
+  - Quando a manutenção evolutiva envolve o controle de uma nova **Entidade**, o **INSERIR**, **MANTER** e **FILTRAR** representam cada um, um novo caso de uso. Neste caso, o FILTRAR é uma ação que retorna os dados exclusivos da Entidade de referência, e pode ser utilizado por qualquer outro caso de uso do sistema, mantendo o paradigma de orientação a objetos, com resultados diretos na manutenibilidade do sistema, bem como, na redução de custos de manutenção evolutiva com o reaproveitamento dessa função.
+ **Quantificação:**
+  - Ver [[:casos_de_uso:regraapuc|aqui!]]
 ===== Referências =====