3. Engenharia de Requisitos

(1)

Engenharia de Software

(2)

Engenharia de Requisitos

_{Fases do desenvolvimento de software que mais}

erros originam

(3)

Engenharia de Requisitos

(4)

Engenharia de Requisitos

_{Mas afinal o que são os requisitos?}

_{descrições de como o sistema se deve comportar}

_{descrições de propriedades do sistema}

_{descrições de restrições do sistema ou condicionantes}

no seu desenvolvimento

_{descrições de capacidades que um sistema deve}

possuir para satisfazer uma determinada imposição

_{descrição de capacidades que um sistema deve possuir}

(5)

Engenharia de Requisitos

_{Mas afinal o que são os requisitos?}

_Exemplos

“deverá existir sempre uma fotografia associada a cada

docente”

“o sistema deve respeitar as normas de acessibilidade da W3C”

“o sistema deve ser compatível com o IE6”

“os dados dos clientes deverão ser guardados numa base de

dados e as passwords deverão ser encriptadas”

(6)

Engenharia de Requisitos

_{Mas afinal o que são os requisitos?}

_{Os requisitos devem incidir sobre o que é para fazer}

_{A forma como isso será feito será tratada}

(7)

Engenharia de Requisitos

_{Mas afinal o que são os requisitos?}

_{Requisitos funcionais}

_{Descrevem o que o sistema deve fazer}

Contexto do sistema

Reacção a estímulos externos

Estados do sistema

Informação manipulada pelo sistema

...

Ex.: “o sistema deve permitir adicionar utilizadores”

Requisitos funcionais podem ser descritos por Diagramas de

Casos de Uso – UML ou textualmente

(8)

Engenharia de Requisitos

_{Mas afinal o que são os requisitos?}

_{Requisitos não-funcionais}

_{Descrevem as restrições na implementação dos requisitos}

funcionais

Usabilidade

Desempenho

Fiabilidade

Disponibilidade

Segurança

Portabilidade

Tecnologia de implementação

(9)

Engenharia de Requisitos

_{Mas afinal o que são os requisitos?}

_{Requisitos de desenvolvimento}

_{Descrevem restrições ao processo de desenvolvimento do}

sistema e não são perceptíveis pelos utilizadores

Manutenção

Evolução

Documentação

Processo

Orçamento

Recursos humanos

Recursos computacionais

(10)

Engenharia de Requisitos

_{Mas afinal o que são os requisitos?}

_{Documentos envolvidos}

Definição de Requisitos

contém uma lista de tudo o que o cliente espera que o sistema faça.

Define um entendimento entre o cliente e a equipa de desenvolvimento sobre

o que é que o sistema deve fazer.

É escrito pelos clientes e os analistas de requisitos.

Especificação de Requisitos

descrição do documento de definição de requisitos em termos técnicos mais

apropriados à equipa de desenvolvimento e às actividades de desenho.

É escrito pelos analistas de requisitos.

(11)

Engenharia de Requisitos

_{Mas afinal o que são os requisitos?}

_{Principais atributos dos requisitos}

prioridade

esforço

risco

_{Por vezes também é possível prever}

duração

custo

(12)

Engenharia de Requisitos

_{Mas afinal o que são os requisitos?}

_{Níveis dos requisitos}

Alto nível

Missões

Objectivos

Regras do negócio

_{Baixo nível}

Necessidades dos utilizadores

Funcionalidades

(13)

Engenharia de Requisitos

_{Engenharia de requisitos?}

_{Consiste do conjunto de actividades envolvidas no}

processo de criação de um documento de requisitos

Fase 1: descobrir, obter, analisar

Fase 2: especificar, documentar

Fase 3: verificar, gerir, manter

_{Implica a utilização de um conjunto de técnicas e}

modelos que tornam sistemática e repetitiva a

execução destas tarefas

(14)

Engenharia de Requisitos

_{Pessoas envolvidas}

Engenharia

de

requisitos

Especialistas do domínio

Engenheiros de requisitos

Engenheiros de software

(15)

Engenharia de Requisitos

_{Stakeholders (pessoas a quem o sistema}

interessa)

_{são as pessoas que serão afectadas pelo sistema e que}

têm uma influência directa ou indirecta na elaboração

dos requisitos

_{os stakeholders têm diferentes "backgrounds" e}

diferentes objectivos individuais e organizacionais

_{os interesses individuais e de grupo das pessoas}

(16)

Engenharia de Requisitos

_{Engenharia de requisitos?}

Regulamentos

Normas da organização

Necessidades dos utilizadores

Sistemas legado

Informação do domínio

Processo

de

Engenharia

de

Requisistos

Especificação do sistema

Requisitos

(17)

Engenharia de Requisitos

_{Fases do processo de recolha de requisitos}

necessidades dos utilizadores,

sistemas legados,

informação do domínio,

normas organizacionais,

etc.

recolha

análise

documentação

validação

(18)

Engenharia de Requisitos

_{Levantamento vs Desenvolvimento de requisitos}

_Levantamento

gestores

utilizadores finais

(19)

_{Levantamento vs Desenvolvimento de requisitos}

_{Desenvolvimento}

Engenharia de Requisitos

gestores

utilizadores finais

clientes

analistas

documento de requisitos

(20)

Engenharia de Requisitos

_{Levantamento vs Desenvolvimento de requisitos}

_{Os requisitos não são algo que esteja à espera de ver}

levantado

_{Um documento de requisitos deve resultar de um}

processo de negociação e aprendizagem envolvendo

todas as partes

_{No entanto… nem sempre é assim! E por vezes os}

(21)

Engenharia de Requisitos

_{Em que momento deve terminar o processo de}

recolha de requisitos

_{Quando ambas as partes assim o entenderem}

_{Nunca será possível prever à partida todas as}

situações possíveis, pelo que a negociação entre

analistas e clientes deverá manter-se

_{No documento de requisitos deverá estar sempre}

explicito quais os requisitos validados pelo cliente

_{Não deverá nunca ser o programador a tomar decisões}

(22)

Engenharia de Requisitos

_{Pode dizer-se que um documento de requisitos}

está “fechado”?

_{Não! Porque vão sempre surgindo propostas de}

alterações

_{O que não implica que todas essas propostas sejam}

aceites

_{É necessário negociar em três frentes:}

âmbito, duração e custo

(23)

Engenharia de Requisitos

_{Um documento de requisitos aceite pelo cliente}

representa sem dúvidas as suas necessidades ?

_{Nem sempre!}

_{Por vezes o cliente não percebe o que é um}

documento de requisitos

_{Outras vezes o cliente não sabe exactamente o que}

quer

_{Por vezes ajuda utilizar maquetas, protótipos,}

(24)

Engenharia de Requisitos

_{Um documento de requisitos aceite pelo cliente}

representa sem dúvidas as suas necessidades ?

_{É fundamental manter diálogo constante com o cliente}

_{Não basta conduzir actividades de}

_{verificação}

garantir que o produto está conforme os requisitos

documentados

_{…é necessário também conduzir actividades de}

validação

(25)

Engenharia de Requisitos

_{É certo que um cliente aceita um produto que}

cumpra com os requisitos?

_{Pode não acontecer! Para que tal aconteça é}

importante:

Evitar ambiguidades nos requisitos

Quantificar e identificar requisitos não funcionais

Acordar à partida os critérios e testes de aceitação

Se os requisitos documentados e os testes de aceitação

acordados não traduzirem realmente as necessidades do cliente,

pouco há a fazer ...

(26)

Engenharia de Requisitos

_{Gestão de requisitos}

_{Os requisitos mudam durante e depois do}

desenvolvimento

Principais causas

Novas necessidades de clientes e utilizadores

Mudanças na tecnologia utilizada

Mudanças em leis, normas ou padrões

Etc

_{As mudanças nos requisitos podem causar impacto nos}

(27)

Engenharia de Requisitos

_{Métodos de recolha de requisitos}

_{Fase exploratória e de contacto com a realidade}

Análise documental

Observação

_{Fase incisiva de compreensão profunda das práticas}

correntes

Entrevistas

Questionários

(28)

Engenharia de Requisitos

_{Métodos de recolha de requisitos}

_{Análise documental}

Estudar a documentação da empresa de forma a descobrir os

aspectos mais significativos formalizados, políticas, regras,

directivas e indicações relevantes, assim como exemplos

concretos da utilização dos dados e da informação na empresa.

Desta forma o analista obtém a competência necessária para

(29)

Engenharia de Requisitos

_{Métodos de recolha de requisitos}

_Observação

Observar as pessoas no desempenho das sua funções,

acompanhando a execução dos processos, determinando as

interfaces entre processos, o manuseamento dos dados e

levantando as necessidades de informação que estas tem para

executar bem o seu trabalho.

Desta forma o analista detalha a informação anteriormente

obtida na análise documental.

(30)

Engenharia de Requisitos

_{Métodos de recolha de requisitos}

_Entrevistas

Entrevistar utilizadores chave com grandes conhecimentos e

experiência sobre as operações e aspectos do sistema actual,

assim como da necessidade de sistemas futuros com base em

actividades organizacionais em desenvolvimento.

Obter a visão de todos os interessados na empresa (operacionais,

gestores intermédios, gestão topo, clientes do grupo e

(31)

Engenharia de Requisitos

_{Métodos de recolha de requisitos}

_{Questionários}

Questionar as pessoas para obter a clarificação das opções

correctas do sistema, assim como aspectos que exijam a

quantificação, a ordenação por prioridades, a selecção de

procedimentos, a decisão, etc.

(32)

Engenharia de Requisitos

_{E quando uma empresa pretende desenvolver}

um produto para um mercado, e não um produto

à medida para um cliente específico?

_{Análise do domínio e de pontos de variabilidade no}

domínio é fundamental (engenharia do domínio)

_{Normalmente começa-se com clientes concretos e}

depois generaliza-se para um mercado

_{Pode-se desenvolver um produto genérico, altamente}

(33)

Engenharia de Requisitos

_{Qualidade dos requisitos}

_Coerência

não devem ser ambíguos ou incoerentes

_Completude

todos os estados possíveis, alterações de estados, entradas, etc,

devem ser descritos

_Realismo

o que é pedido pelo cliente deve ser realizável

_Clareza

(34)

Engenharia de Requisitos

_{Qualidade dos requisitos}

_Validade

o requisito deve descrever algo que é de facto relativo ao

problema

_{Certificação}

deve ser possível escrever testes que demonstram que o

requisito foi satisfeito

_{Rastreabilidade}

deve ser possível relacionar o requisito com a solução e também

saber qual é a origem do requisito

(35)

Engenharia de Requisitos

_{Documentação de requisitos}

_Linguagem

É uma das formas mais comuns de documentar os requisitos. Consiste

basicamente de uma lista numerada dos requisitos

[R1] - o sistema deve fazer isto,

[R2] - o sistema deve fazer aquilo

…

_{Caso de Uso}

É igualmente uma forma muito comum de representar os requisitos. Neste caso

utiliza-se uma representação gráfica (linguagem UML).

(36)

Engenharia de Requisitos

_{Documentação de requisitos}

_Protótipos

Consiste na elaboração de protótipos visuais que representem exactamente o

que o cliente quer.

São geralmente utilizados como complemento de outros métodos

Poderão ser feitos protótipos descartáveis (imagens, RAD, etc.) ou evolutivos

_{User Stories}

Consiste na escrita de todos os passos que o utilizador faz para executar uma

determinada operação.

_{Para criar uma nova conta o utilizador pressiona o botão “new”, em seguida preenche os campos de}

formulário, nome, morada, …., posteriormente o utilizador escolhe um ficheiro de fotografia, para tal

pressiona o botão “procurar” e escolhe a localização do ficheiro. Finalmente pressiona o botão guardar.