Engenharia de Requisitos Adélia Barros [email protected]

Engenharia de RequisitosEngenharia de Requisitos

Adélia Barros

[email protected]

2

Objetivos – Apresentar... Objetivos – Apresentar...

• Importância• Conceitos Básicos• Critérios de Qualidade• Processo de Requisitos• Desafios da Engenharia de Requisitos

Importância da Importância da Engenharia de RequisitosEngenharia de Requisitos


• Requisitos incompletos, inconsistentes, ambíguos e que não atendem as necessidades dos usuários são associados aos principais problemas relacionados ao desenvolvimento de software• insatisfação dos usuários, • imprevisibilidade de prazo e custo, • falta de controle sobre a qualidade do

produto final e• dificuldade de manutenção.


• Estatísticas do Standish Group a partir de 8000 projetos nos EUA, revelam que • 31% deles foram cancelados antes de

serem completados,• 52,7% custaram cerca de 189% dos

valores monetários inicialmente planejados.

• Os gerentes de projeto associaram a ocorrência de mudanças à falta de• envolvimento do usuário (13%), • ao uso de requisitos incompletos (12%) e • à constantes mudanças nos requisitos

(11%).


• Quanto mais tarde problemas com requisitos são detectados, maior é o custo para corrigi-los. • Pode custar até 5x mais, caso o processo já esteja

na fase de codificação, e 20x mais se estiver na fase de manutenção

• O sucesso das etapas posteriores do processo depende da qualidade dos requisitos gerados.

Principais Problemas Principais Problemas com Requisitoscom Requisitos

• Os requisitos não refletem as reais necessidades do usuário.

• Os requisitos são inconsistentes, incompletos e/ou ambíguos.

• É dispendioso fazer mudanças após os requisitos terem sido acordados entre cliente e equipe de desenvolvimento.

• É comum ocorrer interpretação errônea entre clientes e equipe de desenvolvimento.

Conceitos BásicosConceitos Básicosda Engenharia de Requisitosda Engenharia de Requisitos


• Disciplina da engenharia de software cujo objetivo é a concepção dos objetivos e restrições do sistema a partir dos problemas existentes no mundo real

• Com preocupação também na relação entre estes fatores e a especificação precisa do sistema, além de sua evolução.

Zave (1997). Classification of Research Effort in Requirement Engineering. ACM Computing Survey.


Requisitos do sistema

Características dos sistema

Necessidades dos usuários

Domínio do problema

Domínio da solução

Contexto

rast

reab

ilida

d

e

Fatores SociaisFatores SociaisNuseibeh e Easterbrook (2000): Nuseibeh e Easterbrook (2000): “Requirement Engineering: A Roadmap”, 22“Requirement Engineering: A Roadmap”, 22ndnd International Conference on International Conference on

Software Engineering, ICSE´00.Software Engineering, ICSE´00.

“O contexto no qual a engenharia de requisitos encontra-se é usualmente composto por um sistema de atividade humana, e os donos dos problemas que justificam o desenvolvimento do sistema são pessoas.

A engenharia de requisitos é um processo centrado nas pessoas, por isto o resultado do processo é um sistema que irá ser útil, mas alterará as atividades humanas que suportam.

Assim, a engenharia de requisitos deve ser sensível para entender como as pessoas percebem e entendem o mundo ao redor delas, como elas interagem, e como a sociologia do ambiente de trabalho afeta suas ações.

A engenharia de requisitos necessita de ciências como psicologia cognitiva, antropologia, sociologia e linguística para prover teorias que possam servir de base para o processo de elicitação”.


Concepção de nova tecnologia

Re-engenharia organizacional

Fatores sociais

Fatores técnicos

Contexto Presente

Contexto Futuro

Engenharia de RequisitosEngenharia de RequisitosObjetivos EspecíficosObjetivos Específicos

• Definição padrão - o objetivo desta fase é desenvolver uma especificação... • completa, consistente, não ambígua e

correta dos requisitos, ..• que sirva, inclusive, de base para um

acordo entre as partes envolvidas no processo de desenvolvimento do software.

• E quanto às re-engenharias organizacionais? Fazem parte da engenharia de requisitos ?

O que é um Requisito O que é um Requisito ??

• Padrão - Especificação dos objetivos e restrições do sistema, e como o sistema deve se comportar para satisfazê-los. • Uma facilidade do usuário • Uma propriedade geral do sistema • Uma restrição sobre a operacionalização do

sistema • Uma restrição sobre o seu processo de

desenvolvimento

Paradigma doParadigma do “O que” x “Como” “O que” x “Como”

• O “O que” representa os requisitos, ou o que sistema deve fazer.

• O “Como” representa o projeto do sistema, ou seja, como ele irá implementar os requisitos.

Características de um Características de um RequisitoRequisito

• Padrão - Deve conter informações suficientes para gerar uma implementação de um componente de software, bem como viabilizar a realização de testes que verificam se o componente implementa o requisito.• É um problema saber qual o nível de detalhe

necessário!

Classificação de RequisitosClassificação de Requisitos

• Requisitos Funcionais• Orientados à uma ação do usuário (“quando o

usuário faz X, o sistema irá fazer Y”) • Requisitos Não Funcionais

• Requisitos que não são descritos precisamente e não dizem respeito a uma funcionalidade.

• Confiabilidade, usabilidade, desempenho,...• Ao longo do processo, requisitos não

funcionais são usualmente transformados em uma série de requisitos funcionais (operacionalizados) para serem implementados

Critérios de QualidadeCritérios de Qualidade


Os requisitos devem ser corretos: Um conjunto de requisitos é correto

se todos os requisitos acordados realmente representam algo requerido pelo usuário.

Os requisitos não devem possuir ambiguidades: Um requisito é ambíguo se ele pode

ser interpretado de várias formas diferentes.


Os requisitos devem ser completos: Um conjunto de requisitos é completo

se ele descreve todos os requisitos requeridos pelo usuário.

Os requisitos devem ser consistentes: Um conjunto de requisitos é

consistente se nenhum requisito, ou subconjunto de requisitos, está em conflito com outro requisito ou outro subconjunto de requisitos.


Os requisitos devem ser classificáveis por ordem de importância e estabilidade: Os desenvolvedores e clientes precisam

estabelecer atributos nos requisitos para que os mesmos possam ser classificados por prioridade e estabilidade.

Os requisitos devem ser verificáveis: Um requisito é verificável se existe um

processo finito e efetivo para que qualquer pessoa ou máquina possa determinar que o software desenvolvido de fato o satisfaz.


Os requisitos devem ser modificáveis: Um conjunto de requisitos é modificável

se qualquer mudança nos mesmos pode ser feita facilmente e consistentemente sem perturbar suas estruturas ou estilos.

Os requisito devem ser rastreáveis: Um requisito pode ser rastreado se existe

um mecanismo que relaciona aquele requisito com os artefatos gerados na sua implementação.


Os requisitos devem ser passíveis de implementação. Um conjunto de requisitos é passível de

implementação quando for possível a geração de componentes de software que implementem as funcionalidades e restrições especificadas.

Critérios de Aceitação dos Critérios de Aceitação dos Requisitos - CMM-IRequisitos - CMM-I

• Completude, • Não Ambiguidade,• Corretude• Consistência, • Descrição Clara, • Identificação Única, • Rastreabilidade,• Passível de Implementação, • Testável.

Processo de Engenharia Processo de Engenharia de Requisitosde Requisitos

Processo Padrão de Processo Padrão de Engenharia de RequisitosEngenharia de Requisitos

Gerência de Requisitos

Análise de ContextoAnálise de Contexto(Modelar Negócio)(Modelar Negócio)

• Definição de Contexto - norma ISO 9241 • “O contexto de uso consiste dos

usuários, tarefas, equipamentos (hardware, software e materiais), bem como dos ambientes físico e social que afetam o uso do produto”.

Características dos usuários e suas tarefas

ambiente técnico

ambiente social e organizacional

ambiente físico

Fatores do Contexto de Uso Fatores do Contexto de Uso

• Características dos Usuários• experiência, • qualificação, • capacidades cognitivas, sensoriais e

motoras• motivações, • idade, • limitações físicas, • nível de escolaridade,• etc.

Maguire (2001):“Context of Use within Usability Activities”, International Journal of Human-Computer Studies.

Fatores do Contexto de UsoFatores do Contexto de Uso

• Tarefas dos usuários• lista de tarefas, • objetivos e resultado a ser alcançado, • passos, duração, recursos, ferramentas,• fluxo e dependências entre tarefas • dificuldades na realização, • relações entre tarefas informatizadas e

tarefas manuais,• Hierarquia de tarefas• etc.



• Ambiente Físico• ambiente auditivo, térmico, visual e

espacial. • ergonomia, • mobília, • postura do usuário, • vestimentas, • luminosidade,• etc.



• Ambiente Organizacional e Social• processos organizacionais, • políticas e metas da empresa, • fluxo e divisão do trabalho, • regras sociais, • características do trabalho, • relacionamentos de dependências

entre atores• etc.



• Ambiente Técnico• hardware, • software, • rede, • materiais de referência • e outros equipamentos.


Análise de ContextoAnálise de ContextoTécnicas de Coleta de DadosTécnicas de Coleta de Dados

• Entrevistas e Questionários• Etnografia / Observação de campo• Análise de Documentos• Fotos e Vídeos do Ambiente• Análise de Material de Pesquisa de Marketing

• Webpage, etc.• Análise das Interações entre usuários

• E-mails, gravação de conversações, etc.• Testes de usabilidade de sistemas existentes• Manutenção de um diário

Elicitação de RequisitosElicitação de RequisitosConcepçãoConcepção

Análise do contexto futuro

Especificação do Contexto

Feedback do usuário

Análise de Sistemas Competidores

Entrevistas e técnicas de grupo

Problemas

Técnicas de Elicitação Técnicas de Elicitação de Requisitosde Requisitos

• Entrevistas com os usuários sobre o novo sistema• Técnicas de Grupo

• Brainstoming• Diagrama de afinidades• Workshops ou Grupos de Foco

• Análise de sistemas competidores• Feedback do usuário

• Diagramas de Casos de Uso• Protótipos de sistemas ou de telas (em papel ou digital)• Storyboards

• Alocação de Funções• Divisão entre as tarefas informatizadas e as tarefas

manuais• Re-Uso de Requisitos• Representação (Role Playing)• Análise de Contexto Futuro

• O que será afetado ??

Documentação e ModelagemDocumentação e Modelagem

• Documentação - Visão estrututurada dos requisitos elicitados. • Documentos comuns:

• Visão e Escopo• Especificação Funcional• Requisitos Suplementares

• A especificação pode englobar o uso de técnicas de modelagem de requisitos• Ex: Casos de Uso UML

Análise e NegociaçãoAnálise e Negociação

• Análise dos Requisitos: • Classificação, detecção de

incompletudes, e estabelecimento de prioridades.

• Os requisitos são verificáveis?• Os requisitos podem ser implementados

com o orçamento e tecnologias disponíveis?

• Ocorre em paralelo com a negociação, pois comumente existem divergências entre os stakeholders com relação a • conjunto final de requisitos a ser

implementado, • prioridade estabelecida para o

desenvolvimento dos mesmos

ValidaçãoValidação

• Última atividade para certificar-se que o documento final de requisitos satisfaz em todos os aspectos o que o usuário deseja do sistema.• Verificação da Corretude

• Técnicas:• Revisão nos Requisitos• Prototipação• Validação de Modelos

Gerência de RequisitosGerência de Requisitos

• Motivação: Gestão de Mudanças• Sistemas de software estão sempre evoluindo

a medida que o ambiente onde ele está inserido muda, ou novas necessidades surgem por parte dos usuários.

• Fazem parte da Gerência de Requisitos• Identificação de requisitos• Processo de gestão da mudança

• Uso de Gerência de Configuração• Políticas de rastreabilidade

• Relacionamentos entre os requisitos e os artefatos criados a partir dele.

• Apoio de ferramentas CASE• O apoio de ferramentas necessário para ajudar a

gerenciar as mudanças nos requisitos

Desafios da Engenharia Desafios da Engenharia de Requisitosde Requisitos

Desafios da Eng. RequisitosDesafios da Eng. RequisitosLamsweerde (2000): “Requirement Engineering in the Year 00: A Research Perspective”. Lamsweerde (2000): “Requirement Engineering in the Year 00: A Research Perspective”.

ICSE’2000.ICSE’2000.

• O escopo é muito amplo, podendo englobar desde análise organizacionais ou sociais ‘a análises específicas sobre determinada funcionalidade• Pode envolver desde descrições de alto nível

(informais) ‘a especificações precisas sobre a operacionalização do sistema.

• O sistema resultante não é só um software, mas compreende o ambiente ao seu redor composto de pessoas, computadores e software. • O sistema de informação deve ser analisado de

vários ângulos: organizacional, social, econômico, físico, técnico, etc.



• Existem muitos aspectos não funcionais a serem abordados: confiabilidade, eficiência, usabilidade,etc. • Tais aspectos não funcionais são

geralmente conflitantes.

• Existem muitas pessoas envolvidas, cada uma com uma visão diferente sobre o software• clientes, usuários, analistas de negócio,

engenheiros de requisitos, desenvolvedores, etc.

• As especificações podem sofrer uma grande variedade de deficiências• inadequações às necessidades dos

usuários, incompletude, contradições, ambigüidades, etc.

• Envolve diferentes atividades co-relacionadas • análise de contexto, elicitação,

negociação, validação, especificação e gerenciamento de mudanças.



Dúvidas?

Documents

Engenharia de Requisitos Adélia Barros [email protected]