Você está na página 1de 35

Processo

de Engenharia de Requisitos
Centro de Inform-ca - Universidade Federal de Pernambuco Sistemas de Informao Vinicius Cardoso Garcia vcg@cin.ufpe.br Slides originais elaborados por Ian Sommerville
O autor permite o uso e a modicao dos slides para ns did-cos

Processos de Engenharia de Requisitos


Os requisitos e as formas de obt-los e document-los variam dras5camente de um projeto para o outro Contudo, existe uma srie de a-vidades genricas comuns a todos os processos
Elicitao de requisitos; Anlise de requisitos; Validao de requisitos; Gerenciamento de requisitos.
[if977] Engenharia de SoTware - SI - CIn - UFPE 2

Engenharia de requisitos

Ian Sommerville, Engenharia de SoTware, 8. edio. Captulo 7 [if977] Engenharia de SoTware - SI - CIn - UFPE 3

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 nais Gerentes Engenheiros envolvidos na manuteno Especialistas de domnio Representantes de sindicato, etc.

Estes so chamandos stakeholders (partes interessadas)


[if977] Engenharia de SoTware - SI - CIn - UFPE 4

Problemas de anlise de requisitos


Stakeholders no sabem o que eles realmente querem. Stakeholders expressam requisitos em seus prprios termos. Diferentes stakeholders podem ter requisitos conitantes. Fatores organizacionais e pol5cos podem inuenciar os requisitos de sistema. Mudanas de requisitos durante o processo de anlise
[if977] Engenharia de SoTware - SI - CIn - UFPE 5

A espiral de requisitos

Ian Sommerville, Engenharia de SoTware, 8. edio. Captulo 7 [if977] Engenharia de SoTware - SI - CIn - UFPE 6

A5vidades de processo
Iden-cao (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 conitos de requisitos. Os requisitos so documentados e colocados na prxima volta da espiral.
[if977] Engenharia de SoTware - SI - CIn - UFPE 7

Anlise e Negociao de requisitos

Documentao de requisitos

Iden5cao de requisitos
Processo de reunir informaes sobre os sistemas propostos e existentes
Obter requisitos de usurio e de sistema a par-r dessas informaes.

As fontes de informao incluem documentao, stakeholders e as especicaes de sistemas similares. Prot-pos tambm podem ser usados tanto para descobrir quanto para validar requisitos
[if977] Engenharia de SoTware - SI - CIn - UFPE 8

Stakeholders de caixa eletrnico


Clientes do banco Representantes de outros bancos Gerentes de bancos Caixas do banco Administradores de banco de dados Gerentes de proteo (segurana das informaes) Departamento de marke-ng Engenheiros de manuteno de hardware e de soTware Reguladores de banco
[if977] Engenharia de SoTware - SI - CIn - UFPE 9

Pontos de vista
Maneira de estruturar os requisitos para representar as perspec5vas de stakeholders diferentes.
Stakeholders podem ser classicados em diferentes pontos de vista.

Essa anlise de ml-plas perspec-vas importante, pois no h uma maneira nica de analisar os requisitos

[if977] Engenharia de SoTware - SI - CIn - UFPE

10

Tipos de pontos de vista


Pontos de vista de interao so pessoas ou sistemas que interagem diretamente com o sistema.
Clientes e o banco de dados de contas so pontos de vista de interao.

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 caracters-cas e restries de domnio que inuenciam os requisitos.


Padres para comunicaes entre bancos representam pontos de vista de domnio
[if977] Engenharia de SoTware - SI - CIn - UFPE 11

Iden5cao de pontos de vista


Iden5car pontos de vista usando:
Fornecedores e receptores de servios do sistema; Sistemas que devem interfacear diretamente com o sistema que est sendo especicado; Regulamentos e padres; Fontes de requisitos de negcio e de requisitos no funcionais; Engenheiros que tm de desenvolver e manter o sistema; Marke/ng e outros pontos de vista de negcio.
[if977] Engenharia de SoTware - SI - CIn - UFPE 12

Hierarquia de pontos de vista do LIBSYS

Ian Sommerville, Engenharia de SoTware, 8. edio. Captulo 7 [if977] Engenharia de SoTware - SI - CIn - UFPE 13

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 -pos de entrevistas
Entrevistas fechadas, onde um conjunto de questes predenidas so respondidas. Entrevistas abertas, onde no h um roteiro predenido e onde uma variedade de assuntos so explorados com os stakeholders.
[if977] Engenharia de SoTware - SI - CIn - UFPE 14

Entrevistas na prtica
Normalmente, uma mistura de entrevistas fechadas e abertas Entrevistas so boas para obteno de um entendimento geral do que os stakeholders fazem e como eles podem interagir com o sistema. Entrevistas no so ideais para a compreenso de requisitos de domnio
Os engenheiros de requisitos podem no entender a terminologia especca de domnio; Alguns conhecimentos de domnio so to especicos que as pessoas acham dilcil explicar ou pensam que no vale a pena mencion-los
[if977] Engenharia de SoTware - SI - CIn - UFPE

15

Cenrios
Cenrios so simulaes de como um sistema poder ser usado Eles devem incluir
Uma descrio da situao inicial; Uma descrio do uxo normal de eventos; Uma descrio do que pode dar errado; Informao sobre outras a-vidades concorrentes; Uma descrio do estado quando o cenrio termina. Para sistemas intera-vos, cenrios funcionam bem em combinao com prot5pos da GUI
[if977] Engenharia de SoTware - SI - CIn - UFPE 16

Ian Sommerville, Engenharia de SoTware, 8. edio. Captulo 7

[if977] Engenharia de SoTware - SI - CIn - UFPE

17

Casos de uso
Os casos de uso cons-tuem uma tcnica baseada em cenrios que iden-cam os agentes em uma interao e descrevem a interao em si.
Apoiados pela UML Diagramas de casos de uso so usados para denir o escopo Especicaes 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.
[if977] Engenharia de SoTware - SI - CIn - UFPE 18

Alguns casos de uso do LIBSYS

Ian Sommerville, Engenharia de SoTware, 8. edio. Captulo 7 [if977] Engenharia de SoTware - SI - CIn - UFPE 19

Fatores sociais e organizacionais


Sistemas de soTware so usados em um contexto social e organizacional. Isso pode inuenciar, ou mesmo dominar os requisitos de sistema. Fatores sociais e organizacionais no so um ponto de vista nico, mas so inuncias sobre todos os pontos de vista. muito diScil saber se uma anlise de fatores sociais e organizacionais est correta!
[if977] Engenharia de SoTware - SI - CIn - UFPE 20

Etnografia
Um analista despende um tempo considervel observando e analisando como as pessoas realmente trabalham. As pessoas no tm de explicar seu trabalho. Fatores sociais e organizacionais de importncia podem ser observados. Estudos de etnograa tm mostrado que o trabalho , geralmente, mais rico e mais complexo do que o sugerido pelos modelos simples de sistema.
[if977] Engenharia de SoTware - SI - CIn - UFPE 21

Escopo da etnografia
So requisitos originados a par-r do modo como as pessoas realmente trabalham
Independem de como denies de processo sugerem que elas devam trabalhar.

So requisitos originados a par-r da cooperao e da conscien5zao das a-vidades de outras pessoas.

[if977] Engenharia de SoTware - SI - CIn - UFPE

22

Mais Etnografia
Etnograa funciona bem quando combinada com proto-pao
O estudo etnogrco fornece feedback rpido sobre a aceitao e possveis melhorias para um prot-po

O desenvolvimento de prot-po resulta em questes no respondidas que tornam a anlise etnogrca mais focada O problema com a etnograa que ela estuda pr5cas existentes que podem ter alguma base histrica que no mais relevante.
No to eciente para descobrir requisitos novos
[if977] Engenharia de SoTware - SI - CIn - UFPE 23

Validao de requisitos
Dedica-se a mostrar que os requisitos denem o sistema que o cliente realmente deseja. Custos de erros de requisitos so altos e, desse modo, a validao muito importante
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

[if977] Engenharia de SoTware - SI - CIn - UFPE

24

Verificao de requisitos
Vericao de validade. O sistema fornece as funes que melhor apiam as necessidades do cliente? Vericao de consistncia. Existe algum -po de conito de requisitos? Para um mesmo requisito no pode haver contradio Vericao de completude. Todas as funes requisitadas pelo cliente foram includas? Vericao de exequibilidade. Os requisitos podem ser implementados com o oramento e a tecnologia disponveis? Facilidade de vericao. Os requisitos podem ser vericados? Usar conjunto de testes para demonstrar que a funcionalidade entregue atende o requisito
[if977] Engenharia de SoTware - SI - CIn - UFPE 25

Tcnicas de validao de requisitos


Revises de requisitos
Anlise manual sistem-ca dos requisitos. Potencialmente acompanhada por stakeholders

Proto-pao
Uso de um modelo executvel do sistema para vericar requisitos

Gerao de casos de teste.


Desenvolvimento de testes para requisitos a m de vericar a testabilidade Testes de aceitao
[if977] Engenharia de SoTware - SI - CIn - UFPE 26

Revises de requisitos
Revises regulares devem ser feitas enquanto a denio de requisitos est sendo formulada. Ambos, cliente e fornecedor, devem ser envolvidos nas revises. Revises podem ser formais (com documentos completos) ou informais. Uma boa comunicao entre desenvolvedores, clientes e usurios podem resolver problemas nos estgios iniciais.
[if977] Engenharia de SoTware - SI - CIn - UFPE 27

Reviso de requisitos
Facilidade de vericao. O requisito realis-camente 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
[if977] Engenharia de SoTware - SI - CIn - UFPE 28

Gerenciamento de requisitos
Gerenciamento de requisitos um processo para compreender e controlar as mudanas de requisitos 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.
[if977] Engenharia de SoTware - SI - CIn - UFPE 29

Mudanas de requisitos
Diferentes stakeholders atribuem diferentes prioridades para os mesmos requisitos Os clientes do sistema podem especicar os requisitos a par-r de uma perspec-va de negcio que conita com os requisitos do usurio nal. Os ambientes tcnico e de negcio do sistema mudam durante seu desenvolvimento
E frequentemente tm requisitos diferentes
[if977] Engenharia de SoTware - SI - CIn - UFPE 30

Requisitos permanentes e volteis


Requisitos permanentes. So requisitos estveis, derivados da a-vidade 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 es-ver em operao. Um exemplo seria, em um hospital, os requisitos derivados da pol-ca de sade.
[if977] Engenharia de SoTware - SI - CIn - UFPE 31

Classificao de requisitos volteis

Ian Sommerville, Engenharia de SoTware, 8. edio. Captulo 7 [if977] Engenharia de SoTware - SI - CIn - UFPE 32

Rastreabilidade
A rastreabilidade tem a ver com relacionamentos entre os requisitos, suas fontes e o projeto do sistema Rastreabilidade da fonte
necessrio manter essa informao registrada nos locais apropriados

Rastreabilidade de requisitos Rastreabilidade de projeto

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.
[if977] Engenharia de SoTware - SI - CIn - UFPE 33

Gerenciamento de mudanas de requisitos


Deve ser aplicado a todas as mudanas propostas aos requisitos Especialmente importante para sistemas j prontos ou em estgios avanados de desenvolvimento Estgios principais
Anlise de problema: discu-r problemas e mudanas de requisitos; Anlise de mudana e es5ma5va de custo: avaliar os efeitos das mudanas sobre outros requisitos; Implementao de mudana: Modicar vrios artefatos para ree-r as mudanas.

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


[if977] Engenharia de SoTware - SI - CIn - UFPE

34

Leituras recomendadas
SOMMERVILLE, I. Engenharia de SoTware. 9. Ed. So Paulo: Pearson Educa-on, 2011
Captulo 7

[if977] Engenharia de SoTware - SI - CIn - UFPE

35

Você também pode gostar