Embed Size (px)
Citation preview
Técnicas e Projeto de Sistemas
André Mesquita [email protected]@gmail.com
Engenharia de requisitos – Continuação
Técnico Subsequente – Módulo III(05/04/2010)
Engenharia de requisitos
o A Engenharia de Requisitos é o processo de identificar todos os envolvidos (stakeholders), descobrir seus objetivos e necessidades, e documentá-los de forma adequada para análise, comunicação e posterior implementação
o A maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades:
o Elicitação de requisitos
oAnálise de requisitos
o Especificação de requisitos
oValidação de requisitos
Engenharia de requisitos
o Visão geral de UMLo Unified Modeling Language (Linguagem de
Modelagem Unificada)o UML é uma linguagem para visualização,
especificação, construção e documentação de artefatos de um software orientado a objeto
o Visa facilitar a comunicação entre “clientes” e desenvolvedores
Engenharia de requisitos
o Visão geral de UMLo Diagrama de classeso Diagrama de objetoso Diagrama de casos de usoo Diagrama de seqüênciao Diagrama de colaboraçõeso Diagrama de gráficos de estadoso Diagrama de atividadeso Diagrama de componenteso Diagrama de implantação
Casos de uso
o Objetivoo Um diagrama de Caso de Uso descreve um cenário
que mostra as funcionalidades do sistema do ponto de vista do usuário
o O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema
Casos de uso
o Atoreso Um ator é representado por um boneco e um
rótulo com o nome do atoro Um ator é um usuário do sistema, que pode ser
um usuário humano ou um outro sistema computacional
Casos de uso
o Casos de usoo Um caso de uso é representado por uma elipse e
um rótulo com o nome do caso de uso e define uma funcionalidade do sistema
Casos de uso
o Relacionamentoo Entre um ator de um caso de uso
oAssociação: define uma funcionalidade do sistema do ponto de vista do usuário
o Entre atoresoGeneralização: os casos de uso de B são também casos
de uso de A, mas A pode ter seus próprios casos de uso
Casos de uso
o Relacionamentoo Entre casos de uso
o Include: um relacionamento include de um caso de uso A para um caso de uso B indica que B é essencial para o comportamento de A
o Extend: um relacionamento extend de um caso de uso B para um caso de uso A indica que o caso de uso B pode ser acrescentado para descrever o comportamento de A (não é essencial). A extensão é inserida em um ponto de extensão do caso de uso A.
Casos de uso
o Exemplo de diagrama de caso de uso
Casos de uso
o Estudo de caso: ferramenta de EAD (web)o Gerenciamento de aulaso Gerenciamento de conteúdo (usuários não
cadastrados podem baixar)o Gerenciamento de usuárioso Gerenciamento de fórum
o Atoreso Usuários não cadastradoso Alunoso Professores
Requisitos não funcionais
o Requisitos não-funcionais descrevem características do sistema (como o sistema é) ao invés de suas funcionalidades (o que ele faz)
o Podem constituir restrições aos requisitos funcionais
o Assim como os funcionais eles devem ser verificáveis
Requisitos não funcionais
o Uma prática comum é estabelecer a ISO/IEC 9126 como base para especificação dos requisitos não funcionaiso Confiabilidadeo Usabilidadeo EficiênciaoManutenibilidadeo Portabilidade
Requisitos não funcionais
o Confiabilidadeo Capacidade do produto de software de manter um nível de
desempenho especificado, quando usado em condições especificadas
o Exemplo 1: O tempo médio suportado para recuperação de uma falha no sistema nas funcionalidades essenciais para se realizar XPTO deve ser menor que 1 hora
o Exemplo 2: O tempo médio suportado para recuperação de uma falha no sistema em funcionalidade não crucial para a realização de XPTO deve ser menor que 6 horas
Requisitos não funcionais
o Usabilidadeo Capacidade do produto de software de ser compreendido, aprendido,
operado e ser atraente ao usuário, quando usado sob condições especificadas
o Exemplo 1: O sistema deverá fornecer tópicos de ajuda para cada tela apresentada ao usuário, descrevendo o funcionamento e a descrição dos campos da tela
o Exemplo 2: Os usuários deverão ser capazes de utilizar o software, executando todas as funcionalidades disponibilizadas após uma demonstração de no máximo 10 minutos para cada uma das funcionalidades e características do software
o Exemplo 3: O sistema deverá ter como único idioma (Português do Brasil)
Requisitos não funcionais
o Eficiênciao Capacidade do produto de software de apresentar
desempenho apropriado, relativo à quantidade de recursos usados, sob condições especificadas
o Exemplo 1: O sistema deve permitir o acesso de pelo menos 50 usuários simultâneos sem perdas perceptíveis (ao usuário) de desempenho
Requisitos não funcionais
o Manutenibilidadeo Capacidade do produto de ser modificadoo Exemplo 1: Devem ser entregues documentos de
design que especifiquem a arquitetura e o design detalhado do software
o Exemplo 2: O código desenvolvido e entregue deve ser compatível com o produto do design de software
Requisitos não funcionais
o Portabilidadeo Capacidade de um produto ser transferido de um ambiente
para outro
o Exemplo 1: O sistema deve executar sem perda de funcionalidades em ambiente Linux e Windows, utilizando-se o navegador Firefox versão 3.0 ou superior
o Exemplo 2: O servidor que executará a aplicação deverá tem pelo menos 1GB de memória RAM e processador compatível com Pentium V, com um servidor de aplicação Java e um Sistema de Gerenciamento de Banco de Dados devidamente instalados e configurados
o Exemplo 3: A interface gráfica para o ambiente de mesa de trabalho poderá ser executada em máquinas com, no mínimo, 512 MB de memória RAM
Atividade
1. Adequação dos requisitos não funcionais ao contexto do seu projeto
Casos de uso expandido
o Detalha as ações dos usuários no sistema em forma de sequencia de interações dos atores com o sistema
o É criado um caso de uso expandido “para cada” funcionalidade do sistema que está presente no diagrama de casos de uso
o Pode utilizar protótipos de tela para facilitar o entendimento do usuário
Casos de uso expandido
o Elementos do cabeçalhoo Nome do caso de uso com um identificador único
(UC1, UC2, UC3...)o Descrição breve sobre o caso de usoo Ator(es) envolvidos no caso de usoo Pré-condições para realização do caso de usoo Pós-condições que representa o estado do sistema
após a realização do caso de uso
Casos de uso expandido
o Fluxo principalo Descrição numerada da sequencia de passos que o
ator irá executar durante a realização do caso de usoo1...
o2...
o3...
o4...
Casos de uso expandido
o Fluxo alternativoo Ações que ocorrem dentro do sistema, mas que
não correspondem ao fluxo “normal” que o usuário esperava
o Faz referência ao passo que o fluxo alternativo acontece
o 4... no passo 4 o sistema faz XPTO
o Observaçõeso Informações complementares que podem auxiliar
no entendimento do caso de uso
Casos de uso expandido – exemplo
o Processo de autenticação em um sistema web em que é exigido nome de usuário e senha para ter acesso às funcionalidades internas da aplicaçãoo A) a única página do sistema que usuário tem acesso aberto (isto é:
sem estar autenticado) é a página que apresenta o formulário de autenticação.
o B) o sistema deve registrar um log de acesso a cada entrada (log-in) e saída (log-out) do sistema em que as seguintes informações serão armazenadas: nome do usuário, data/hora do log-in ou log-out, IP da máquina e operação realizada (log-in ou log-out).
o C) a seguinte funcionalidade deverá estar presente na sua descrição de caso de uso (seja no fluxo principal ou no fluxo alternativo): “Quando o ator ficar sem realizar ações no sistema por 20 minutos, seu log-out será feito automaticamente”.
Atividade
1. Fazer um exemplo no quadro (turma toda)
2. Cada um deve fazer um caso de uso do seu projeto
Tópicos de revisão
o Engenharia de software, SWEBOK e a relação com Técnicas e Projeto de Sistemas
o Objetivos da Engenharia de Softwareo Por que se preocupar com o processo de
desenvolvimento de software?o Características do produto de softwareo O que é sistema? Software é um sistema?o Hierarquia de sistemas e relações entre sistemaso Sistemas organizacionais
Tópicos de revisão
o Ciclo de vida de software (definição, vantagens e desvantagens)o Ciclo de vida clássicoo Incrementalo Prototipaçãoo Espiralo Técnicas de quarta geração
o Processo de softwareo Como se define um processo?
Tópicos de revisão
o Engenharia de requisitoso Definição e objetivoo Tipos de requisitoso Processo de requisitos
o Elicitação
oAnálise
o Especificação
oValidação
Tópicos de revisão
o UMLo Definição e objetivo
o Diagrama de casos de usoo Definição, objetivo, interpretação e elaboração
o Requisitos funcionaiso Definição e elaboração
o Requisitos não funcionaiso Definição e elaboração
o Casos de uso expandidoo Definição, objetivo, interpretação e elaboração
