engenharia requisitos

Engenharia de Requisitos

Professor: Msc. Alexandre Rafael Lenz

1. Apresentao do Professor 2. Apresentao da Disciplina

Ementa Objetivo Bibliografia

3. Introduo Engenharia de Requisitos Requisitos Tipos de Requisitos Nveis de Requisitos

2

Agenda

4. Processo de Engenharia de Requisitos Viso Geral do Processo de Engenharia de Requisitos Levantamento de Requisitos

Tcnicas de Levantamento de Requisitos Qualidade dos Requisitos Atributos dos Requisitos Organizao dos Requisitos

Anlise de Requisitos UML Modelo Entidades e Relacionamentos

Documentao de Requisitos O Documento de Definio de Requisitos O Documento de Especificao de Requisitos

Verificao e Validao de Requisitos Gerncia de Requisitos

Mudanas de Requisitos Matriz de Rastreabilidade

Engenharia de Requisitos e Normas e Modelos de Qualidade de Processos de Software CMMI MPS.BR

1. Apresentao do Professor

4

- DOUTORANDO EM CINCIA DA COMPUTAO Universidade Federal da Bahia, UFBA, Salvador, Brasil Ttulo: Uma Abordagem para Gerao de Contedos Complementares num Cenrio de Convergncia Digital Orientador: Celso Alberto Saibel Santos - MESTRADO EM INFORMTICA. Universidade Federal do Paran, UFPR, Brasil. Ttulo: Utilizando tcnicas de aprendizado de mquina para apoio ao teste de regresso, Ano de Obteno: 2009. Orientadora: Slvia Regina Vergilio.

- GRADUAO - BACHARELADO EM CINCIA DA COMPUTAO. Universidade Luterana do Brasil, ULBRA. Ttulo: Processo de Teste de Software Customizvel baseado em Modelos e Normas de Qualidade. Ano de Obteno: 2007. Orientador: Luis Fernando Fortes Garcia.

Apresentao do Professor

5


- PROFESSOR 4 ANOS DE EXPERINCIA - REA 1 - UNIJORGE - UNIME - UNEB Funcionrio Pblico, D.E., Concursado desde

2012 - Engenharia de Software - Gerncia de Projetos - Sistemas de Informao - Sistemas Multimdia - Interface Humano-Computador - Algoritmos

6


Mais de 7 anos de experincia profissional na rea de T.I.,

Atuando em multinacionais como HP, LG, Nokia, Siemens e

Bunge.

Palestrante nos Simpsios da Sociedade Brasileira de

Engenharia de Televiso (SET) em Belo Horizonte, Braslia,

Recife e Manaus.

Gerente de Projetos no Centro Internacional de Tecnologia

de Software, gerenciando os Laboratrios de Teste de Tv

Digital da LG Electronics em Porto Alegre, Curitiba, So Paulo,

Belo Horizonte, Salvador e Fortaleza.

7


Nome em citaes bibliogrficas: LENZ, A. R.;

Lenz, A. R.

reas de atuao: Engenharia de Software, Teste

de Software, Televiso Digital e Convergncia

Digital.

2. Apresentao da Disciplina

9

Apresentao da Disciplina

Engenharia de Requisitos: A engenharia de requisitos estabelece uma base slida para o projeto e para a construo. Sem ela, o software resultante tem grande probabilidade de no atender s necessidades do cliente.

10


EMENTA Introduo Engenharia de Requisitos Tipos de requisitos. O processo da Engenharia de Requisitos. Tcnicas de Levantamento de Requisitos. Anlise de Requisitos e Modelagem Conceitual. Mtodos e tcnicas para a modelagem de sistemas. Documentao de requisitos. Verificao e validao de requisitos. Gerncia de requisitos. Engenharia de Requisitos e Normas e Modelos de

Qualidade

11


BIBLIOGRAFIA BSICA Ian Sommerville. Engenharia de Software, 9 Edio. Pearson Education, 2011. Roger S. Pressman. Engenharia de Software - Uma Abordagem Profissional, 7 Edio, Bookman, 2011. BIBLIOGRAFIA COMPLEMENTAR Falbo, R.A., Engenharia de Requisitos de Software Notas de Aula, UFES, 2012.

Objetivo Geral: Estudar as caractersticas, abordagens e mtodos aplicveis ao processo de Engenharia de Requisitos, procurando capacitar os alunos a levantar, analisar, modelar conceitualmente, documentar, avaliar e gerenciar requisitos de sistemas de software.

Objetivos Especficos:

Estudar os principais aspectos a serem considerados na definio de requisitos de sistemas de software;

Capacitar o aluno a aplicar tcnicas de levantamento de requisitos e modelagem conceitual 12


3. Introduo

14

Mapa dos requisitos

[PRESSMAN, 2011]

Problema Clssico

15

Soluo: Comunicao

16 Cliente Engenheiro de

Requisitos

Um processo de software envolve diversas atividades que podem ser classificadas quanto ao seu propsito em:

Atividades de Desenvolvimento (ou Tcnicas) so as atividades diretamente relacionadas ao processo de desenvolvimento

do software (levantamento e anlise de requisitos, projeto, implementao)

Atividades de Gerncia envolvem atividades relacionadas ao gerenciamento do projeto de maneira

abrangente (gerncia de projetos, gerncia de configurao, reuso, etc.).

Atividades de Controle da Qualidade so aquelas relacionadas com a avaliao da qualidade do produto ou do

processo (verificao, validao, garantia da qualidade).

Processo de Software: Classificao de Atividades

17


18


19

Atividades de Desenvolvimento:

1 Atividade de Desenvolvimento Levantamento de Requisitos:

quando os requisitos do sistema a ser desenvolvido so preliminarmente capturados e organizados.

em seguida os requisitos devem ser modelados, avaliados e documentados.

Modelagem Conceitual: elaborao de modelos descrevendo o qu o software tem de fazer (e no como faz-lo).


20

Note que muitas solues so possveis para o mesmo conjunto de requisitos

So ligadas uma dada plataforma de implementao

linguagem de programao, mecanismo de persistncia a ser adotado, etc.

Atividade de Projeto

Tem por objetivo definir e especificar uma soluo (como faz-lo) a ser implementada.

Importncia dos Requisitos

21

Requisitos tm um papel central no desenvolvimento de software, uma vez que uma das principais medidas do sucesso de um software o grau no qual ele atende aos objetivos e requisitos para os quais foi construdo.

Requisitos so a base para: Estimativas

Modelagem

Projeto

Implementao

Testes

Manuteno

Esto presentes ao longo de todo o ciclo de vida de um software.

Atividades Relacionadas aos Requisitos

22

Nos estgios iniciais de um projeto, requisitos tm de ser levantados, entendidos e documentados.

Atividades de:

Levantamento de Requisitos

Anlise de Requisitos

Documentao de Requisitos


23

Dada a importncia dos requisitos para o sucesso de um projeto, atividades de controle da qualidade devem ser realizadas para verificar, validar e garantir a qualidade dos requisitos

Atividades de:

Verificao de Requisitos

Validao de Requisitos

Garantia da Qualidade de Requisitos

Os custos sero bem maiores se defeitos em requisitos forem identificados tardiamente


24

Mesmo quando coletados de forma sistemtica, requisitos mudam. fundamental gerenciar a evoluo dos requisitos, bem como manter a rastreabilidade entre os requisitos e os demais artefatos produzidos no projeto.

Atividade de:

Gerncia de Requisitos


25


26

Atividades de Desenvolvimento


Anlise de Requisitos

Documentao de Requisitos

Atividades de Gerncia


Atividades de Controle da Qualidade

Verificao de Requisitos

Validao de Requisitos

Garantia da Qualidade de Requisitos

Definio de Engenharia de Requisitos

27

A Engenharia de Requisitos o processo pelo qual os requisitos de um produto de software so coletados, analisados, documentados e gerenciados ao longo de todo o ciclo de vida do software. (AURUM; WOHLIN, 2005)

Definio de Engenharia de Requisitos

28

Engenharia de Requisitos :

O processo de (em relao aos requisitos):

A Engenharia de Requisitos de Software o ramo da Engenharia de Software que envolve as atividades relacionadas com a definio dos requisitos de software de um sistema, desenvolvidas ao longo do ciclo de vida de

software [Sommerville, 2011]

Coletar Analisar Documentar

Verificar/ Validar

Gerenciar

Definio de Requisito

29

Existem diversas definies para requisito de software na literatura, dentre elas:

Requisitos de um sistema so descries dos servios que devem ser fornecidos por esse sistema e as suas restries operacionais (SOMMERVILLE, 2011).

Um requisito de um sistema uma caracterstica do sistema ou a descrio de algo que o sistema capaz de realizar para atingir seus objetivos (PFLEEGER, 2004).

Um requisito alguma coisa que o produto tem de fazer ou uma qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON, 2006).

Tipos de Requisitos

30

As vrias definies apresentadas apontam para a existncia de diferentes tipos de requisitos: Requisitos Funcionais

Requisitos No Funcionais

Requisitos de Domnio (Regras de Negcio)

Tipos de Requisitos

31

Requisitos Funcionais (RFs) So declaraes de servios que o sistema deve prover,

descrevendo o que o sistema deve fazer (SOMMERVILLE, 2011).

Um requisito funcional descreve uma interao entre o sistema e o seu ambiente (PFLEEGER, 2004).

Podendo descrever, ainda, como o sistema deve reagir a entradas especficas, como o sistema deve se comportar em situaes especficas e o que o sistema no deve fazer (SOMMERVILLE, 2011).

Tipos de Requisitos

32

Requisitos Funcionais (RFs) Exemplo:

RF1 (Fidelizao do Cliente) Para que o cliente possa efetuar o pedido o mesmo deve estar previamente cadastrado no site. Para a consulta no catlogo no necessrio que o usurio esteja autenticado. Deve-se permitir que o cliente seja bloqueado caso haja alguma situao de inadimplncia no pagamento.

Tipos de Requisitos

33

Requisitos No Funcionais (RNFs) Descrevem restries sobre os servios ou funes

oferecidos pelo sistema (SOMMERVILLE, 2011), as quais limitam as opes para criar uma soluo para o problema (PFLEEGER, 2004).

Neste sentido, os requisitos no funcionais so muito importantes para a fase de projeto (design), servindo como base para a tomada de decises nessa fase.

Tipos de Requisitos

34

Requisitos No Funcionais (RNFs) Os requisitos no funcionais tm origem nas

necessidades dos usurios:

em restries de oramento

em polticas organizacionais

em necessidades de interoperabilidade com outros sistemas de software ou hardware

em fatores externos como regulamentos e legislaes

(SOMMERVILLE, 2011)

Tipos de Requisitos

35

Classificao - RNFs (SOMMERVILLE, 2011): Requisitos de produto: comportamento do produto.

confiabilidade, usabilidade, eficincia, portabilidade, manutenibilidade e segurana.

Requisitos organizacionais: so derivados de metas, polticas e procedimentos das organizaes do cliente e do desenvolvedor. Time-to-market, linguagem, custo, plataforma, etc.

Requisitos externos: referem-se a todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. Interoperabilidade com outros sistemas, privacidade, etc.

Tipos de Requisitos

36

Classificao RNFs ISO 25000:

Tipos de Requisitos

37

Requisitos No Funcionais (RNFs) Exemplo:

RNF1 (Desempenho) O Site deve estar preparado para atender 20 requisies simultneas com respostas de no mximo 1 segundo de atraso.

Tipos de Requisitos

38

Ainda que a classificao em requisitos funcionais e no funcionais seja a mais amplamente aceita, h outras classificaes de requisitos.

Sommerville (2011) considera, alm de requisitos funcionais e no funcionais, requisitos de domnio.

Tipos de Requisitos

39

Requisitos de domnio na concepo de Sommerville so o que outros autores, tal como Wiegers (2003), chamam de Regras de Negcio.

Exemplo: Em um sistema de matrcula de uma universidade, uma regra de negcio diz que:

RN1 (pr-requisito) Um aluno s pode se matricular em uma turma de uma disciplina se ele tiver cumprido seus pr-requisitos.

Tipos de Requisitos

40

Regras de Negcio

1. Fatos ou invariantes: declaraes que so verdade sobre o negcio. Geralmente

descrevem associaes ou relacionamentos entre importantes termos do negcio.

Ex.: Todo pedido tem uma taxa de remessa.

2. Restries: como o prprio nome indica, restringem as aes que o sistema ou

seus usurios podem realizar.

Algumas palavras ou frases sugerem a descrio de uma restrio, tais como deve, no deve, no pode e somente.

Ex.: Um aluno s pode tomar emprestado, concomitantemente, at trs livros.

Tipos de Requisitos

41

Regras de Negcio

3. Ativadores de Aes: so regras que disparam alguma ao sob condies especficas. Uma

declarao na forma Se , ento indicada para descrever ativadores de aes.

Ex.: Se a data para retirada do livro ultrapassada e o livro no retirado, ento a reserva cancelada.

4. Inferncias: so regras que derivam novos fatos a partir de outros fatos ou

clculos. So normalmente escritas no padro se / ento, mas a clusula ento implica um fato ou nova informao e no uma ao a ser tomada.

Ex.: Se o usurio no devolve um livro dentro do prazo estabelecido, ento ele torna-se um usurio inadimplente.

Tipos de Requisitos

42

Regras de Negcio

5. Computaes:

so regras de negcio que definem clculos a serem realizados usando algoritmos ou frmulas matemticas especficos.

Podem ser expressas como frmulas matemticas, descrio textual, tabelas etc. Ex.: Multa = Valor de Locao * Nmero de Dias de Atraso.

Nveis de Descrio de Requisitos

43

Os requisitos devem ser redigidos de modo a serem passveis de entendimento pelos diversos interessados (stakeholders).

Desenvolvedores tm interesse em detalhes tcnicos.

Requisitos de Sistema

Clientes requerem descries mais abstratas.

Requisitos de Usurio


44

Requisitos de Usurio: so declaraes em linguagem natural acompanhadas de diagramas intuitivos de quais servios so esperados do sistema e das restries sob as quais ele deve operar.

Nvel de abstrao mais alto para pessoas que no possuem conhecimento tcnico.

[Sommerville, 2011]


45

Requisitos de Sistema: definem detalhadamente as funes, servios e restries do sistema. So verses expandidas dos requisitos de usurio usados pelos desenvolvedores para projetar, implementar e testar o sistema.

Especificaes em linguagem natural so insuficientes e para especific-los, notaes mais especializadas devem ser utilizadas.

[Sommerville, 2011]


46

Esses nveis de descrio de requisitos so aplicados em momentos diferentes e com propsitos distintos.

Requisitos de usurio so elaborados nos estgios iniciais do desenvolvimento. Usados como base para a contratao e o planejamento do projeto

Requisitos de sistema so elaborados como parte dos esforos diretos para o desenvolvimento do sistema Capturam detalhes importantes para as fases tcnicas

Documentos de Requisitos

Pfleeger (2004) sugere que dois tipos de documentos de requisitos sejam elaborados:

Documento de Definio de Requisitos: deve ser escrito de maneira que o cliente possa entender. Usa uma listagem do qu o cliente espera que o sistema proposto faa. Representa um consenso entre o cliente e o desenvolvedor sobre o qu o cliente quer. Resultado do Levantamento de Requisitos

Documento de Especificao de Requisitos: redefine os requisitos de usurio em termos mais tcnicos, apropriados para o desenvolvimento de software, sendo produzido por analistas de requisitos. Resultado da Anlise de Requisitos 47

2. Processo de

Engenharia de Requisitos

Viso Geral do Processo de Engenharia de Requisitos

A Engenharia de Requisitos pode ser descrita como um processo:

Um conjunto organizado de atividades que deve ser seguido para derivar, avaliar e manter os requisitos e artefatos relacionados.

Deve incluir: A estrutura ou sequncia dessas atividades

Quem responsvel por cada atividade

Suas entradas e sadas

As ferramentas usadas para apoiar as atividades

Os mtodos, tcnicas e diretrizes a serem seguidos na sua realizao. 49


Processos de engenharia de requisitos podem variar muito de uma organizao para outra.

A definio de um processo apropriado organizao traz muitos benefcios.

Deve atender s necessidades da organizao, ou at mesmo de um projeto especfico.

No faz sentido falar em processo ideal ou definir algum e imp-lo a uma organizao.

50


Wiegers (2003) destaca alguns benefcios que um processo de Engenharia de Requisitos de alta qualidade pode trazer: menor quantidade de defeitos nos requisitos,

reduo de retrabalho,

desenvolvimento de menos caractersticas desnecessrias,

diminuio de custos,

desenvolvimento mais rpido,

menos problemas de comunicao,

alteraes de escopo reduzidas,

estimativas mais confiveis,

maior satisfao dos clientes e membros da equipe. 51


52 (KOTONYA; SOMMERVILLE, 1998)

1 2 3 4

5


Vale destacar que no h limites bem definidos entre as atividades do processo apresentado.

Na prtica, elas so intercaladas e existe um alto grau de iterao e feedback entre elas.

O processo executado at que todos os usurios estejam satisfeitos e concordem com os requisitos. 53


Esse processo pode ser aplicado para diferentes ciclos de vida:

Ao se adotar um modelo de ciclo de vida iterativo, essas atividades podem ser realizadas muitas vezes.

54


Atividades do Processo de Engenharia de Requisitos: 1. Levantamento de Requisitos

2. Anlise de Requisitos

3. Documentao de Requisitos

4. Verificao e Validao de Requisitos

5. Gerncia de Requisitos

55

1. Levantamento de Requisitos

Levantamento de Requisitos Nessa fase, um esforo conjunto de clientes, usurios e

especialistas de domnio necessrio

Objetiva entender a organizao, seus processos, necessidades, deficincias dos sistemas de software atuais, possibilidades de melhorias, bem como restries existentes.

No se resume somente a perguntar s pessoas o que elas desejam, mas sim analisar cuidadosamente a organizao, o domnio da aplicao e os processos de negcio no qual o sistema ser utilizado

56


Os requisitos podem ser obtidos de diferentes fontes:

Informaes dos interessados (stakeholders) Usurios, clientes e especialistas de domnio.

Consultar documentos

Sistemas e processos existentes

Obter conhecimentos do domnio

Estudar o negcio da organizao

etc. 57


Dimenses do levantamento de requisitos



1 2

3 4

Dimenses do levantamento de requisitos 1. Entendimento do domnio da aplicao:

entendimento geral da rea na qual o sistema ser aplicado;

2. Entendimento do problema: entendimento dos detalhes do problema especfico a ser

resolvido com o auxlio do sistema a ser desenvolvido;

3. Entendimento do negcio: entender como o sistema ir afetar a organizao e como

contribuir para que os objetivos do negcio e os objetivos gerais da organizao sejam atingidos;

59


Dimenses do levantamento de requisitos 4. Entendimento das necessidades e das restries dos

interessados: Entender as demandas de apoio para a realizao do trabalho de

cada um dos interessados no sistema, entender os processos de trabalho a serem apoiados pelo sistema e o papel de eventuais sistemas existentes na execuo e conduo dos processos de trabalho.

Consideram-se interessados (stakeholders), todas as pessoas que so afetadas pelo sistema de alguma maneira, dentre elas clientes, usurios finais e gerentes de departamentos onde o sistema ser instalado.

60


Stakeholders Todas as pessoas que so afetadas pelo sistema de alguma maneira

Nem sempre o cliente o usurio final

Cliente Quem contrata e paga pelo servio (Administrador de um hospital)

Usurio final Quem usa o software no dia a dia (Mdicos e enfermeiros)

Importante Nunca deixe de levantar requisitos com os usurios finais pois sem a

colaborao deles, o software no ser usado 61


Alguns sistemas sero utilizados por milhares ou milhes de usurios

Escolha usurios fonte dos requisitos que sejam representativos

Lembre-se que a regra de Pareto (80-20) aparenta ser vlida 20% dos requisitos satisfazem a 80% dos usurios

Escolher um usurio muito especialista pode levar a implementao de requisitos que nunca sero utilizados

Requisitos funcionais: Descrevem as funcionalidades do sistema

Requisitos no funcionais: Descrevem a qualidade do sistema 62


Tcnicas de Levantamento de Requisitos Dentre as vrias tcnicas, podem ser citadas (KENDALL;

KENDALL, 2010; KOTONYA; SOMMERVILLE, 1998; AURUM; WOHLIN, 2005):

Entrevistas

Questionrios

Observao

Anlise de Documentos

Anlise de Sistemas Existentes

Cenrios

Prototipao

Dinmicas de Grupo 63


As tcnicas so complementares: til empregar vrias dessas

tcnicas concomitantemente, de modo a se ter um levantamento

de requisitos mais eficaz.

Tcnicas de Levantamento de Requisitos Entrevistas:

Tcnica amplamente utilizada, que consiste em conversas direcionadas com um propsito especfico e com formato pergunta-resposta.

Seu objetivo descobrir problemas a serem tratados, levantar procedimentos importantes e saber a opinio e as expectativas do entrevistado sobre o sistema.

64



Entrevistas fechadas: nas quais o interessado responde a um conjunto de perguntas predefinidas.

Entrevistas abertas: nas quais no existe um roteiro predefinido. O analista explora vrios assuntos com o interessado e, assim, desenvolve uma maior compreenso de suas necessidades.

65


Tcnicas de Levantamento de Requisitos Entrevistas: Planejamento da entrevista [Kendall e Kendall, 2010]:

1. Estudar material existente sobre o domnio e a organizao. linguagem usada , vocabulrio comum, otimizar o tempo despendido nas entrevistas.

2. Estabelecer objetivos. fontes de informao, formatos da informao, frequncia na tomada de deciso, estilo

da tomada de deciso etc.

3. Decidir quem entrevistar. pessoas chave das diversas classes de interessados

4. Preparar o entrevistado. agendamento para que o entrevistado tenha tempo para pensar sobre a entrevista.

5. Preparar a entrevista. tipos de questes e a estrutura da entrevista e o modo como a mesma ser registrada.

66



67


Tcnicas de Levantamento de Requisitos Questionrios:

O uso de questionrios possibilita ao analista obter informaes como postura, crenas, comportamentos e caractersticas de vrias pessoas que sero afetas pelo sistema.

68


Tcnicas de Levantamento de Requisitos Observao:

Consiste em observar o comportamento e o ambiente dos indivduos de vrios nveis organizacionais.

Utilizando-se essa tcnica, possvel capturar o que realmente feito e qual tipo de suporte computacional realmente necessrio.

Ajuda a confirmar ou refutar informaes obtidas com outras tcnicas e ajuda a identificar tarefas que podem ser automatizadas e que no foram identificadas pelos interessados. 69


Tcnicas de Levantamento de Requisitos Anlise de Documentos:

Pela anlise de documentos existentes na organizao, analistas capturam informaes e detalhes difceis de conseguir por entrevista e observao.

Documentos revelam um histrico da organizao e sua direo.

70


Tcnicas de Levantamento de Requisitos Anlise de Software Existente:

Caso j exista um sistema em uso e o projeto trata da sua reconstruo, este pode ser utilizado como fonte para levantamento de requisitos.

A tarefa ser executada atravs da Engenharia Reversa no contexto de uma Reengenharia do software.

71


Tcnicas de Levantamento de Requisitos Cenrios:

Um cenrio de interao entre o usurio final e o sistema montado e o usurio simula sua interao com o sistema nesse cenrio, explicando ao analista o que ele est fazendo e de quais informaes ele precisa para realizar a tarefa descrita no cenrio.

O uso de cenrios ajuda a entender requisitos, a expor o leque de possveis interaes e a revelar facilidades requeridas.

72


Tcnicas de Levantamento de Requisitos Prototipao:

Um prottipo uma verso preliminar do sistema, muitas vezes no operacional e descartvel, que apresentada ao usurio para capturar informaes especficas sobre seus requisitos de informao, observar reaes iniciais e obter sugestes, inovaes e informaes para estabelecer prioridades e redirecionar planos.

73



Prototipao evolucionria Uma abordagem para o desenvolvimento do sistema onde um

prottipo inicial produzido e refinado atravs de vrios estgios at atingir o sistema final.

Prototipao descartvel Um prottipo o qual usualmente uma implementao prtica

do sistema produzida para ajudar a levantar os problemas com os requisitos e depois descartado. O sistema ento desenvolvido usando algum outro processo de desenvolvimento.

74



75



76



77


Tcnicas de Levantamento de Requisitos Dinmicas de Grupo:

H vrias tcnicas que procuram explorar dinmicas de grupo para a descoberta e o desenvolvimento de requisitos: Brainstorming: representantes de diferentes grupos de interessados

engajam-se em uma discusso informal para rapidamente gerarem o maior nmero possvel de ideias.

JAD (Joint Application Development): interessados e analistas se renem para discutir problemas a serem solucionados e solues possveis. Com as diversas partes envolvidas representadas, decises podem ser tomadas e questes podem ser resolvidas mais rapidamente.

JAD so normalmente bem estruturadas (passos, aes e papis). 78


Contextualizao: O contexto consiste em definir algumas caractersticas de cada Requisito Funcional, tais como: para quem til?, quando?, por que?, onde?, como?

79


Essas perguntas so fundamentais para

entendimento dos requisitos, auxiliando uma descrio detalhada e consistente.

Dimenses Contextuais [KNIGHT, 2004]

Contextualizao: Para cada requisito identificado, as seguintes questes devem ser feitas:

01) Por que o requisito deve ser considerado na Soluo? A resposta deve ser analisada e verificada com o problema que est sendo resolvido pela

soluo em questo. A resposta tem que manter o escopo do Problema e da Soluo. Caso a resposta indique que o requisito amplia a soluo do Problema, ento um estudo mais aprofundado deve ser feito em relao ao escopo do Problema e da Soluo.

02) Como o requisito deve ser considerada Soluo? Esta pergunta deve esclarecer, do ponto de vista do usurio, como o requisito deve ser

considerado na soluo. As respostas podem variar bastante e outros requisitos de diversos tipos podem ser identificados.

Alm disso, esse item responde em partes os critrios de aceitao do requisito, uma vez que aponta para a expectativa do cliente em relao funcionalidade. As outras perguntas que completam os critrios de aceitao do requisito so as perguntas Quando? e Onde?, pois nelas tambm so traduzidas as expectativas do cliente.

80


Contextualizao: Para cada requisito identificado, as seguintes questes devem ser feitas:

03) Quando o requisito deve ser processado ou executado na Soluo? A pergunta visa obter Requisitos que definam a frequncia de processamento, a

disponibilidade e alguns outros Requisitos para que a funcionalidade seja executada, depois de implementada na Soluo.

04) Onde o requisito ser implementado? Indica a localizao da funcionalidade (mdulos, ambientes, servidores especficos, etc.).

05) Quem utilizar o requisito? A pergunta definir os usurios autorizados a utilizar a funcionalidade, aps a implantao.

Cada usurio identificado com a pergunta dever ser questionado tambm sobre os seus Requisitos para a implementao da funcionalidade.

81


Aplicando as Tcnicas de Levantamento de Requisitos

Duas importantes questes que precisam ser abordadas em relao s tcnicas de levantamento de requisitos so (AURUM; WOHLIN, 2005): Que tcnica(s) aplicar durante uma atividade de levantamento de

requisitos?

Quais dessas tcnicas so complementares?

Em ltima instncia, cada situao , em alguma extenso, nica e, portanto, as respostas a essas perguntas so dependentes do contexto do projeto (AURUM; WOHLIN, 2005).

De maneira geral, as principais tcnicas discutidas so complementares.

82


Qualidade dos Requisitos: A especificao dos requisitos deve satisfazer a uma srie de critrios para ser considerada uma especificao que possui qualidade, entre eles:

1. Clareza A clareza de um requisito expressa atravs de sua preciso, corretude e capacidade de ser

compreendido por todos os envolvidos no projeto. Para isso todos os conceitos presentes na especificao devem ser representados pelo mesmo termo.

2. Completude Para determinado requisito, todas as necessidades a ele relacionado foram captadas do

cliente e registradas. (Aplicabilidade do roteiro de levantamento de requisitos)

3. Origem O requisito foi coletado de um fornecedor de requisito oficial?

83


Qualidade dos Requisitos: 4. Consistncia

Garantir que no existam conflitos entre os requisitos e entre os artefatos gerados durante o ciclo de vida do projeto.

5. Implementveis Garantir que determinado requisito no conflita com as tecnologias e arquiteturas

determinadas durante o ciclo de vida do projeto.

6. Testveis A verificao e validao do requisito ocorrem atravs de procedimentos de teste,

experimentos e provas ou atravs de acordos de aceitao previamente definidos.

Para garantir esse critrio, deve-se identificar as condies para a homologao do Requisito, ou seja, todas as condies que permitam verificar que esse Requisito foi atendido.

7. Rastreveis O requisito deve permitir a fcil determinao de seus antecedentes e precedentes.

84


Atributos dos Requisitos:

Identificador nico (RF-n, RNF-n, RN-n)

Descrio (Texto descritivo)

Prioridade (Baixa, Mdia, Alta)

Status (Identificado, Aprovado, Cancelado, Em Construo, Em Homologao, Finalizado)

Origem (Nome do usurio, Documento analisado, etc.)

Dependncias

Etc.

85


Organizao dos Requisitos:

Narrativa livre O sistema deve mostrar uma mensagem de status (finalizada, em

andamento, ...) para uma tarefa em intervalos no menores que 60 segundos (dificulta o entendimento - no a forma mais indicada)

Lista de Requisitos Funcionais (RFs) RF-1: Uma mensagem de status deve ser mostrada na rea inferior

da janela (desenho da Fig.1)

RF-2: A mensagem deve ser atualizada a cada 60 segundos, com tolerncia de 10 segundos para mais ou para menos

RF-3: A mensagem deve estar sempre visvel

86



Lista de Requisitos No Funcionais (RNFs) Disponibilidade

RNF - DS-1: O sistema deve ficar disponvel por 99,5% do tempo nos dias teis, das 6h s 22h

Eficincia RNF - EF-1: Em condies de pico de uso, deve ter uma reserva de 25% de

capacidade de processamento e memria

RNF - EF-2: O clculo de interferncia deve ser finalizado com sucesso em menos de 5 minutos

Flexibilidade RNF - FL-1: Um novo tipo de sensor deve poder ser configurado no sistema em

menos de 3 horas

Integridade RNF - IN-1: Transaes histricas dos consumidores s podero ser vistas por

usurios com privilgios de auditor 87



Lista de Requisitos No Funcionais (RNFs)

88



Lista de Requisitos No Funcionais (RNFs)

89



Exemplo de Requisito No Funcional (RNF)

90



Lista de Regras de Negcio (RNs) RN-1: O valor total de um pedido igual soma dos totais dos itens do

pedido acrescido de 10% de taxa de entrega.

RN-2: Um cliente do banco no pode retirar mais de R$ 1.000 por dia de sua conta.

RN-3: Os pedidos para um cliente no especial devem ser pagos antecipadamente.

RN-4: A regra de consistncia de nmeros de CPF calculada como descrito abaixo...

RN-5: sobre instncias (integridade referencial); ex: se X est em projeto, ento X funcionrio;

RN-6: sobre comparaes; ex: salrio tem que ser maior que salrio mnimo;

RN-7: sobre tempo (cronolgico); ex: todo funcionrio deve ter sido candidato antes; 91


Alguns problemas que tornam o levantamento de requisitos uma tarefa difcil: fronteiras so mal definidas

clientes/usurios especificam detalhes tcnicos desnecessrios.

clientes/usurios no sabem muito bem o que querem

clientes/usurios tm pouca compreenso das capacidades e limitaes de um ambiente computacional

clientes/usurios no tm pleno entendimento do domnio do problema

clientes/usurios tm dificuldade de comunicar suas necessidades

clientes/usurios omitem informao que acreditam ser bvia

92


Alguns problemas que tornam o levantamento de requisitos uma tarefa difcil: clientes/usurios especificam requisitos que conflitam com as

necessidades de outros clientes/usurios

clientes/usurios especificam requisitos que so ambguos ou impossveis de testar

Pode ser difcil compreender e coletar informaes quando existem muitos termos desconhecidos

clientes/usurios que entendem o problema a ser resolvido podem ser muito ocupadas

Polticas organizacionais podem influenciar nos requisitos de um sistema.

93


Descreva os requisitos (RFs, RNFs e RNs) de um Gerenciador de Compromissos

Lista de requisitos funcionais

Devidamente contextualizados

Lista de requisitos no funcionais

Lista de regras de negcio

Entregveis

Os requisitos devem estar organizados em um documento de definio de requisitos (a forma de organizao faz parte da avaliao) e contendo os atributos como prioridade, status, origem, etc. 94

Avaliao Parte 1



1 2 3 4

5

Uma vez identificados os requisitos, possvel iniciar a atividade de anlise, quando os requisitos levantados so usados como base para a modelagem do sistema.

Requisitos de usurio so escritos tipicamente em linguagem natural, pois eles devem ser compreendidos por pessoas que no sejam especialistas tcnicos.

Contudo, til expressar requisitos mais detalhados do sistema de maneira mais tcnica. Para tal, diversos tipos de modelos podem ser utilizados (ex.: UML).

96


A atividade de anlise uma atividade de modelagem conceitual, pois ela se preocupa com o domnio do problema e no com solues tcnicas para o mesmo. Duas principais perspectivas so consideradas nesta atividade:

Perspectiva estrutural: Busca modelar os conceitos, propriedades e relaes do domnio

que so relevantes para o sistema em desenvolvimento.

Diagramas de Classes e Modelo de Entidades e Relacionamentos so usados para modelar esta perspectiva.

Perspectiva comportamental: visa modelar o comportamento geral do sistema, de uma de suas

funcionalidades ou de uma entidade especfica ao longo do tempo.

Diagramas de casos de uso, diagramas de atividades, diagramas de estados e diagramas de interao so usados para esta perspectiva. 97


Os modelos criados durante a atividade de anlise de requisitos cumprem os seguintes papis (PFLEEGER, 2004):

prover uma base para o entendimento e concordncia entre clientes e desenvolvedores sobre o que o sistema deve fazer; e

prover uma especificao que guie os desenvolvedores na demais etapas do desenvolvimento, sobretudo no projeto, implementao e testes do sistema.

98


Descries de Casos de Uso

No h um padro definido para especificar casos de uso.

Diferentes autores propem diferentes estruturas, formatos e contedos para descries de casos de uso

Alguns mais indicados para casos de uso essenciais e mais complexos, outros para casos de uso cadastrais e mais simples.

Exemplos detalhados podem ser encontrados na Seo 5.3 [Falbo, 2012].

99



100


Linguagem de Modelagem Unificada (Unified Modeling Language UML)

uma linguagem grfica padro para especificar, visualizar, documentar e construir artefatos de sistemas de software

somente uma linguagem e, portanto, apenas parte de um mtodo de desenvolvimento de software.

Ela independente do processo de software a ser usado, ainda que seja mais adequada a processos de desenvolvimento orientados a objetos. 101


UML

Diagramas de Classes: Um diagrama de classes exibe um conjunto de classes e seus relacionamentos. Proveem uma viso esttica da estrutura de um sistema.

102


103


UML: Diagramas de Classes

UML

Diagramas de Casos de Uso:

Um diagrama de casos de uso mostra um conjunto de casos de uso e atores e seus relacionamentos.

Os casos de uso descrevem a funcionalidade do sistema percebida pelos atores externos.

Um ator interage com o sistema, podendo ser um usurio humano, dispositivo de hardware ou outro sistema.

Diagramas de casos de uso proveem uma viso das funcionalidades do sistema, sendo importantes para a organiz-las e model-las.

104


105


UML: Diagramas de Casos de Uso

UML

Diagramas de Estados:

Mostram os estados pelos quais um objeto pode passar ao longo de sua vida, em resposta a estmulos recebidos, juntamente com suas aes.

Os diagramas de estados proveem uma viso dinmica de um objeto, sendo importantes para modelar o comportamento dos objetos de uma classe em resposta ocorrncia de eventos.

106


107


UML: Diagramas de Estados

UML

Diagramas de Atividades:

Mostram a estrutura de um processo.

Proveem uma viso dinmica do sistema (ou de uma poro do sistema) e podem ser usados tanto para modelar processos de negcio quanto para modelar funes do sistema.

Um diagrama de atividades d nfase ao fluxo de controle entre objetos

108


109


UML: Diagramas de Atividades

UML

Diagramas de Interao: Diagramas de Sequncia:

Mostra um conjunto de objetos ou papis interagindo, incluindo as mensagens que podem ser trocadas entre eles.

So um tipo de diagrama de interao cuja nfase est na ordenao temporal das mensagens.

110


111


UML: Diagramas de Sequncia

Fases de um projeto de BD

Coleta e Anlise de Requisitos

Projeto Conceitual

Projeto Lgico

Projeto Fsico

Mini-mundo

Requisitos de BD

Esquema conceitual

Esquema lgico

Esquema interno 112

Modelo de Entidades e Relacionamentos (MER)

Representao semntica das estruturas de dados mantidas num banco de dados

Foi proposto por Peter Chen em 1976

Possui vrias notaes: - Relacionamentos como objetos do Modelo (Chen)

- Relacionamentos apenas como simples ligaes (Codd, Martin)

113

Entidades

Uma entidade tudo aquilo sobre o qual se deseja manter informaes.

Podendo representar:

objetos concretos: pessoas, livros, carros,

conceitos abstratos: empresas, eventos, embarques,

114

Possui propriedades que a distingue de outras entidades.

um subconjunto de objetos (instncias) que:

desempenha o mesmo papel semntico

possui os mesmos tipos de propriedades (atributos)

115

Entidades

Ex.: Conjunto de todas as contas correntes de um banco

Conjunto de todos os empregados de uma empresa

Conjunto de todos os filmes de um produtor

Representao de entidades no diagrama E-R (entidades e relacionamentos):

Empregado Filme Emprstimo

116

Entidades

Entidades devem ser descritas num Dicionrio de Dados

Entidade: EMPREGADO

Descrio: Pessoa que mantm vnculo

empregatcio com a Empresa atravs de

um contrato de trabalho de acordo com a

legislao trabalhista

117

Entidades

118

Instncia: objeto de uma entidade com suas respectivas propriedades que distinguvel dos outros objetos. Ex.: A entidade Empregado poderia ter a seguinte instncia: Maria dos Anjos, 31 anos, Secretria, Solteira, R$ 800,00

Entidades

So as propriedades que caracterizam ou descrevem uma entidade ou um relacionamento.

Ex.: A entidade CARRO poderia ter os seguintes atributos:

Placa, fabricante, modelo, ano de fabricao, cor, preo

O relaciomento TRABALHA entre EMPREGADO e PROJETO pode ter o atributo: horasTrabalhadas.

119

Atributos

Cada atributo possui um domnio que identifica o conjunto de valores permitidos para aquele atributo.

Ex.: nome: domnio string(20) salrio: domnio numrico

120

Atributos

Entidade: EMPREGADO

Atributo: Data de Admisso

Descrio: data na qual foi assinado o

contrato de trabalho entre a empresa e o

empregado

Domnio: data posterior a 03/01/78 (data de

criao da empresa) e a data de nascimento

do empregado

Atributos devem tambm ser descritos no Dicionrio de Dados:

121

Atributos

Simples: atmico.

Ex. Idade: numrico Nome: cadeia de caracteres

Composto: contm sub-atributos que compem o atributo.

Ex.: Endereo (rua, nmero, bairro, CEP, cidade, etc.)

122

Atributos

Simplesmente valorados: tm um nico valor para uma instncia de uma entidade.

Ex.: PESSOA: Idade

Multivalorados: possuem vrios valores numa instncia de uma entidade.

Ex.: PESSOA:TitulaoSuperior(nenhum, Bel., MSc., PhD)

Atributos derivados: podem ser determinados a partir de outros atributos/entidades.

Ex. Idade e dataAniversrio

123

Atributos

Relacionamentos

So funes que mapeiam um conjunto de instncias de uma entidade em um outro conjunto de instncias de outra entidade (ou da mesma entidade: auto relacionamento).

Em outras palavras, so associaes entre diversas entidades.

Ex.:

Um empregado trabalha num projeto

Um cliente possui conta bancria

Um filme possui vrios atores 124

Empregado

Projeto trabalha

matricula nome salrio horas

1..N

1..N

125

Relacionamentos

Empregado supervisiona 0..N

0..1

126

Relacionamentos

Restries de Integridade

Caracterizam as restries nas quais os relacionamentos entre entidades esto submetidos (regras do negcio).

Ex.:

Todo empregado deve estar lotado num departamento

Existe Cliente que no foi recomendado por Cliente

Toda Nota Fiscal deve ter pelo menos um item discriminado

Toda multa deve estar associada a um carro

Existe carro sem multa associada 127

Podemos caracterizar um relacionamento em termos de:

1. Cardinalidade: quantidade de instncias que podem participar do relacionamento

2. Totalidade: obrigatoriedade da ocorrncia do relacionamento entre as entidades envolvidas.

128


Tipos de Cardinalidade

Um_para_Um (1:1): uma instncia de uma entidade A est associada a no mximo a uma instncia de uma entidade B, e vice-versa.

Um_para_Muitos (1:N): uma instncia de uma entidade A est associada a qualquer nmero de instncias da entidade B. Porm, uma instncia da entidade B pode estar associada, no mximo, a uma instncia da entidade A.

129


Tipos de Cardinalidade

Muitos_para_Um (N:1): uma instncia da entidade A est associada a uma instncia de B. Porm, uma instncia de B pode estar associada a qualquer nmero de instncias de A.

Muitos_para_Muitos(M:N): uma instncia da entidade A est associada a qualquer nmero de instncias da entidade B, e vice-versa.

OBS.: o uso de zero (0:1) ou (0:N) indica a totalidade do relaciomento.

130


a1

a2

a3

a4

a5

b1

b2

b3

b4

b5

A B

1:1

b1

b2

b3

b4

b5

a1

a2

a3

B A

1:N

a1

a2

a3

a4

a5

b1

b2

b3

N:1

a1

a2

a3

a4

a5

b1

b2

b3

b4

b5

N:M

A A B B

131


Representao clssica Chen

A B 1

1

A B 1

N

A B N

1

A B N

M

132

Chaves

Como distinguir as instncias de uma entidade? Num Banco de Dados, isto feito atravs dos atributos das entidades que formam as chamadas chaves de identificao.

Toda instncia de uma entidade deve ter uma chave de identificao, que deve ter algum valor no nulo.

133

Chave de identificao composta: uma chave formada por mais de um atributo.

Ex.: Cenrio: sistema de controle de multas de trnsito.

Premissas: toda multa est relacionada a um carro,

carros devem ser de propriedades de pessoas que tenham carteira de habilitao,

carteiras de habilitao so emitidas pelo DETRAN de cada estado.

134

Chaves

Entidade Chave

Estado Sigla do estado

Motorista Sigla do estado +

nmero da carteira de

habilitao

Carro Sigla do Estado

Nmero da carteira de motorista

Placa do Carro

Multa Sigla do Estado

Nmero da carteira de motorista

Placa do Carro

Nmero de sequncia da multa

135

Chaves

Obs.: Evitar usar chaves compostas sempre que possvel!

Chaves de identificao definidas pelo usurio concorrem entre si como chaves candidatas e so sujeitas mudanas.

Ex.: Entidade : Departamento

Chaves candidatas:

1. Sigla do Departamento

2. Cdigo do Centro de Custo

3. Cdigo da Diretoria + Cdigo da Superintendncia + Cdigo do Departamento

136

Chaves

O que fazer quando:

um departamento mudar de nome?

- for modificada a estrutura de codificao de Centros de Custos?

- um departamento mudar de diretoria?

Soluo: chave de identificao prpria: surrogate ou object identification (object id)

137

Chaves

Surrogates:

- criados para cada entidade (chave primria)

- identifica univocamente cada instncia da entidade

- no precisa ser percebido pelos usurios

- no controlado pelos usurios (gerado automaticamente pelo SGBD)

138

Chaves

MER Estendido

Superclasses e Subclasses

Vimos que uma entidade usada para representar um conjunto de instncias do mesmo tipo (Ex. Empregado).

Porm, muitas vezes uma entidade tem subentidades que necessitam ser representadas explicitamente.

Ex. Empregado pode ser agrupado em: Secretria, Engenheiro e Tcnico

139

Superclasses e Subclasses Estas subentidades so subconjuntos da entidade

Empregado, ou seja, cada instncia de uma subentidade tambm uma instncia da entidade Empregado. Ento dizemos que Secretria _uma Empregada, Engenheiro _um Empregado e Tcnico _um Empregado.

Este relacionamento _um caracteriza a herana. Ou seja, a subentidade (subclasse) herda todos os atributos e relacionamentos da superentidade (superclasse).

140

MER Estendido

Superclasses e Subclasses

importante notar, que nem toda instncia da superentidade membro de uma subentidade.

Ex.: podemos ter empregados que no so nem secretria, nem engenheiro, nem tcnico.

141

MER Estendido

Empregado

_um

Tcnico Engenheiro Secretria

142

MER Estendido

Especializao

o processo de definir um conjunto de subclasses de uma entidade (superentidade).

Podem-se ter vrias especializaes de uma mesma entidade, baseado em caractersticas distintas.

Ex.: A entidade Empregado pode tambm ser especializada nas subentidades Assalariado e Horista.

143

Existem pelo menos duas razes para usar especializao num modelo de dados:

Certos atributos podem ser aplicados somente a algumas instncias de uma entidade (subclasse), mas no a todas.

Ex.: Secretria: lnguas, velocidadeDigitao

Engenheiro: Especialidade, CREA

Motorista: nmero da carteira de habilitao, categoria

Alguns relacionamentos s se aplicam a algumas instncias que pertencem a uma subclasse. Ex.: Horistas pertencem_a Empreiteras

144

Especializao

o processo inverso Especializao, isto , um processo de sntese em que suprimimos as diferenas entre vrias entidades (subclasses), identificamos suas caractersticas comuns e as generalizamos numa superclasse.

145

Generalizao

MER Estendido - Restries

Cobertura Total: cada instncia da superentidade deve ser uma instncia de alguma subentidade.

Ex.: Todo Empregado deve ser Engenheiro, Secretria ou Motorista

Cobertura Parcial: uma instncia de uma superentidade pode no ser membro de nenhuma subclasse.

Ex.: Pode existir empregado que no seja Engenheiro, Secretria nem Motorista.

146

MER Estendido - Restries

Disjuno: uma dada instncia pode ser membro de no mximo uma subentidade.

Ex. Empregado ou secretria, engenheiro ou tcnico.

Sobreposio: uma mesma instncia pode ser membro de mais de uma subentidade.

Ex. Empregado pode ser engenheiro e tcnico.

147

DER - Exemplo

148

Mtodo de Anlise de Requisitos Funcionais

149

Execute a anlise dos requisitos do Gerenciador de Compromissos proposto na Parte 1 da Avaliao

Entregveis:

Documento de Especificao de Requisitos com:

Diagrama de Entidades e Relacionamentos


Opcionais: Diagrama de Classes

Diagrama de Casos de Uso

Outros Diagramas UML 150

Avaliao Parte 2



1 2 3 4

5

Basicamente so gerados dois documentos de requisitos durante o processo de Engenharia de Requisitos:

1. Documento de Definio de Requisitos

Resultado da atividade de Levantamento de Requisitos

2. Documento de Especificao de Requisitos

Resultado da atividade de Anlise de Requisitos

H muitos formatos distintos propostos na literatura.

152


1. Documento de Definio de Requisitos Registro dos requisitos em um documento, de modo

que possam ser verificados, validados e utilizados como base para outras atividades do processo de software.

Para que sejam teis, os requisitos tm de ser escritos em um formato compreensvel por todos os interessados.

Combinao de linguagem natural, modelos, tabelas e outros elementos. Formas de documentao de requisitos na Seo 3.4 [Falbo, 2012].

153


1. Documento de Definio de Requisitos Uma estrutura simples contendo apenas quatro sees:

1. Introduo Breve introduo ao documento, descrevendo seu propsito e

estrutura.

2. Descrio do Propsito do Sistema: Descreve o propsito geral do sistema.

3. Descrio do Minimundo: Apresenta uma viso geral do domnio, do problema a ser resolvido,

dos processos de negcio apoiados e das principais ideias do cliente sobre o sistema a ser desenvolvido.

4. Requisitos de Usurio: Requisitos funcionais, requisitos no funcionais e regras de negcio. 154


2. Documento de Especificao de Requisitos

Tem como propsito registrar os requisitos escritos a partir da perspectiva do desenvolvedor

Deve incluir os vrios modelos conceituais desenvolvidos

Deve incluir a especificao dos requisitos no funcionais detalhados.

155


2. Documento de Especificao de Requisitos 1. Introduo:

breve introduo ao documento, descrevendo seu propsito e estrutura.

2. Modelo de Casos de Uso:

diagramas de casos de uso e as descries de casos de uso associadas.

3. Modelo Estrutural:

diagramas de entidades e relacionamento e diagrama de classes do sistema.

4. Modelo Dinmico:

apresenta os modelos comportamentais dinmicos do sistema, incluindo os diagramas de estados, diagramas de interao e diagramas de atividades.

5. Dicionrio do Projeto:

apresenta as definies dos principais conceitos, servindo como um glossrio do projeto.

6. Especificao dos Requisitos No Funcionais:

apresenta os requisitos no funcionais descritos no nvel de sistema, o que inclui critrios de aceitao. 156




1 2 3 4

5

As atividades de Verificao & Validao (V&V) devem ser iniciadas o quanto antes no processo de desenvolvimento de software, pois quanto mais tarde os defeitos so encontrados, maiores os custos associados sua correo.

V&V de requisitos deve assegurar que: 1. Todos os requisitos do sistema tenham sido declarados de

modo no-ambguo

2. As inconsistncias, conflitos, omisses e erros tenham sido detectados e corrigidos

3. Os documentos esto em conformidade com os padres estabelecidos

4. Os requisitos realmente satisfazem s necessidades dos clientes e usurios.

158


As atividades de Verificao & Validao (V&V) devem ser iniciadas o quanto antes no processo de desenvolvimento de software, pois quanto mais tarde os defeitos so encontrados, maiores os custos associados sua correo.

Verificao x Validao

Verificao assegurar que o software esteja sendo construdo de forma correta Revises realizadas pela equipe do projeto (internamente).

Validao assegurar que o software que est sendo desenvolvido o software correto Revises realizadas pelos usurios ou clientes (externamente).

159


Verificao x Validao

Verificao

realizada em relao consistncia entre requisitos e modelos e conformidade com padres organizacionais de documentao de requisitos.

Validao

Tem de envolver a participao de usurios e clientes, pois somente eles so capazes de dizer se os requisitos atendem aos propsitos do sistema.

160


Tcnicas de Verificao e Validao

Revises Formais

Seguem um processo para realizao de revises (papis, atividades, ferramentas, monitoramento de defeitos).

Revises Informais

Podem ser conduzidas pelos prprios autores dos documentos, por clientes, usurios ou por qualquer envolvido.

No seguem regras pr-estabelecidas.

So baseadas em checklists, guias e templates garantindo padronizaes. 161



Revises Formais X Revises Informais

As revises formais devem ser combinadas com revises informais para uma estratgia de qualidade efetiva e dentro de custos razoveis.

162



Revises Formais

Reviso em Pares (Peer Review)

Inspeo Formal

Walkthrough Estruturado

163



Revises Formais

Reviso em Pares (Peer Review)

Apenas uma pessoa, alm do autor, verifica o artefato.

Depende totalmente da experincia e conhecimento do revisor.

considerada formal, pois existem checklists, guias, templates, registro sistemtico de defeitos e procedimentos especficos de anlise.

164



Revises Formais

Inspeo Formal A inspeo de um artefato deve ser solicitada quando ele chegar a um

ponto de completude razovel.

No devem ser realizadas inspees de artefatos que ainda esto mudando com frequncia.

165


Papis Participantes: Autor Moderador Leitor Escriba Inspetor (Todos so inspetores) Verificador

Atividades: 1. Preparao para a reunio 2. Conduo (leitura do documento) 3. Resultados da reunio 4. Anlise causal (em caso de alto grau de

defeitos)


Revises Formais

Walkthrough Estruturado A diferena principal em relao s inspees que o autor descreve o

artefato para um grupo e solicita comentrios. (no tem o papel do leitor)

Em qualquer ponto do desenvolvimento de um artefato.

No deve durar mais de uma hora e mnimo de participantes trs

166


Papis Participantes: Apresentador Moderador Escriba Especialista de manuteno Especialista de padres Outros Revisores

Atividades: 1. Preparao para a reunio 2. Conduo (rpida apresentao do artefato) 3. Resultados da reunio 4. Anlise causal (em caso de alto grau de

defeitos)


Revises Informais

Demonstrao Muito utilizada para demonstrao de artefatos ou prottipos para

clientes e usurios

Checklists de padres

Guias de padronizao

Comparao com Templates

167


Verificao e Validao Questes:

Os requisitos esto claros?

A fonte dos requisitos est identificada?

Os requisitos foram mostrados para essa fonte?

Os requisitos esto descritos de forma quantitativa?

Os requisitos esto relacionados via referncia cruzada?

Os requisitos violam alguma restrio do domnio?

O requisito testvel? Os testes foram especificados?

Os requisitos so rastreveis para os modelos e o cdigo subsequente?

Existem requisitos implcitos? 168


Exemplos de Ambiguidade:

A janela deve abrir rapidamente

O sistema deve ser flexvel

O clculo deve ser eficiente

A interface com o usurio deve ser melhor que a atual

No devem ser mostradas muitas mensagens de erro

A exibio do mapa de navegao deve ser amigvel

169


Execute verificao dos artefatos gerados nas Partes 1 e 2 da Avaliao

Cada grupo ir verificar os artefatos de outro grupo.

Tcnica: Walkthrough Estruturado

Entregveis:

Lista de Defeitos categorizados por prioridade e tipo. Ambiguidade

Inconsistncia

Omisso

Erro 170

Avaliao Parte 3



1 2 3 4

5

172


Mudana de software inevitvel

Novos requisitos surgem quando o software usado;

O ambiente de negcio muda;

Erros devem ser reparados;

Novos computadores e equipamentos so adicionados ao sistema;

O desempenho ou a confiabilidade do sistema deve ser melhorada.

Um problema-chave para as organizaes a implementao e o gerenciamento de mudanas em seus sistemas e a rastreabilidade entre os artefatos.

173



Objetivo

Controlar as mudanas nos requisitos

Permitir a anlise de impacto das mudanas

174


Custo da evoluo

Distribuio de esforos de manuteno

175

(SOMMERVILLE, 2011)


Distribuio de esforos de manuteno

176

Percentuais de Esforo por

Tipo de Manuteno (PFLEEGER,

2007)


O processo de evoluo de sistema

177

(Sommerville, 2011)


Implementao de mudanas

178

(Sommerville, 2011)


Solicitaes de mudana urgentes

Mudanas urgentes podem ter de ser implementadas sem passar por todos os estgios do processo de desenvolvimento de software

Se um defeito crtico de sistema tem de ser reparado;

Se mudanas no ambiente do sistema (por exemplo, atualizao do OS) tm efeitos inesperados;

Se existem mudanas de negcio que necessitam de uma resposta muito rpida (por exemplo, o release de um produto concorrente)

179


Reparo de emergncia

180

(Sommerville, 2011)


Processo de Manuteno

181

Basili (1990) props trs paradigmas diferentes para tratar a manuteno de software:

(i) Conserto Rpido;

(ii) Melhoria Interativa;

(iii) Reuso Total


Conserto Rpido

182

Essa abordagem corresponde normalmente preferida pelo mantenedor, justificando a deciso pela urgncia da manuteno (Visaggio, 2001).


Melhoria Interativa

183

prope inicialmente adequar e atualizar a documentao de alto nvel que ser afetada, para ento propagar as mudanas at o nvel de cdigo-fonte.


Reuso Total

184

Reuso total, consiste em construir um novo software, utilizando componentes do software antigo e outros disponveis em um repositrio.


Matriz de Reastreabilidade

185

Matrizes de rastreabilidade so os principais artefatos produzidos na fase de gerncia de requisitos.

Elas relacionam os requisitos identificados a um ou mais aspectos do sistema ou do seu ambiente

Permitem obter um entendimento de como uma modificao em um requisito vai afetar diferentes aspectos do sistema.



186

Matriz de rastreabilidade de dependncia: indica como os requisitos esto relacionados uns com os outros.

Matriz de rastreabilidade requisitos fontes: indica a fonte de cada requisito.

Matriz de rastreabilidade requisitos subsistemas: indica os subsistemas que tratam os requisitos.

Matriz de rastreabilidade requisitos de usurio casos de uso: indica os casos de uso que detalham um requisito funcional ou tratam um requisito no funcional ou regra de negcio.



187



188


Regressiva a partir dos requisitos relaciona requisitos com suas origens (outros documentos

ou pessoas); Progressiva a partir dos requisitos

relaciona requisitos aos artefatos do projeto (planos, modelos de anlise e projeto, cdigo etc.);

Regressiva em direo aos requisitos relaciona artefatos do projeto aos requisitos;

Progressiva em direo aos requisitos relaciona as fontes (p.ex., documentos que precederam o

documento de requisitos) aos requisitos relevantes.


189


CMMI

190

Engenharia de Requisitos e Normas e Modelos de Qualidade de Processos de Software

O CMMI um modelo de qualidade de processo desenvolvido pelo (Software Engineering Institute SEI) da Universidade de Carnegie Mellon.

Tem como objetivo fornecer diretrizes para a definio e melhoria de processos de software de uma organizao

Cinco nveis de maturidade na representao em estgios: 1- Inicial 2- Gerenciado 3- Definido 4- Gerenciado Quantitativamente 5- Em Otimizao

191


CMMI - Nvel 2- Gerenciado rea de processo: Gesto de Requisitos (REQM)

SG 1 Gerenciar Requisitos SP 1.1 Entender os requisitos. SP 1.2 Obter comprometimento com os requisitos. SP 1.3 Gerenciar mudanas de requisitos. SP 1.4 Manter rastreabilidade bidirecional dos requisitos. SP 1.5 Garantir alinhamento entre o trabalho de projeto

(planos de projeto e produtos de trabalho) e requisitos.

192


CMMI - Nvel 3- Definido rea de Processo: Desenvolvimento de Requisitos (RD)

SG 1 Desenvolver Requisitos de Cliente SP 1.1 Levantar necessidades. SP 1.2 Transformar necessidades dos interessados em requisitos de cliente.

SG 2 Desenvolver Requisitos do Produto SP 2.1 Estabelecer os requisitos do produto e de componentes do produto. SP 2.2 Alocar requisitos de componentes do produto. SP 2.3 Identificar requisitos de interface.

SG 3 Analisar e Validar Requisitos SP 3.1 Estabelecer conceitos e cenrios operacionais. SP 3.2 Estabelecer uma definio da funcionalidade e dos atributos de

qualidade requeridos. SP 3.3 Analisar requisitos. SP 3.4 Analisar requisitos para balancear. SP 3.5 Validar requisitos.

MPS.BR

193


O MPS.BR (Melhoria de Processo do Software Brasileiro) (SOFTEX, 2011) um programa mobilizador, que tem como objetivo a melhoria de processo do software brasileiro.

Tem como objetivo definir e aprimorar um modelo de melhoria e avaliao de processo de software, visando preferencialmente s micro, pequenas e mdias empresas. Sete nveis de maturidade:

G- Parcialmente Gerenciado F- Gerenciado, E- Parcialmente Definido D- Largamente Definido C- Definido B- Gerenciado Quantitativamente A- Em Otimizao

194


MPS.BR - Nvel G - Parcialmente Gerenciado rea de processo: Gerncia de Requisitos

GRE 1. O entendimento dos requisitos obtido junto aos fornecedores de requisitos;

GRE 2. Os requisitos so avaliados com base em critrios objetivos e um comprometimento da equipe tcnica com esses requisitos obtido;

GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho estabelecida e mantida;

GRE 4. Revises em planos e produtos de trabalho do projeto so realizadas visando identificar e corrigir inconsistncias em relao aos requisitos;

GRE 5. Mudanas nos requisitos so gerenciadas ao longo do projeto.

195


MPS.BR - Nvel D - Parcialmente Gerenciado rea de processo: Desenvolvimento de Requisitos

DRE 1. As necessidades, expectativas e restries do cliente, tanto do produto quanto de suas interfaces, so identificadas;

DRE 2. Um conjunto definido de requisitos do cliente especificado e priorizado a partir das necessidades, expectativas e restries identificadas;

DRE 3. Um conjunto de requisitos funcionais e no-funcionais, do produto e dos componentes do produto que descrevem a soluo do problema a ser resolvido, definido e mantido a partir dos requisitos do cliente;

DRE 4. Os requisitos funcionais e no-funcionais de cada componente do produto so refinados, elaborados e alocados;

DRE 5. Interfaces internas e externas do produto e de cada componente do produto so definidas;

DRE 6. Conceitos operacionais e cenrios so desenvolvidos; DRE 7. Os requisitos so analisados, usando critrios definidos, para balancear as

necessidades dos interessados com as restries existentes; DRE 8. Os requisitos so validados.

engenharia requisitos

Documents