Engenharia de Requisitos

Apresentação em tema: "Engenharia de Requisitos"— Transcrição da apresentação:

1 Engenharia de Requisitos
Adélia Barros

2 Objetivos – Apresentar...
Importância Conceitos Básicos Critérios de Qualidade Processo de Requisitos Desafios da Engenharia de Requisitos

3 Importância da Engenharia de Requisitos

4 Importância da Engenharia 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.

5 Importância da Engenharia de Requisitos
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%).

6 Importância da Engenharia de Requisitos
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.

7 Principais Problemas com 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.

8 Conceitos Básicos da Engenharia de Requisitos

9 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.

10 Engenharia de Requisitos
Contexto Domínio do problema Necessidades dos usuários rastreabilidade Características dos sistema Domínio da solução Requisitos do sistema

11 Fatores Sociais Nuseibeh e Easterbrook (2000): “Requirement Engineering: A Roadmap”, 22nd International Conference on 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”.

12 Engenharia de Requisitos
Concepção de nova tecnologia Fatores sociais Contexto Presente Fatores técnicos Re-engenharia organizacional Contexto Futuro

13 Engenharia de Requisitos Objetivos 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 ?

14 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

15 Paradigma do “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.

16 Características de um Requisito
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!

17 Classificaçã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

18 Critérios de Qualidade

19 Crité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.

20 Critérios de Qualidade
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.

21 Critérios de Qualidade
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.

22 Critérios de Qualidade
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.

23 Critérios de Qualidade
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.

24 Critérios de Aceitação dos Requisitos - CMM-I
Completude, Não Ambiguidade, Corretude Consistência, Descrição Clara, Identificação Única, Rastreabilidade, Passível de Implementação, Testável.

25 Processo de Engenharia de Requisitos

26 Processo Padrão de Engenharia de Requisitos
Gerência de Requisitos

27 Análise de Contexto (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 social e organizacional ambiente técnico ambiente físico

28 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.

29 Fatores 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. Maguire (2001):“Context of Use within Usability Activities”, International Journal of Human-Computer Studies.

30 Fatores do Contexto de Uso
Ambiente Físico ambiente auditivo, térmico, visual e espacial. ergonomia, mobília, postura do usuário, vestimentas, luminosidade, etc. Maguire (2001):“Context of Use within Usability Activities”, International Journal of Human-Computer Studies.

31 Fatores do Contexto de Uso
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. Maguire (2001):“Context of Use within Usability Activities”, International Journal of Human-Computer Studies.

32 Fatores do Contexto de Uso
Ambiente Técnico hardware, software, rede, materiais de referência e outros equipamentos. Maguire (2001):“Context of Use within Usability Activities”, International Journal of Human-Computer Studies.

33 Análise de Contexto Té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 s, gravação de conversações, etc. Testes de usabilidade de sistemas existentes Manutenção de um diário

34 Elicitação de Requisitos Concepção
Especificação do Contexto Análise do contexto futuro Entrevistas e técnicas de grupo Problemas Análise de Sistemas Competidores Feedback do usuário

35 Técnicas de Elicitação de 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 ??

36 Documentaçã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

37 Aná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

38 Validaçã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

39 Gerê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

40 Desafios da Engenharia de Requisitos

41 Desafios da Eng. Requisitos Lamsweerde (2000): “Requirement Engineering in the Year 00: A Research Perspective”. 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.

42 Desafios da Eng. Requisitos Lamsweerde (2000): “Requirement Engineering in the Year 00: A Research Perspective”. ICSE’2000. 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.

43 As especificações podem sofrer uma grande variedade de deficiências
Desafios da Eng. Requisitos Lamsweerde (2000): “Requirement Engineering in the Year 00: A Research Perspective”. ICSE’2000. 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.

44 Dúvidas?