Analise sistemas 01 Aula 02

Prévia do material em texto

Análise de Sistemas – Aula 03
Processos RUP para Requisitos
O analista de requisitos
Compatibilização com normas e modelos
• Modelos de conhecimentos internacionais (ISO, CMMI, SWEBOK)
▫ Orientam a empresa e o Analista sobre o que devem fazer para 
garantir uma boa especificação de requisitos. São guias.
 EX: Deve-se levantar os Requisitos Funcionais e Não Funcionais
• Os modelos, diagramas e padrões internacionais (Ex: RUP)
▫ Orientam a empresa e o analista sobre como devem para 
investigar, reunir, levantar dados e informações.
 Ex: Como fazer uma reunião de brainstorm.
▫ Orientam também como devem documentar e quais diagramas
podem ser usados para documentar os requisitos.
 Ex: Pode-se usar o diagrama de Caso de Uso como um dos documentos 
dos requisitos pois gera boa compreensão para o cliente e usuário.
Processo RUP para Requisitos
• O RUP é uma maneira de desenvolvimento de software que é 
iterativa, centrada à arquitetura e guiada por casos de uso.
• O RUP é um processo de engenharia de software bem definido e 
bem estruturado. O RUP define claramente quem é responsável 
pelo que, como as coisas devem ser feitas e quando fazê-las.
Fases do Processo RUP
• Como é interactivo, as fases se complementam.
• Erro achar que o projecto e implementação começam no fim dos 
requisitos.
Processos de Requisito no RUP
• Definido um conjunto de 
processos e para cada 
processo um fluxo de 
trabalho com papéis, 
artefactos e 
actividades.
• Estas actividades não 
ocorrem linearmente 
pois estão distribuídas 
nos ciclos que 
percorrem as fases do 
modelo interactivo.
Processos de Requisito no RUP
• Analisar o Problema (concepção):
▫ Obtenção de uma visão uniforme do sistema pelas partes 
envolvidas. Identificar os stakeholders. Definir os limites do 
sistema. Obter um acordo quanto ao problema a ser resolvido. 
Identificar as restrições do sistema (económica, técnica, 
ambiental, etc).
▫ Artefactos principais:
 Visão
 Plano de requisitos
 Vocabulário comum
 Casos de uso e fluxos
 Estados
 Telas
 Classe de Análise
Analisar o Problema (concepção):
• Fase inicial do processo de requisitos.
• Estabelecemos um entendimento básico do problema, as pessoas 
que querem uma solução e a natureza da solução.
• Definimos o escopo (abrangência) e a natureza do problema a ser 
resolvido.
• Identificamos a necessidade de negócio e cria-se uma visão 
aproximada e uma descrição operacional do projecto.
• Obtemos uma visão uniforme do sistema pelas partes envolvidas. 
Cada usuário tem uma visão diferente do sistema.
• Identificamos os stakeholders. Definir os limites do sistema.
Na prática
• Entendimento do problema por meio de um conjunto de questões que podem 
ser formuladas ao cliente:
• Identificar o problema:
▫ Quais os problemas esta solução irá tratar?
▫ Quais os impactos actuais do problema?
▫ O que se espera do sistema? O que deve controlar?
▫ Qual será o benefício económico e operacional esperado com esta solução?
▫ Quais os ambientes de negócio em que esta solução será usada? (outros 
sistemas instalados, quantidade de pessoas, locais de uso do sistema)
▫ O que seria uma boa solução esperada?
▫ Quais os limites do sistema em relação a prazos, recursos, orçamento?
▫ Há outros limites que a solução deve respeitar (técnica, política, 
ambiental, local…)
• Registo:
▫ Registe as informações preliminares no documento de Visão.
Compreender as necessidades dos stakeholders
• Obter informações de todos os usuários e clientes de forma a 
compreender suas necessidades e usá-las para a definição das 
características do sistema.
• Realiza levantamento, análise e especificação.
• Artefactos principais:
▫ Visão (revista).
▫ Casos de uso (revistos). Descrição inicial dos fluxos principais de 
cada caso de uso.
▫ Vocabulário comum (revisto).
▫ Lista de requisitos dos stakeholders (clientes).
Na prática
• Identificar os envolvidos (stakeholders)
▫ Quem irá usar a solução?
▫ Quem irá beneficiar-se com o sistema de forma directa e 
indirecta?
▫ Quem são os responsáveis pela solução do problema?
▫ Quem são os usuários (gerentes de operações, gerente de 
produto, marketing, usuários internos, clientes externos etc.)?
▫ Quais as áreas de actuação de cada um?
• Registo:
▫ Liste todos os envolvidos e se possível seus nomes. Diferencie os 
envolvidos dos usuários.
▫ Outros dados serão acrescentados ao longo do processo: sua 
responsabilidade no sistema, tipo de usuário, envolvimento no 
projecto, papéis que irá desempenhar no projecto, 
Checklist do documento de visão (RUP)
• Você já explorou totalmente o que os problemas por trás do 
problema?
• A declaração do problema está corretamente formulada?
• A lista de interessados é completa e correta?
• Será que todos concordam com a definição dos limites do sistema?
• Se os limites do sistema foram expressos usando atores, todos os 
atores estão definidos e corretamente descritos?
• Você explorou suficientemente as restrições para colocar no 
sistema?
• Você cobriu todos os tipos de restrições - por exemplo, política, 
econômica e ambiental?
• Ter todas as principais características do sistema foram 
identificadas e definidas
• Será que os recursos para resolver os problemas foram 
identificados?
Definir um vocabulário comun
• Identificar um vocabulário comum
▫ Pesquisar os termos e expressões mais utilizados no ambiente 
em que o sistema será utilizado.
▫ É necessário diferenciar os termos para não haver ambiguidade.
▫ Em um sistema de gestão de uma clínica, pode ser que a 
expressão “processo médico” signifique muitas coisas. Deve-se 
definir o que ela significa para o projecto actual.
▫ Exemplo de expressões confusas: website, sistema, página, 
processo, paciente, usuário, etc...
• Registo
▫ Criar um glossário com os termos de acordo com o domínio do 
problema. Estes termos serão utilizados em todos os 
documentos.
▫ Registe as informações no documento Glossário.
Processos de Requisito no RUP
• Definir o Sistema
▫ Refina e complementa as fases anteriores, gerando documentos 
e modelos mais elaborados e completos.
▫ Entende que quase todas as necessidades do cliente e as 
alternativas de solução do problema foram compreendidas.
▫ Compreende um trabalho de análise e especificação.
 +=
 Especificação dos Requisitos do Sistema (SRS).
 Casos de Uso (descrever de forma completa os fluxos de execução de 
cada caso de uso).
• Gerenciar Escopo do Sistema
▫ Busca garantir que os objectivos do projecto são alcançados. 
Prioriza e selecciona os requisitos que farão parte do sistema.
 +=
 Prioridades de casos de uso.
Processos de Requisito no RUP
• Refinar as definições do sistema
▫ Detalhar o fluxo de execução de cada caso de uso, pré e pós 
condições, fluxos alterativos, de excepção.
▫ Detalhar a Especificação de Requisitos do Sistema (SRS) com as 
restrições que não se aplicam a nenhum caso de uso. Listar os 
requisitos (lista dos casos de uso).
▫ Em caso de prototipação, modelar a interface e criar o protótipo.
▫ Artefactos principais:
 Casos de Uso
 Especificação dos Requisitos do Sistema (SRS).
 Especificações suplementares.
• Gerenciar Requisições de Mudança
▫ Recebe solicitações de mudança nos requisitos.
▫ Efectuar análise de impacto de cada solicitação de mudança.
▫ Actualizar definições, documentos, modelos e diagramas após.
Modelagem de Análise
• Alguns autores (Pressman E.S 7.ed.) 
indicam a necessidade da modelagem 
dos requisitos estender-se até a 
modelagem de classes de análise.
• Classes de Análise:
▫ Utiliza-se uma modelagem de classes 
sem detalhes relevantes nos métodos 
como os parâmetros, tipo de cadaparâmetro, encapsulamento, gets e 
sets, fronteiras, etc.
▫ Inclui as associações entre as classes 
e a multiplicidade.
Usuario
#nome: String
#email: String
#senha: String
#usuario: String
#morada: String
#situacao: int = 1
#categoria: int
#/data_registo: Date
+registar(): int
+consultar(String): String
+alterar(String): int