4/14/11

Processos de engenharia de requisitos

Processos de Engenharia de Requisitos

Os requisitos e as formas de obt-los e documentlos variam drasticamente de um projeto para o outro

Contudo, existe uma srie de atividades genricas comuns a todos os processos

Elicitao de requisitos; Anlise de requisitos; Validao de requisitos; Gerenciamento de requisitos.

2007 by Pearson Education

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 1

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 2

Engenharia de requisitos

Elicitao e anlise
Envolve pessoal tcnico trabalhando com os clientes para descobrir sobre o domnio da aplicao, os servios que o sistema deve fornecer e sobre as restries operacionais. Pode envolver

Usurios finais Gerentes Engenheiros envolvidos na manuteno especialistas de domnio representantes de sindicato, etc.

Estes so chamandos stakeholders (partes interessadas)

2007 by Pearson Education

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 3

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 4

Problemas de anlise de requisitos

A espiral de requisitos

Stakeholders no sabem o que eles realmente querem.

Stakeholders expressam requisitos em seus prprios termos.

Diferentes stakeholders podem ter requisitos conflitantes.

Fatores organizacionais e polticos podem influenciar os requisitos de sistema.

Mudanas de requisitos durante o processo de anlise

2007 by Pearson Education

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 5

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 6

4/14/11

Atividades de processo

Identificao de requisitos
Processo de reunir informaes sobre os sistemas propostos e existentes

Identificao (ou Elicitao) de requisitos

Interao com os stakeholders para coletar seus requisitos. Os requisitos de domnio so tambm descobertos neste estgio. Agrupa requisitos relacionados e organiza-os em conjuntos coerentes. Priorizao de requisitos e resoluo de conflitos de requisitos. Os requisitos so documentados e colocados na prxima volta da espiral.

Anlise e Negociao de requisitos

Obter requisitos de usurio e de sistema a partir dessas informaes.

As fontes de informao incluem documentao, stakeholders e as especificaes de sistemas similares.

Documentao de requisitos

Prottipos tambm podem ser usados tanto para descobrir quanto para validar requisitos

2007 by Pearson Education

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 7

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 8

Stakeholders de caixa eletrnico

Pontos de vista
Maneira de estruturar os requisitos para representar as perspectivas de stakeholders diferentes.

Clientes do banco Representantes de outros bancos Gerentes de bancos Caixas do banco Administradores de banco de dados Gerentes de proteo (segurana das informaes)

Stakeholders podem ser classificados em diferentes pontos de vista.

Departamento de marketing Engenheiros de manuteno de hardware e de software

Essa anlise de mltiplas perspectivas importante, pois no h uma maneira nica de analisar os requisitos

Reguladores de banco
2007 by Pearson Education 2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 9

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 10

Tipos de pontos de vista

Pontos de vista de interao so pessoas ou sistemas que interagem diretamente com o sistema.

Identificao de pontos de vista

Identificar pontos de vista usando:

Clientes e o banco de dados de contas so pontos de vista de interao.

Fornecedores e receptores de servios do sistema; Sistemas que devem interfacear diretamente com o sistema que est sendo especificado; Regulamentos e padres; Fontes de requisitos de negcio e de requisitos no funcionais; Engenheiros que tm de desenvolver e manter o sistema; Marketing e outros pontos de vista de negcio.
2007 by Pearson Education

Pontos de vista indiretos so os stakeholders que no usam o sistema diretamente, mas afetam os requisitos.

Gerncia, caixas do banco e pessoal de proteo so pontos de vista indiretos.

Pontos de vista de domnio so as caractersticas e restries de domnio que influenciam os requisitos.

Padres para comunicaes entre bancos representam pontos de vista de domnio

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 11

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 12

4/14/11

Hierarquia de pontos de vista do LIBSYS

Entrevistas
Em entrevista formal ou informal, a equipe de RE formula questes para os stakeholders sobre os sistemas que eles usam e o sistema a ser desenvolvido.

Existem dois tipos de entrevistas Entrevistas fechadas, onde um conjunto de questes predefinidas so respondidas.

Entrevistas abertas, onde no h um roteiro predefinido e onde uma variedade de assuntos so explorados com os stakeholders.
2007 by Pearson Education

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 13

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 14

Entrevistas na prtica
Normalmente, uma mistura de entrevistas fechadas e abertas

Cenrios
Cenrios so simulaes de como um sistema poder ser usado

Entrevistas so boas para obteno de um entendimento geral do que os stakeholders fazem e como eles podem interagir com o sistema.

Eles devem incluir

Uma descrio da situao inicial; Uma descrio do fluxo normal de eventos; Uma descrio do que pode dar errado; Informao sobre outras atividades concorrentes; Uma descrio do estado quando o cenrio termina.

Entrevistas no so ideais para a compreenso de requisitos de domnio

Os engenheiros de requisitos podem no entender a terminologia especfica de domnio; Alguns conhecimentos de domnio so to especificos que as pessoas acham difcil explicar ou pensam que no vale a pena mencion-los
2007 by Pearson Education

Para sistemas interativos, cenrios funcionam bem em combinao com prottipos da GUI

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 15

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 16

Cenrio do LIBSYS

Casos de uso
Os casos de uso constituem uma tcnica baseada em cenrios que identificam os agentes em uma interao e descrevem a interao em si.

Apoiados pela UML Diagramas de casos de uso so usados para definir o escopo Especificaes de casos de uso so cenrios como o descrito anteriormente

Um conjunto de casos de uso deve descrever todas as possveis interaes com o sistema.

2007 by Pearson Education

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 17

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 18

4/14/11

Alguns casos de uso do LIBSYS

Fatores sociais e organizacionais

Sistemas de software so usados em um contexto social e organizacional. Isso pode influenciar, ou mesmo dominar os requisitos de sistema. Fatores sociais e organizacionais no so um ponto de vista nico, mas so influncias sobre todos os pontos de vista. muito difcil saber se uma anlise de fatores sociais e organizacionais est correta!

2007 by Pearson Education

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 19

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 20

Etnografia
Um analista despende um tempo considervel observando e analisando como as pessoas realmente trabalham.

Escopo da etnografia
So requisitos originados a partir do modo como as pessoas realmente trabalham

As pessoas no tm de explicar seu trabalho.

Fatores sociais e organizacionais de importncia podem ser observados.

Estudos de etnografia tm mostrado que o trabalho , geralmente, mais rico e mais complexo do que o sugerido pelos modelos simples de sistema.

Independem de como definies de processo sugerem que elas devam trabalhar. So requisitos originados a partir da cooperao e da conscientizao das atividades de outras pessoas.

2007 by Pearson Education

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 21

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 22

Mais Etnografia
Etnografia funciona bem quando combinada com prototipao

Validao de requisitos
Dedica-se a mostrar que os requisitos definem o sistema que o cliente realmente deseja.

O estudo etnogrfico fornece feedback rpido sobre a aceitao e possveis melhorias para um prottipo

O desenvolvimento de prottipo resulta em questes no respondidas que tornam a anlise etnogrfica mais focada

Custos de erros de requisitos so altos e, desse modo, a validao muito importante

O problema com a etnografia que ela estuda prticas existentes que podem ter alguma base histrica que no mais relevante.

O custo da reparao de um erro de requisitos depois da entrega pode equivaler a muitas vezes o custo de reparao de um erro de implementao

No to eficiente para descobrir requisitos novos

2007 by Pearson Education 2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 23

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 24

4/14/11

Verificao de requisitos
Verificao de validade. O sistema fornece as funes que melhor apiam as necessidades do cliente? Verificao de consistncia. Existe algum tipo de conflito de requisitos? Para um mesmo requisito no pode haver contradio Verificao de completude. Todas as funes requisitadas pelo cliente foram includas? Verificao de exequibilidade. Os requisitos podem ser implementados com o oramento e a tecnologia disponveis? Facilidade de verificao. Os requisitos podem ser verificados? Usar conjunto de testes para demonstrar que a funcionalidade entregue atende o requisito

2007 by Pearson Education

Tcnicas de validao de requisitos

Revises de requisitos

Anlise manual sistemtica dos requisitos. Potencialmente acompanhada por stakeholders Uso de um modelo executvel do sistema para verificar requisitos Desenvolvimento de testes para requisitos a fim de verificar a testabilidade Testes de aceitao
2007 by Pearson Education

Prototipao

Gerao de casos de teste.

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 25

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 26

Revises de requisitos
Revises regulares devem ser feitas enquanto a definio de requisitos est sendo formulada. Ambos, cliente e fornecedor, devem ser envolvidos nas revises.

Reviso de requisitos
Facilidade de verificao. O requisito realisticamente testvel? Facilidade de compreenso. O requisito adequademente compreendido? Rastreabilidade. A origem do requisito claramente estabelecida? Adaptabilidade. O requisito pode ser mudado sem um grande impacto em outros requisitos

Revises podem ser formais (com documentos completos) ou informais. Uma boa comunicao entre desenvolvedores, clientes e usurios podem resolver problemas nos estgios iniciais.

2007 by Pearson Education

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 27

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 28

Gerenciamento de requisitos
Gerenciamento de requisitos um processo para compreender e controlar as mudanas de requisitos

Mudanas de requisitos
Diferentes stakeholders atribuem diferentes prioridades para os mesmos requisitos Os clientes do sistema podem especificar os requisitos a partir de uma perspectiva de negcio que conflita com os requisitos do usurio final.

Requisitos so, inevitavelmente, incompletos e inconsistentes

Novos requisitos surgem durante o processo inteiro Os diferentes pontos de vista tm requisitos diferentes e estes so freqentemente contraditrios.

Os ambientes tcnico e de negcio do sistema mudam durante seu desenvolvimento

E frequentemente tm requisitos diferentes

2007 by Pearson Education

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 29

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 30

4/14/11

Requisitos permanentes e volteis

Classificao de requisitos volteis

Requisitos permanentes. So requisitos estveis, derivados da atividade central da organizao do cliente. Por exemplo, um hospital ter sempre mdicos, enfermeiros, etc. Podem ser derivados dos modelos de domnio. Requisitos volteis. So requisitos que mudam durante o desenvolvimento, ou quando o sistema estiver em operao. Um exemplo seria, em um hospital, os requisitos derivados da poltica de sade.

2007 by Pearson Education

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 31

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 32

Rastreabilidade
A rastreabilidade tem a ver com relacionamentos entre os requisitos, suas fontes e o projeto do sistema

Gerenciamento de mudanas de requisitos

Deve ser aplicado a todas as mudanas propostas aos requisitos

necessrio manter essa informao registrada nos locais apropriados Ligam requisitos aos stakeholders que os propuseram ou aos elementos externos que o criaram; a ligao dos requisitos dependentes; Ligaes entre os requisitos e os mdulos de projeto.
2007 by Pearson Education

Especialmente importante para sistemas j prontos ou em estgios avanados de desenvolvimento Anlise de problema: discutir problemas e mudanas de requisitos; Anlise de mudana e estimativa de custo: avaliar os efeitos das mudanas sobre outros requisitos; Implementao de mudana: Modificar vrios artefatos para refletir as mudanas.

Estgios principais

Rastreabilidade da fonte

Rastreabilidade de requisitos

Rastreabilidade de projeto

O impacto da mudana tem que ser avaliado para TODO O SISTEMA!

2007 by Pearson Education

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 33

Ian Sommerville 2006

Engenharia de Software, 8. edio. Captulo 7

Slide 34