ì Análise e Modelação de Sistemas
AulaT03 -‐ Engenharia de Requisitos Referências:
1 Conceptual Modeling of Informa5on Systems (Secção 1.4) 2 Nuseibeh, B. and Easterbrook, S. 2000. Requirements engineering: a roadmap.
ACM, New York, NY, 35-‐46, DOI= hUp://doi.acm.org/10.1145/336512.336523
3 IEEE Std 830 -‐ IEEE Recommended Prac5ce for SoYware Requirements Specifica5ons
4 Aulas AMS do IST
Engenharia de requisitos
ì Abordagem sistemá>ca à documentação, validação e gestão de requisitos
ì Processo de Engenharia de requisitos ì Elicitação de requisitos ì Análise de Requisitos ì Negociação de requisitos ì Especificação/documentação de requisitos ì Validação de requisitos
Modelação
2
Requisitos e “Stakeholders”
ì Requisitos ì Condição ou capacidade que deve ser sa5sfeita pelo sistema ì Originada de
ì Decisões ou pedidos dos “stakeholders” ì Impostas por standards, regulamentos, leis, etc.
ì “Stakeholders” ì Qualquer um envolvido no ciclo de vida do sistema
ì Análise, desenho, desenvolvimento, manutenção, … ì Qualquer capaz de impor requerimentos ao sistema
ì Dono, u6lizador …
É qualquer um interessado no sistema ou afectado por ele… Modelação
3
Importância dos requisitos…
ì Requisitos ì Mudam ì Diferentes interpretações do problema ì Problemas de comunicação
ì Qualidade dos sistemas de informação ì Funcionalidade (requisitos funcionais) ì Usabilidade e experiência de u5lização (requisitos não
funcionais) ì U5lidade (alinhamento requisitos-‐objec5vos do negócio)
Modelação
4
Modelação de Sistemas e Requisitos
Modelação
5
Requisitos Gerais
Requisitos Específicos
Necessidade… Objec5vos do Sistema
Modelação do sistema
Modelação do comportamento Modelação da estrutura
Modelação do subsistema
Modelação do comportamento Modelação da estrutura
Modelação do subsistema
Modelação do comportamento Modelação da estrutura
Modelação do subsistema
Modelação do comportamento Modelação da estrutura
Modelação
6
Elicitação de
requisitos
Análise e Negociação de
requisitos
Especificação de requisitos
Validação de requisitos
Documento de requisitos
Especificação do sistema
• Objectivos do negócio • Necessidades dos utilizadores • Informação sobre o domínio • Informação sobre sistemas existentes • Leis, regulações, standards,… • …
Processo Geral da engenharia de requisitos
Modelação
7
Elicitação de requisitos
Análise e negociação de
requisitos
Documentação de requisitos
Validação de requisitos
Documento de requisitos
Especificação do sistema
• Objectivos do negócio • Necessidades dos utilizadores • Informação sobre o domínio • Informação sobre sistemas existentes • Leis, regulações, standards, … • …
Processo geral da engenharia de requisitos
Modelação conceptual
Tipos de requisitos
• Requisitos funcionais – Especifica as funções do sistema e das suas componentes – Relacionada com as capacidades específicas do sistema – Representados no desenho do sistema
• Requisitos não funcionais – Refere-‐se ao comportamento geral do sistema na realização das suas funções
– Tipos de requisito não funcionais: – Performance; Escalabilidade; Disponibilidade; Confiabilidade;
Facilidade de Manutenção; Segurança; Sa5sfacção de regulamentos; Usabilidade, Interoperabilidade, Flexibilidade, Extensibilidade
– Representados na arquitectura do sistema Modelação
8
Tipos de Requisitos (Eng. Software)
ì Requisitos de u>lizador. Estes requisitos foram escritos segundo pontos de vista dos u5lizadores finais, normalmente expressados na forma narra5va. Abrangem requisitos funcionais e não funcionais de tal forma que sejam compreendidos pelos u5lizadores que não tenham conhecimento técnico detalhado.
ì Requisitos de sistema. Estes requisitos são especificações detalhadas descrevendo as funções que o sistema será capaz de executar. Só requisitos funcionais
ì Requisitos não funcionais: Os requisitos não funcionais descrevem qualidades do sistema (como o sistema é) ao invés das suas funcionalidades (o que ele faz).
Modelação
9
Exemplos (funcionais)….
Modelação
10
(exemplo de “Systems analysis and design with UML” – ISBN: 978-‐0471348061)
Exemplos (não funcionais)
Modelação
11
(exemplo de “Systems analysis and design with UML” – ISBN: 978-‐0471348061)
IEEE/ANSI 830-‐1993 propõe uma estrutura
para os documentos de especificação de
requisitos
Modelação
12
Norma IEEE para documentos de requisitos
Modelação 13
Elicitação de
requisitos
Análise e Negociação de
requisitos
Especificação de requisitos
Validação de requisitos
Documento de requisitos
Especificação do sistema
• Objectivos do negócio • Necessidades dos utilizadores • Informação sobre o domínio • Informação sobre sistemas existentes • Leis, regulações, standards,… • …
Processo Geral da engenharia de requisitos
Elicitação de requisitos
ì Processo de descoberta de requisitos para um sistema através da comunicação com os “stakeholders”
ì Este processo apoia-‐se em várias técnicas: ì Ques5onários ì Análise de documentos ì Entrevistas ì Workshops/Seminários ì Observação ì Técnicas etnográficas (inserção no ambiente onde o sistema
vai funcionar) ì Proto5pagem ì …
Modelação
14
Questionários ì Relevantes para:
ì Alto número de “stakeholders” da mesma natureza e com as mesmas necessidades
ì Foco em requisitos funcionais
ì Processo ì Seleccionar par5cipantes ì Definir as perguntas e 5po de respostas (abertas, fechadas,
escalas) ì Definir estratégias para assegurar um alto número de
respostas de qualidade ì Comunicar resultados aos “stakeholders”
ì Para validar e mo5var Modelação
15
Análise de documentos ì Quando já há processos ou sistemas operando
(cenário “as-‐is”), mas há a necessidade de mudar o processo e/ou sistema (cenário “to-‐bo”)
ì Documentos Opicos ì Formulários ì Relatórios ì Manuais de processos ì Manuais de sistema ì Manuais de u5lizador ì …
Modelação
16
Entrevistas ì Relevantes
ì Número reduzido e bem iden5ficado de stakeholders, par5cularmente com poder de decisão, altamente especializados e com diferentes visões do sistema
ì Foco em requisitos funcionais
ì Processo ì Prepare-‐se cuidadosamente ì Defina claramente os objec5vos da entrevista ì Seleccione os stakeholders e forneça detalhes com
antecedência de forma a eles poderem preparar-‐se também ì Formule as suas perguntas de forma clara e concisa
Modelação
17
Seminários/Workshops ì Relevantes para
ì Sistemas novos cujos requisitos dependem de grupos heterogéneos de stakeholders que representam diferentes classes de u5lizadores ou decisores
ì Requer um ambiente organizacional flexível e relaxado (será que existe??)
ì Processo ì Prepare vários workshops (2, 3,…) num local apropriado e com o tempo
suficiente (1 dia completo), 8 a 12 par5cipantes é a dimensão ideal ì Um par5cipantes deve registar as decisões tomadas ì Um par5cipante deve agir como moderador (com habilidades de
comunicação) ì 1 o 2 membros da equipa de desenho devem estar presentes (num papel
PASSIVO, só a ouvir) ì Contar com o suporte de um alto execu5vo para efeitos de credibilidade e
sensação de compromisso Modelação
18
Observação e Etnografia
ì Observação dos u5lizadores no seu local de trabalho e registar manualmente (limitado), ou com gravadores de audio ou vídeo (caro)
ì A etnografia é uma prá5ca de observação os aspectos de uma cultura dentro da cultura. O observador é membro do grupo observador.
ì Técnica relevante para elicitar requisitos sociais e organizacionais mas relacionados com a forma em que as pessoas realmente trabalham (e porquê), em vez da forma em os documentos ou processos indicam como deveriam trabalhar
Modelação
19
Modelação
20
Elicitação de
requisitos
Análise e Negociação de
requisitos
Especificação de requisitos
Validação de requisitos
Documento de requisitos
Especificação do sistema
• Objectivos do negócio • Necessidades dos utilizadores • Informação sobre o domínio • Informação sobre sistemas existentes • Leis, regulações, standards,… • …
Processo Geral da engenharia de requisitos
Bons requisitos (ISO Std 830): ì Correctos
ì Não ambíguos
ì Completos
ì Consistentes
ì Ordenados pela sua importância e/ou estabilidade
ì Vericáveis
ì Suscepvveis de modificação
ì Rastreáveis
Modelação
21
Análise de requisitos
ì O propósito da análise de requisitos é encontrar problemas, falhas, inconsistências, etc.
ì A análise de requisitos deve estar interligada com a elicitação ì É importante manter “check lists”
Modelação
22
Check list de requisitos
ì Cada requisito deve ser avaliado em relação a se: ì Inclui informação (prematura) de desenho ou implementação? ì É um único requisito ou pode ser decomposto em vários ì É um requisito real ou “desejo cosmé5co”? ì Implica tecnologia não standard? ì Está alinhado com os objec5vos do negócio? ì É suscepvvel de uma ou várias interpretações? ì É realista face à tecnologia, custos, ou outras restrições? ì É possível desenhar testes para avalia-‐lo?
Modelação
23
Matriz de interacção de requisitos
ì Técnica que ilustra a interacção entre requisitos, e mostra conflictos e sobre posições ì 0 => Requisitos independentes ì 1 => Requisitos em conflicto ì 100=> Requisitos sobrepostos (dizem ou mesmo) ì Nota: a sobreposição pode ser total ou parcial
Modelação
24
R e q u i r e m e n t R 1 R 2 R 3 R 4 R 5 R 6 R 1 0 0 1 0 0 0 1 1 R 2 0 0 0 0 0 0 R 3 1 0 0 0 0 1 0 0 0 1 0 0 R 4 0 0 1 0 0 0 1 1 R 5 1 0 0 1 0 0 R 6 1 0 1 0 0 1 0 0
Modelação
25
Elicitação de
requisitos
Análise e Negociação de
requisitos
Especificação de requisitos
Validação de requisitos
Documento de requisitos
Especificação do sistema
• Objectivos do negócio • Necessidades dos utilizadores • Informação sobre o domínio • Informação sobre sistemas existentes • Leis, regulações, standards,… • …
Processo Geral da engenharia de requisitos
Negociação de requisitos
ì Encontrar soluções para questões como os requisitos em conflicto ou sobrepostos, mas também outros problemas como requisitos não realistas….
ì Requer tempo, paciência e consensos (como imaginam é um trabalho que o computador não pode fazer)
ì Processo: ì Informar: colocar as questões aos stakeholders relevantes ì Discussão: ouvir aos stakeholders; definir prioridade dos
requisitos… ì Solução: tomar decisões
ì Implica apagar, mudar, refinar, …. os requisitos em questão
Modelação
26
Modelação
27
Elicitação de
requisitos
Análise e Negociação de
requisitos
Especificação de requisitos
Validação de requisitos
Documento de requisitos
Especificação do sistema
• Objectivos do negócio • Necessidades dos utilizadores • Informação sobre o domínio • Informação sobre sistemas existentes • Leis, regulações, standards,… • …
Processo Geral da engenharia de requisitos
Especificação de requisitos: Use Cases
ì Especifica requisitos funcionais relacionado-‐os com cenários de u5lização/comportamentais
ì Descrevem a interacção entre o sistema e en5dades externas (um actor)
ì Descrição provista do ponto de vista do actor. Desta forma descreve “quem” faz o quê e como é afectado pelo sistema
Modelação
28
Especificação de requisitos: Use Cases II
ì No documento de requisitos podem ser apresentados antes que a lista de requisitos, porque facilitam uma rápida compreensão da funcionalidade requerida
ì Os use cases são úteis para ligar o documento de requisitos com a modelação detalhada do comportamento do sistema
Modelação
29
Validação dos requisitos
ì Validação: mostrar que os requisitos definem com exac5dão o sistema pretendido
ì Técnicas: ì Revisão de requisitos: análise sistemá5ca dos requisitos por um
ou mais revisores ì Proto5pagem: validar requisitos com potenciais u5lizadores ì Generação de casos de teste: assegurar que os requisitos são
verificáveis ì Os requisitos são expressados em ferramentas que incluem
funções para verificar a consistência
Modelação
30
Algumas ferramentas
ì hUp://easyweb.easynet.co.uk/~iany/other/vendors.htm
ì hUp://www.volere.co.uk/tools.htm
ì hUp://www.soYdevtools.com/modules/weblinks/viewcat.php?
cid=93
ì hUp://soYware.forbes.com/requirements-‐management-‐soYware
ì hUp://www.paper-‐review.com/tools/rms/read.php
ì … Modelação
31
Exercício: Funcional vs Não funcional
1 A apresentação da lista de todos os clientes em ordem alfabé5ca não pode demorar mais de 5 segundos (Não funcional – Performance)
2 Listar todos os clientes em ordem alfabé5ca (Funcional) 3 O sistema de gestão de base de dados deve ser sempre a
versão aprovada de MySQL mais recente (Não funcional – ambiente operacional)
4 Cada vez que se cria um novo u5lizador, deve enviar-‐se uma no5ficação por email ao departamento de marke5ng (Funcional)
Modelação
32
Exercício: Funcional vs Não funcional
5 Todas as interfaces devem ser bilingues (Português e Inglês) (Não funcional-‐usabilidade)
6 O cliente coloca pedidos através do sistema (Funcional) 7 O cliente coloca pedido até 2 min depois de registar-‐se
(Não funcional –performance) 8 O sistema deverá estar indisponível entre 24h00 e 1h00
para os backups (Não funcional -‐ disponibilidade ) 9 A auten5cação far-‐se-‐á via disposi5vos biométricos
(não funcional – segurança)
Modelação
33
Exercício Check list de requisitos
ì Quais elementos da checklist falham os seguintes requisitos? 1 O u5lizador introduz pedidos através de uma interface web
ì Introduz informação prematura 2 O u5lizador gere os seus pedidos
ì Pode ser decomposto em vários, é suscepvvel de várias interpretações
3 O u5lizador pode visualizar a sua encomenda em três dimensões ì É requisito cosmé5co
Modelação
34
Exercício Check list de requisitos
ì Quais elementos da checklist falham os seguintes requisitos? 4 O u5lizador introduz os seus pedidos através de uma “brain
computer interface (u5liza tecnologia não standard) 5 O u5lizador analisa os pedidos (suscepvvel de várias
interpretações) 6 O u5lizador visualiza os seus pedidos (sobre-‐posto com 5) 7 O sistema organiza os pedidos do u5lizador
ì Pode ser decomposto em vários, é suscepvvel de várias interpretações
Modelação
35
Top Related