engenharia de requisitos - cee.uma.ptcee.uma.pt/edu/er/slides/er-intro.pdf · o contexto no qual...

1Engenharia de Requisitos - Universidade da Madeira

Engenharia de Requisitos1 - Introdução

Pedro CamposProfessor Auxiliar, Universidade da Madeira

http://dme.uma.pt/pcampos - [email protected]


Agenda

• Apresentação

• Equipa docente

• Definição de ER

• Bibliografia

• Objectivos da disciplina

• Programa da disciplina

• Conceitos introdutórios de ER


Definição de Engenharia de Requisitos

• “A engenharia de requisitos (ER) é um conjunto de actividades dedicadas àidentificação e comunicação do propósito de um sistema de software, bem comoo contexto no qual ele será utilizado.”

• A ER actua como uma ponte entre:

– as necessidades do mundo real dos utilizadores, clientes e outros constituintesafectados por um sistema de software, e

– as capacidades e oportunidades oferecidas pelas tecnologias de software.

• ER não é uma fase nem uma etapa!

• A comunicação é tão importante como a análise!

• ER é sobre o que é preciso e sobre o que é possível!


Bibliografia


Objectivos da disciplina

• Examinar o estado da arte em investigação e prática de ER

– O papel da ER na engenharia de software actual

– Técnicas, notações, métodos, processos e ferramentas de ER

• Obter experiência prática em técnicas de ER seleccionadas

• Compreender a natureza essencial da ER

– Multi-disciplinar, intensiva em comunicação oral e escrita

– Factores contextuais

• Obter fundamentos para investigação em ER

– Metodologias actuais

– Literatura

– Casos práticos e problemas em aberto


Programa resumido

• Introdução à Engenharia de Requisitos

• Contexto e Fundamentos

• Iniciando um Projecto

• Técnicas de Elicitação de Requisitos

• Técnicas de Modelação de Requisitos

– Modelação de Negócios

– Modelação de Qualidade

– Modelação de Informação e Comportamento

• Especificações e Validação

• Gestão da Mudança

• Formalidade


O que são requisitos?

• Dois princípios básicos:

– É útil separar o problema da solução

• ...e documentar o problema separadamente da solução

– Esta separação, na prática, nunca consegue ser atingida na totalidade

• ...porque o design muda o mundo, logo muda também o problema!

• Porque é que a ER é importante?

– Porque o falhanço sai caro, muito caro!

• Domínios de aplicação

– ER é sobre o estudo das actividades humanas, muito mais do que sobrecomputadores e informática!


Separar o problema da solução

Situação doproblema

Enunciado do problema

Enunciado da implementação

Sistema

Co

rres

po

nd

ênci

a

Co

rrec

ção

Ver

ifica

ção

Val

idaç

ão


...Mas o design altera o mundo

Situação doproblema

SistemaMudança

Modelo abstractodo mundo

Enunciado do problema

Enunciado da implementação


Separar o problema da solução

• Uma descrição separada é útil porque:

– O problema mais óbvio pode não ser o problema a atacar

– O enunciado do problema deve ser discutido com os stakeholders

– O enunciado do problema pode ser usado para avaliar decisões de design

– O enunciado do problema é uma boa fonte para casos de teste

• Mas é necessário verificar outros itens:

– A solução resolve correctamente o problema enunciado

– O enunciado do problema corresponde às necessidades dos stakeholders


Sobre a ER

• ER não é necessariamente um processo sequencial

– ER é um conjunto de actividades ao longo de todo o desenvolvimento

• O enunciado do problema será imperfeito

– Os modelos de ER são aproximações ao mundo real

• Aperfeiçoar uma especificação pode custar muito $$$

– A análise de requisitos tem um custo

– Para diferentes projectos, o rácio custo-benefício será diferente

• O enunciado do problema nunca deve ser tido como fixo

– A mudança é inevitável, logo deve ser antevista e planeada

– Deve haver uma forma de incorporar mudanças periodicamente


Importância da ER

• Chaos Report, Standish Group, 1995– O “pai” de todos os relatórios sobre falhanços de projectos de software– 31,1% dos projectos são cancelados antes de terminarem– 52,7% dos projectos custam mais 189% do que a estimativa inicial– Apenas 16% dos projectos são completados a tempo e dentro do orçamento

– Porquê?• Requisitos incompletos (13.1%)• Falta de envolvimento com o utilizador (12.4%)• Falta de recursos (10.6%)• Expectativas irrealistas (9.9%)• Falta de suporte executivo (9.3%)• Alterações aos requisitos e especificações (8.7%)• Falta de planeamento (8.1%)• Sistema deixou de ser necessário (7.5%)


Que fazem os engenheiros de requisitos?

• Existe a noção de que há um PROBLEMA a ser resolvido

– Insatisfação com sistema actual, nova oportunidade de negócio, etc.

• Um engenheiro de requisitos é um agente de mudança!

• O engenheiro de requisitos deve:

– Tornar-se um perito no domínio da aplicação

– Identificar o problema e a oportunidade:• Qual o problema a ser resolvido? (Identificar a Fronteira do problema)

• Onde está o problema? (Compreender o Domínio do problema e o Contexto)

• De quem é o problema? (Identificar os Stakeholders)

• Porque necessita ser resolvido? (Identificar os Objectivos dos stakeholders)

• Como poderia um sistema de software ajudar? (Definir Cenários)

• Quando necessita ser resolvido? (Identificar Restrições ao desenvolvimento)

• O que nos pode impedir de o resolver? (Identificar Riscos)


Processos, métodos e ferramentas

• Notação– Esquema de representação (ou linguagem) para exprimir conceitos

• Exº: Z, lógica de 1ª ordem, diagramas de fluxo de dados, UML, ...

• Técnica– Descreve como realizar uma actividade técnica particular e, se necessário, como

descrever um produto dessa actividade numa dada notação

• Exº: Diagramas de casos de utilização

• Método– Descrição técnica sobre como realizar uma colecção de actividades, focando-se na

integração de técnicas e guias sobre o seu uso

• Exº: OMT, RUP, KAOS, ...

• Modelo de processo– Descrição abstracta de como conduzir uma colecção de actividades, focando-se na

utilização de recursos e dependências entre actividades

• Processo– Actuação de um modelo de processo


Métodos e Processos em ER

• Onde encaixar os métodos de ER nos processos de ER?

– Muitas vezes não é claro onde cada método “encaixa”

• Cada método é apropriado para alguns tipos de domínio de problema

• Os métodos variam na sua cobertura (de actividades de ER) e no foco, por exº:

– Cobertura:

• Elicitação, Modelação, Análise, etc.

– Foco:

• Objectivos, Comportamentos, Pontos de vista


Temas chave da disciplina

• Sistemas de Software (intensivos)

• Mudança contínua

• Desenvolvimento centrado nos humanos

• Uma perspectiva de sistemas

• Abordagem multi-disciplinar

• Gestão do Risco... Contínua!

• Design como reflexão

• Muitos pontos de vista

• ER como uma disciplina de negociação

engenharia de requisitos - cee.uma.ptcee.uma.pt/edu/er/slides/er-intro.pdf · o contexto no qual...

Documents