aula05fapan

(1)

ENGENHARIA DE SOFTWARE

Prof. Paulo Malcher

prcmalcher@gmail.com

https://sites.google.com/site/professorpaulomalcher/

(2)

(3)

Engenharia de Requisitos - Conceitos

• O tratamento da informação é um requisito que

fundamenta o processo de desenvolvimento de

software antes da solução de tecnologia a ser

aplicada.

• Cada

projeto

deve

ter

suas

fases

de

desenvolvimento adequadas às necessidades

de tratamento da informação.

(4)

Engenharia de Requisitos - Conceitos

• Requisito(s) é (são):

• “Descrições das funções e das restrições de um sistema” (SOMMERVILLE, 2011)

• “Definição detalhada, matematicamente formal, de uma função do sistema” (SOMMERVILLE, 2011)

(5)

Engenharia de Requisitos - Conceitos

• Requisito(s) é (são):

• “uma descrição dos principais recursos de um produto de software, seu fluxo de informações, comportamento e atributos. Fornece uma estrutura básica para o desenvolvimento de um produto de software. O grau de compreensibilidade, precisão e rigor da descrição fornecida por um documento de requisitos de software tende a ser diretamente proporcional ao grau de qualidade do produto resultante” (PETERS, 2009).

(6)

Engenharia de Requisitos - Conceitos

• Engenharia

de

Requisitos

é

segundo

Sommerville (2011):

• “O processo de (em relação aos requisitos):

(7)

Engenharia de Requisitos - Conceitos

• Engenharia de Requisitos é:

• “Estabelecer quais funções são requeridas pelo sistema e as restrições sobre a operação e o desenvolvimento do sistema” (SOMMERVILLE, 2011)

(8)

Engenharia de Requisitos - Conceitos

• Engenharia de Requisitos é:

• “Um processo que envolve todas as atividades exigidas para criar e manter o documento de requisitos de sistema” (SOMMERVILLE, 2011).

(9)

Engenharia de Requisitos - Conceitos

• Definição Genérica:

• Estabelecer o que o cliente quer de um sistema de software

• Definição da IEEE:

• Processo de aquisição, refinamento e verificação das necessidades do cliente, com o objetivo de obter uma especificação correta e completa dos requisitos.

(10)

Engenharia de Requisitos - Conceitos

• Definição de Davis:

• Durante a fase de requisitos, é necessário analisar, e portanto entender o problema a ser resolvido.

• A análise do problema é a atividade que inclui o entendimento das necessidades do usuário e as limitações impostas na solução.

(11)

Engenharia de Requisitos - Conceitos

• Definição de Boehm

• Disciplina para desenvolver uma especificação completa, consistente e não ambígua do software;

• Um acordo entre as partes descrevendo o que o produto de software irá fazer.

(12)

Engenharia de Requisitos - Conceitos

• Definição de Meyer

• Especificar o documento de requisitos de um software é definir de uma forma completa e não ambígua:

• As características externas do software oferecidas aos usuários;

(13)

Engenharia de Requisitos - Motivação

• Baixo nível de aceitação dos sistemas pelos

usuários.

• S.I. comerciais: 40%

(14)

Engenharia de Requisitos - Motivação

• O documento de requisitos é um

acordo

contratual entre clientes e fornecedores;

• Os

desenvolvedores

de

software

têm

obrigação de inquirir

os

requisitos dos seus

clientes;

• Os

desenvolvedores

de

software

têm

a

obrigação de informar

seus usuários

acerca

da solução proposta (um manual de usuários

não é suficiente!).

(15)

Engenharia de Requisitos - Motivação

40% 66% 30% 25% 30% 9% 0% 10% 20% 30% 40% 50% 60% 70%

% total erros % total do custo de correção erros Especificação Projeto

(16)

Engenharia de Requisitos - Objetivos

• Engenharia de Requisitos objetiva:

• Fornecer métodos para compreender a natureza de um problema

• Estabelecer com exatidão o que um sistema deve fazer

(17)

Requisitos – Conceitos Básicos

• Fala-se muito sobre requisitos; propagam-se

necessidades de gestão de mudanças de

atendimento ao cliente;

• Diz-se

muito

de

métodos,

técnicas

e

ferramentas para descrevê-los e

representá-los, mas muito pouco da aplicação prática

deste conhecimento

(18)

Requisitos – Conceitos Básicos

• O requisito é uma condição cuja exigência deve

ser satisfeita.

• Se a condição é produzir algo, diz-se que o requisito é funcional.

• Se a condição é caracterizar algo (propriedade, comportamento, restrição, etc,...), diz-se que o

(19)

Requisitos – Visões

• REQUISITOS DOS USUÁRIO

(20)

Requisitos – Visões

• REQUISITOS DO USUÁRIO

• Declarações em linguagem natural com diagramas de serviços que o sistema deve oferecer e suas restrições operacionais. Escrito para os clientes.

(21)

Visão dos Requisitos

• REQUISITOS DO SISTEMA

• Documento estruturado com descrições detalhadas sobre os serviços do sistema. Contrato entre cliente e fornecedor.

(22)

Requisitos – Tipos

• REQUISITOS FUNCIONAIS

• REQUISITOS NÃO FUNCIONAIS

(23)

Requisitos – Tipos

• REQUISITOS FUNCIONAIS

• Correspondem à listagem de todas as coisas que o sistema deve fazer.

• Descreve funcionalidade e serviços do sistema

• Dependem do:

• Tipo do software.

• Usuários esperados.

(24)

Requisitos – Tipos

• REQUISITOS FUNCIONAIS

• Serviços que o sistema deve prover, como o sistema deve reagir a determinadas entradas e como o sistema deve se comportar em determinadas situações.

(25)

Requisitos – Tipos

• REQUISITOS FUNCIONAIS

• Requisitos funcionais evidentes são efetuados com conhecimento do usuário;

• Requisitos funcionais ocultos são efetuados pelo sistema sem o conhecimento explícito do usuário;

(26)

26

Requisitos – Tipos – Exemplo

• REQUISITOS FUNCIONAIS

• [RF001] Usuário pode pesquisar todo ou um sub-conjunto do banco de dados

• [RF002] Sistema deve oferecer visualizadores apropriados para o usuário ler documentos armazenados

• [RF003] A todo pedido deve ser associado um identificador único (PID), o qual o usuário pode copiar para a área de armazenamento permanente da conta

(27)

27

Requisitos – Tipos – Exercícios

• REQUISITOS FUNCIONAIS

• Dê alguns exemplos de R.F.s para:

1. Sistema da padaria de pequeno porte;

2. Sistema inteligente de preenchimento do IRPF;

(28)

Requisitos – Tipos

• REQUISITOS NÃO FUNCIONAIS

• Definem propriedades e restrições do sistema (tempo, espaço, etc).

• São restrições e qualidades que se coloca sobre como o sistema deve realizar seus requisitos funcionais.

(29)

Requisitos – Tipos

• REQUISITOS NÃO FUNCIONAIS

• Restrições aos serviços ou funções oferecidas pelo sistema, tais como restrições de tempo, restrições quanto ao processo de desenvolvimento, padrões, etc.

(30)

Requisitos – Tipos

• REQUISITOS NÃO FUNCIONAIS

• Classificação

• Usabilidade: requisitos que selecionam ou afetam a

usabilidade do sistema. Exemplos incluem a facilidade de uso e a necessidade ou não de treinamento dos usuários.

• Confiabilidade: Tratamento de falhas, possibilidade de

previsão, não erros de programação.

• Desempenho: Velocidade, eficiência, precisão, tempo de

(31)

Requisitos – Tipos

• REQUISITOS NÃO FUNCIONAIS

• Classificação

• Configurabilidade: o que pode ser configurado pelos

usuários do sistema.

• Portabilidade: restrições sobre a plataforma de hardware e

de software nas quais o sistema será implantado e sobre o grau de facilidade para transportar o sistema para outras plataformas.

(32)

Requisitos – Tipos

• REQUISITOS NÃO FUNCIONAIS

• Devido à sua própria definição, requisitos não-funcionais são mensuráveis.

• Assim, deve-se associar forma de medida/referência a cada requisito não-funcional.

(33)

Requisitos – Tipos

• REQUISITOS NÃO FUNCIONAIS - MEDIDAS

Propriedade Medida

Velocidade Transações processadas/seg

Tempo de resposta do usuário/evento

Tamanho K bytes

No _{de chips de RAM}

Facilidade de uso Tempo de treinamento No _{de quadros de ajuda}

Confiabilidade Tempo médio de falhas

Probabilidade de indisponibilidade Taxa de ocorrência de falhas

Robustez Tempo de reinício após falha

Percentual de eventos causando falhas

Probabilidade de corrupção de dados após falha Portabilidade Percentual de declarações dependentes do destino

(34)

Requisitos – Tipos - Exemplos

• REQUISITOS NÃO FUNCIONAIS

• [RNF001] Toda consulta ao B.D., baseada em código de barras, deve resultar em até 5 s.

• [RNF002] Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00.

• [RNF003] Informações pessoais do usuário não devem ser vistas pelos operadores do sistema

(35)

35

Requisitos – Tipos – Exercícios

• REQUISITOS NÃO FUNCIONAIS

(36)

Requisitos – Tipos

• REQUISITOS DE DOMÍNIO

• Derivados do domínio da aplicação e descrevem características do sistema e qualidades que refletem o domínio

• Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas.

• Se requisitos de domínio não forem satisfeitos, o sistema pode tornar-se não prático

(37)

Requisitos – Tipos

• REQUISITOS DE DOMÍNIO - PROBLEMAS

• Entendimento

• Requisitos são descritos na linguagem do domínio da aplicação

• Não é entendido pelos engenheiros de software que vão desenvolver a aplicação

• Implicitude

• Especialistas no domínio entendem a área tão bem que não tornam todos os requisitos de domínio explícitos

(38)

Requisitos – Tipos - Exemplos

• REQUISITOS DE DOMÍNIO - PROBLEMAS

• A desaceleração do trem deve ser computada através da fórmula D_trem=D_controle+D_gradiente onde...

(39)

39

Requisitos – Tipos – Exercícios

• REQUISITOS DE DOMÍNIO

(40)

40

Requisitos – Conclusões

Requisitos Não-funcionais Organização Funcionais Domínio Produto Externo Sistema Usuário =_df

(41)

Requisitos – Conclusões

• Descrever requisitos funcionais e requisitos

não-funcionais requer tratar dois aspectos:

• "Produzir";

(42)

Requisitos – Conclusões

• O processo de produção de software depende

da definição clara de qual produto construir.

• Esta definição fundamenta-se no conhecimento

do problema e na viabilização de oportunidade

de negócio com o uso de tecnologia da

informação.

(43)

Requisitos – Conclusões

• A estratégia é o tratamento multidisciplinar da

informação de requisitos obtida do ponto de

vista dos stakeholder (fonte de informação)

para

o

entendimento

e

atendimento

às

necessidades.

(44)

Requisitos - Desafios

• Como descobrir os requisitos;

• Como comunicar os requisitos para as outras

fases ou equipes do projeto;

• Como

lembrar

dos

requisitos

durante

o

desenvolvimento e verificar se foram todos

atendidos

(45)

Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Engenharia de Requisitos - Processo

• O processo de estabelecer que serviços são

requeridos e as restrições à operação e

desenvolvimento do sistema

• Processo de Engenharia de Requisitos

• Estudo de viabilidade

• Elicitação e análise de requisitos

• Especificação de requisitos

(46)

Engenharia de Requisitos - Processo

Estudo de viabilidade Relatório de viabilidade Elicitação de requisitos e análise Modelos do sistema Especificação de requisitos Validação de requisitos Requisitos do usuário e do sistema Documento de requisitos Documento de Visão

(47)

Engenharia de Requisitos - Processo

(48)

48

Eng. de Requisitos – Estudo de Viabilidade

• O estudo de viabilidade decide se vale a pena

desenvolver o sistema proposto. É baseado em

coleta, avaliação e escrita de relatórios.

(49)

49

Eng. de Requisitos – Estudo de Viabilidade

• Um estudo breve que verifica se:

• O sistema contribui para os objetivos da organização

• O sistema pode ser implementado com a tecnologia atual e dentro do orçamento

• O sistema pode ser integrado com outros sistemas em operação

(50)

50

Eng. de Requisitos – Estudo de Viabilidade

• Questões para pessoas na organização:

• O que aconteceria se o sistema não fosse implementado?

• Quais são os problemas com os processos atuais?

(51)

51

Eng. de Requisitos – Estudo de Viabilidade

• Questões para pessoas na organização:

• Pode haver troca de informações entre outros sistemas e o sistema proposto?

• Será necessário nova tecnologia? Quais habilidades?

• O que precisa e o que não precisa ser compatível com o sistema?

(52)

52

Eng. de Requisitos – Estudo de Viabilidade

• Estudo que indica se o esforço em desenvolver

a ideia vale a pena

• Visa tanto a tomada de decisão.

• Como a sugestão de possíveis alternativas de solução.

(53)

53

Eng. de Requisitos – Estudo de Viabilidade

• Deve oferecer informações para ajudar nas

seguintes decisões:

• Se o projeto pode ou não ser feito

• Se o produto final irá ou não beneficiar os usuários interessados

• Escolha das alternativas entre as possíveis soluções.

(54)

54

Eng. de Requisitos – Estudo de Viabilidade

• Entrada: Esboço da descrição do sistema e um

conjunto inicial de requisitos de negócio.

• Saída: relatório que recomenda se vale a pena

ou não construir o sistema.

O relatório também pode propor mudanças de

escopo, orçamento e prazo.

(55)

55

Eng. de Requisitos – Estudo de Viabilidade

• Tempo de duração: normalmente de uma a

três semanas.

• Fontes

de

informação:

gerentes

de

departamentos,

engenheiros

de

software

especialistas

no

domínio,

usuários

finais,

normas e legislação etc.

(56)

Engenharia de Requisitos

-Processo

(57)

Engenharia de Requisitos

-Processo

(58)

Eng. de Requisitos – Elicitação

• Esta atividade divide-se em dois esforços

maiores:

• Elicitação dos requisitos em si

• Técnicas de elicitação

• Análise do que foi elicitado

(59)

Eng. de Requisitos – Elicitação

• Esta atividade divide-se em dois esforços

maiores:

• Elicitação dos requisitos em si

• Técnicas de elicitação

• Análise do que foi elicitado

(60)

Que é um requisito?

• Tanto pode ser...

• ...uma declaração abstrata de alto nível de um serviço...

• ...como uma restrição do sistema...

• ...Quanto

uma

especificação

funcional

matemática detalhada.

(61)

Elicitação de Requisitos

• Também

denominada

de

descoberta

de

requisitos

• Envolve

pessoal

objetivando

descobrir

o

domínio de aplicação, serviços que devem ser

fornecidos bem como restrições

• Deve

envolver

usuários

finais,

gerentes,

pessoal

envolvido

na

manutenção,

especialistas no domínio, etc. (Stakeholders).

(62)

(63)

(64)

(65)

(66)

(67)

Elicitação de Requisitos - Técnicas

• Uma vez que levantar requisitos não é tarefa

fácil, é imprescindível que essa atividade seja

cuidadosamente conduzida, fazendo uso de

diversas técnicas.

• Dentre as diversas técnicas que podem ser

aplicadas para o levantamento de requisitos,

destacam-se:

(68)

Elicitação de Requisitos - Técnicas

• Entrevistas

• Questionários

• Observação

• Prototipação

• Brainstorming

• Workshop de Requisitos

• investigação de documentos

(69)

Elicitação de Requisitos - Técnicas

• TIPOS

• Kendall e Kendall (2010) classificam os métodos de levantamento de requisitos em dois grandes grupos: métodos interativos e métodos não obstrutivos.

(70)

Elicitação de Requisitos - Técnicas

• TIPOS

• Métodos Interativos: envolvem a interação com

membros da organização, como é o caso de entrevistas e workshops de requisitos.

• Métodos não obstrutivos: procuram não interferir

no trabalho dos membros da organização. Este é o caso de métodos como observação e investigação de documentos.

(71)

Elicitação de Requisitos - Técnicas

• TIPOS

• Alexander e Beus-Dukic (2009), por sua vez, organizam as técnicas de levantamento de requisitos pelo contexto no qual pode se dar a descoberta de requisitos.

(72)

Elicitação de Requisitos - Técnicas

• TIPOS

• a partir de indivíduos (entrevistas, por exemplo).

• a partir de grupos (workshops de requisitos).

(73)

Elicitação de Requisitos - Técnicas

• ENTREVISTA

• Técnica direta que pode ser usada na análise do problema e na elicitação de requisites.

• Tem como objetivo entender os problemas reais e soluções potenciais das perspectivas dos usuários, clientes, e outros stakeholders

(74)

Elicitação de Requisitos - Técnicas

• ENTREVISTA

• Entrevistas são, provavelmente, a técnica mais comumente utilizada no levantamento de requisitos (AURUM; WOHLIN, 2005).

• Uma entrevista é uma conversa direcionada com um propósito específico, que utiliza um formato “pergunta-resposta” (KENDALL; KENDALL, 2010).

(75)

Elicitação de Requisitos - Técnicas

• ENTREVISTA

• Entrevistas são usadas em quase todos os esforços de levantamento de requisitos. Nelas, os analistas formulam questões para os interessados e os requisitos são derivados das respostas a essas perguntas (SOMMERVILLE, 2011).

(76)

Elicitação de Requisitos - Técnicas

• ENTREVISTA

• Uma entrevista é feita tipicamente por meio de uma reunião envolvendo o analista (entrevistador) e um interessado no sistema (entrevistado).

(77)

Elicitação de Requisitos - Técnicas

• ENTREVISTA

• Assim, é um método interativo de levantamento de requisitos a partir de um indivíduo. Contudo, uma entrevista pode envolver mais de um entrevistador e mais de um entrevistado.

(78)

Elicitação de Requisitos - Técnicas

• ENTREVISTA

• As entrevistas podem ser de dois tipos principais (SOMMERVILLE, 2011):

• Entrevistas fechadas: nas quais o interessado responde a

um conjunto de perguntas predefinidas.

• Entrevistas abertas: nas quais não existe um roteiro

predefinido. O analista explora vários assuntos com o interessado e, assim, desenvolve uma maior compreensão de suas necessidades.

(79)

Elicitação de Requisitos - Técnicas

• ENTREVISTA

• Uma entrevista precisa ser planejada. Tipicamente, o planejamento de uma entrevista, assim como o de outras atividades de levantamento de requisitos, deve considerar as quatro perguntas básicas:

(80)

Elicitação de Requisitos - Técnicas

• ENTREVISTA

• Por que?: a primeira coisa a ser feita é estabelecer

os objetivos da entrevista.

• Quem?: tendo em mente o objetivo da entrevista, o

próximo passo é identificar quais membros da organização têm conhecimento acerca do assunto a ser tratado e selecionar as pessoas a serem entrevistadas

(81)

Elicitação de Requisitos - Técnicas

• ENTREVISTA

• Quando?: no que se refere à questão temporal de

uma entrevista, dois aspectos devem ser considerados: primeiro, a data e o horário; segundo, a duração.

• Onde?: definir o local onde se dará a entrevista.

Normalmente, o analista vai até o local de trabalho do entrevistado.

(82)

Elicitação de Requisitos - Técnicas

• ENTREVISTA

• Como?: conhecendo o objetivo, o entrevistado (e

seu perfil) e o tempo disponível, resta preparar a entrevista cuidadosamente para que a mesma seja o mais produtiva possível.

(83)

Elicitação de Requisitos - Técnicas

• ENTREVISTA

• Quem são o cliente e o usuário?

• Possuem necessidades diferentes?

• Quais são suas

• Capacidades

• Backgrounds

• Ambientes, etc.

• Qual é o problema?

(84)

Elicitação de Requisitos - Técnicas

• ENTREVISTA

• Qual a razão para resolvê-lo?

• Qual o valor de uma solução bem-sucedida?

• Onde mais uma solução pode ser encontrada?

Note que algumas dessas

perguntas já foram feitas

no estudo de viabilidade.

(85)

Elicitação de Requisitos - Técnicas

• QUESTIONÁRIOS

• Questionário ou survey é uma técnica de levantamento de informações que permite ao analista capturar, de várias pessoas afetadas pelo sistema, atitudes, crenças, comportamentos e características.

(86)

Elicitação de Requisitos - Técnicas

• QUESTIONÁRIOS

• Atitudes referem-se a o que as pessoas na organização dizem querer; crenças referem-se a o que as pessoas pensam ser realmente verdade; comportamento é o que as pessoas fazem; características são propriedades de pessoas ou coisas (KENDALL; KENDALL, 2010).

(87)

Elicitação de Requisitos - Técnicas

• QUESTIONÁRIOS

• Questionários proveem um meio eficiente de coletar informações de vários interessados. Entretanto, são limitados no que tange à profundidade do conhecimento que pode ser levantado, uma vez que não permitem que um tópico seja aprofundado ou que ideias sejam expandidas (AURUM; WOHLIN, 2005).

(88)

Elicitação de Requisitos - Técnicas

• QUESTIONÁRIOS

• Questionários podem ter questões objetivas ou

subjetivas. Questões subjetivas são particularmente

adequadas a situações em que se deseja saber a opinião dos membros da organização acerca de algum aspecto do sistema, sendo impossível, portanto, listar efetivamente todas as respostas possíveis para uma pergunta.

(89)

Elicitação de Requisitos - Técnicas

• QUESTIONÁRIOS

• Aplicabilidade a mercados específicos.

• Onde perguntas são bem definidas.

• Hipóteses.

• Perguntas relevantes podem ser decididas antecipadamente.

• Leitor ouve da maneira desejada.

• Suprime o que é bom sobre análise.

(90)

Elicitação de Requisitos - Técnicas

• OBSERVAÇÃO

• As pessoas, muitas vezes, têm dificuldade em articular detalhes de seu trabalho, pois estão imersas nele e fazem muitas coisas de maneira intuitiva. Contudo, os contextos social e organizacional em que as pessoas trabalham são importantes para o desenvolvimento de um sistema e podem derivar requisitos e restrições (SOMMERVILLE, 2011).

(91)

Elicitação de Requisitos - Técnicas

• OBSERVAÇÃO

• Assim, observar o comportamento e o ambiente do indivíduo, sobretudo aquele que toma decisões, pode ser uma forma bastante eficaz de levantar informações que, tipicamente, passam despercebidas quando outras técnicas são usadas (KENDALL; KENDALL, 2010).

(92)

Elicitação de Requisitos - Técnicas

• OBSERVAÇÃO

• A observação é uma das técnicas de etnografia mais usadas no levantamento de requisitos. Como o próprio nome indica, o analista observa os usuários executando os processos, sem interferência direta (AURUM; WOHLIN, 2005).

(93)

Elicitação de Requisitos - Técnicas

• OBSERVAÇÃO

• Ela é empregada para compreender requisitos sociais e organizacionais, bem como para compreender como as tarefas são realizadas efetivamente.

(94)

Elicitação de Requisitos - Técnicas

• OBSERVAÇÃO

• O analista se insere no ambiente de trabalho onde o sistema será usado, observa o trabalho do dia-a-dia e faz anotações acerca das tarefas reais nas quais os participantes estão envolvidos (SOMMERVILLE, 2011).

(95)

Elicitação de Requisitos - Técnicas

• OBSERVAÇÃO

• Como outras técnicas de levantamento de requisitos, a observação envolve planejamento, condução e o registro de resultados. No planejamento, o analista deve definir o que observar, quem observar,

(96)

Elicitação de Requisitos - Técnicas

• PROTOTIPAÇÃO

• Muitas vezes as pessoas acham difícil visualizar como um requisito especificado na forma de uma sentença escrita ou por um conjunto de modelos vai se materializar em um sistema de software. De maneira geral, pessoas têm dificuldade de descrever suas necessidades sem ter algo tangível à sua frente.

(97)

Elicitação de Requisitos - Técnicas

• PROTOTIPAÇÃO

• Nesses casos, se um protótipo do sistema é desenvolvido para demonstrar requisitos, fica mais fácil para usuários e outros interessados encontrar problemas e sugerir como os requisitos podem ser melhorados. Afinal, criticar é mais fácil do que criar (KOTONYA; SOMMERVILLE, 1998; WIEGERS, 2003).

(98)

Elicitação de Requisitos - Técnicas

• PROTOTIPAÇÃO

• Um protótipo é uma versão inicial do sistema que é desenvolvido no início do processo de desenvolvimento. No contexto da engenharia de requisitos, um protótipo é desenvolvido com o propósito de apoiar o levantamento e a validação de requisitos. Assim, nesse contexto, uma característica essencial de um protótipo é que ele seja desenvolvido rapidamente (KOTONYA; SOMMERVILLE, 1998).

(99)

Elicitação de Requisitos - Técnicas

• PROTOTIPAÇÃO

• A prototipagem é uma técnica valiosa para o levantamento de requisitos. Ela torna os requisitos mais reais e diminui lacunas de entendimento. Ao colocar o usuário na frente de uma porção inicial ou uma imitação do sistema, a prototipagem estimula os usuários a pensar e a estabelecer um diálogo sobre os requisitos.

(100)

Elicitação de Requisitos - Técnicas

• BRAINSTORM

• Neste tipo de reunião, representantes de diferentes grupos de interessados engajam-se em uma discussão informal para gerar rapidamente tantas ideias quanto possível, sem focar a atenção em nenhuma delas.

(101)

Elicitação de Requisitos - Técnicas

• BRAINSTORM

• Normalmente não é propósito de uma sessão de brainstorming resolver maiores questões ou tomar decisões.

• Essa técnica é frequentemente utilizada para desenvolver uma declaração preliminar da missão e dos requisitos para o sistema.

(102)

Elicitação de Requisitos - Técnicas

• BRAINSTORM

• Um diferencial dessa técnica é que ela promove a livre expressão, favorecendo a descoberta de soluções novas e inovadoras para problemas existentes (AURUM; WOHLIN, 2005).

(103)

Elicitação de Requisitos - Técnicas

• BRAINSTORM

• Regras para Brainstorming

• Estabeleça o objetivo da sessão

• Gere quantas ideias for possível

• Deixe sua imaginação livre

• Não admita críticas ou debates

(104)

Elicitação de Requisitos - Técnicas

• WORKSHOP DE REQUISITOS

• É um técnica de coleta colaborativa de requisitos. Onde ocorre um número de diferentes tipos de reuniões envolvendo diversas pessoas, cujo foco é a descoberta e desenvolvimento de requisitos (AURUM; WOHLIN, 2005).

(105)

Elicitação de Requisitos - Técnicas

• WORKSHOP DE REQUISITOS

• Coloca-se um grupo de pessoas juntas, com o objetivo de levantar requisitos para um problema compartilhado, para o qual essas pessoas têm visões distintas.

(106)

Elicitação de Requisitos - Técnicas

• WORKSHOP DE REQUISITOS

• O propósito é obter conhecimento e energia suficientes para levantar requisitos rápida e eficientemente (ALEXANDER; BEUS-DUKIC, 2009).

(107)

Elicitação de Requisitos - Técnicas

• WORKSHOP DE REQUISITOS

• Põe todos os stakeholders juntos por um período intensivo (focado). Onde um Facilitador conduz a reunião, definindo que todos têm sua vez de falar e os resultados são disponíveis imediatamente, provendo assim um ambiente propício para aplicar outras técnicas de elicitação.

(108)

Elicitação de Requisitos - Técnicas

• WORKSHOP DE REQUISITOS

• Um workshop de requisitos não é simplesmente uma reunião. Um workshop é uma reunião com propósito definido e atividades planejadas. Assim, requer planejamento endereçando as cinco questões básicas: • Por que? • Quem? • Quando? • Onde? • Como?

(109)

Elicitação de Requisitos - Técnicas

• ANÁLISE DE DOCUMENTOS

• Em qualquer negócio, há vários documentos cuja interpretação pode ajudar no levantamento de informações, tais como relatórios usados na tomada de decisão, fichas e uma variedade de formulários.

(110)

Elicitação de Requisitos - Técnicas

• ANÁLISE DE DOCUMENTOS

• Documentos com formato pré-determinado, tais como relatórios e formulários, têm um propósito específico e um público-alvo e trazem informações muito úteis.

(111)

Elicitação de Requisitos - Técnicas

• ANÁLISE DE DOCUMENTOS

• Relatórios de desempenho, por exemplo, podem mostrar metas da organização, a distância em que a organização se encontra da meta e a tendência atual. Relatórios usados no processo de tomada de decisão mostram informações compiladas e podem incorporar algum conhecimento sobre a estratégia da organização.

(112)

Elicitação de Requisitos - Técnicas

• ANÁLISE DE DOCUMENTOS

• Formulários, assim como fichas, são muito úteis para o levantamento de requisitos de informação. Tais informações são difíceis de serem obtidas através de outras técnicas de levantamento de requisitos, como entrevistas e observação (KENDALL; KENDALL, 2010)

(113)

Elicitação de Requisitos - Técnicas

• ANÁLISE DE DOCUMENTOS

• Benchmarking é um processo contínuo de comparação dos produtos, serviços e práticas empresarias entre os mais fortes concorrentes ou empresas reconhecidas como líderes.

• Benchmarking. surgiu como uma necessidade de informações e desejo de aprender depressa, como corrigir um problema empresarial.

(114)

Elicitação de Requisitos - Exercício

• Quais técnicas poderiam ser usadas em:

• 1. Sistema da padaria de pequeno porte;

• 2. Sistema inteligente de preenchimento do IRPF;

(115)

Eng. de Requisitos – Elicitação

• Esta atividade divide-se em dois esforços

maiores:

• Elicitação dos requisitos em si

• Técnicas de elicitação

• Análise do que foi elicitado

(116)

Elicitação de Requisitos – Análise

Entendimento do domínio Coleta de requisitos Classificação Definição e especificação de requisitos Resolução de conflito Atrib. Prioridade Validação dos requisitos Entrada do processo Documento de requisitos 1 2 3 4 5 6 7 8

(117)

Elicitação de Requisitos – Análise

• ENTENDIMENTO DO DOMÍNIO

• Desenvolver sistemas envolve domínios além de software e hardware

• Podemos ter que entender sobre

• Contabilidade

• Saúde

• Supermercados

(118)

Elicitação de Requisitos – Análise

• COLETA DE REQUISITOS

• Como vimos anteriormente, a coleta de requisitos é feita através de técnicas

• Nesta etapa, os requisitos são simplesmente documentados à medida que são coletados

(119)

Elicitação de Requisitos – Análise

• CLASSIFICAÇÃO DOS REQUISITOS

• Esta etapa consiste basicamente em agrupar os diversos requisitos coletados em categorias (clusters) bem-definidos

• Por exemplo

• Deve ser possível consultar o preço de uma mercadoria

(120)

Elicitação de Requisitos – Análise

• RESOLUÇÃO DE CONFLITOS

• É normal que ocorram requisitos conflitantes

• Por exemplo

• R-23: O sistema deve ...

• R-45: O sistema não deve ...

• Cliente/usuário deve ser consultado para resolver conflitos (ambiguidades)

(121)

Elicitação de Requisitos – Análise

• ATRIBUIÇÃO DE PRIORIDADE

• Alguns requisitos são mais urgentes que outros

• É essencial determinar a prioridade dos requisitos junto ao cliente

• Requisitos de maior prioridade são considerados em primeiro lugar

(122)

Elicitação de Requisitos – Análise

• ATRIBUIÇÃO DE PRIORIDADE

• Requisitos podem ser vistos em três classes distintas.

• Essenciais.

• Importantes.

• Desejáveis.

• Em princípio, sistema deve resolver todos os requisitos de essenciais para desejáveis.

(123)

Elicitação de Requisitos – Análise

• ATRIBUIÇÃO DE PRIORIDADE - EXEMPLO

• [RF001] Consulta X ao B.D. deve retornar dados A, B, C

• Prioridade: Essencial

• [RNF001] Consulta X ao B.D. deve visualizar dados segundo padrão Y

• Prioridade: Importante

• [RNF010] Consulta X ao B.D. deve usar cores azuis nos resultados

(124)

Elicitação de Requisitos – Análise

• VALIDAÇÃO DOS REQUISITOS

• Será que realmente entendi o que o cliente deseja?

• Devo me certificar de que não houve falha em nossa interação (comunicação).

(125)

Elicitação de Requisitos – Análise

• VALIDAÇÃO DOS REQUISITOS

• Demonstrar que os requisitos definem o sistema que o cliente realmente deseja.

• Custos com erros de requisitos são altos.

• Consertar um erro de requisitos após entrega do sistema pode custar mais de 100 vezes o custo de um erro de implementação.

(126)

Elicitação de Requisitos – Análise

• VALIDAÇÃO DOS REQUISITOS - TÉCNICAS

• Revisões de Requisitos

• Análise manual sistemática dos requisitos

• Prototipação

• Uso de modelo executável do sistema para avaliar requisitos

• Geração de Casos de Teste

• Desenvolver testes específicos para os requisitos para avaliá-los

• Análise de Consistência Automática

(127)

Elicitação de Requisitos – Análise

• DOCUMENTAÇÃO DOS REQUISITOS

1. Introdução

2. Definição dos Requisitos do Usuário

3. Especificação dos Requisitos do Sistema

4. Arquitetura do Sistema

5. Modelos do Sistema

6. Evolução do Sistema

7. Apêndices

(128)

Elicitação de Requisitos – Análise

• DOCUMENTAÇÃO DOS REQUISITOS

1. Introdução

I. Propósito do documento

II. Escopo do sistema

III. Glossário, acrônimos e abreviaturas

IV. Referências

V. Descrição do resto do documento

(129)

Elicitação de Requisitos – Análise

• DOCUMENTAÇÃO DOS REQUISITOS

2. Descrição geral

I. Perspectiva do produto

II. Funções do produto

III. Características dos usuários

IV. Restrições gerais

V. Assertivas e dependências

(130)

Elicitação de Requisitos – Análise

• DOCUMENTAÇÃO DOS REQUISITOS

3. Requisitos específicos

• Requisitos Funcionais,

• Requisitos Não-funcionais

• GUI com o usuário: funcionalidade, interfaces externas, desempenho, restrições, atributos do sistema, caract. qualidade, ...

(131)

Elicitação de Requisitos – Análise

• DOCUMENTAÇÃO DOS REQUISITOS

4. 4. Arquitetura do Sistema

5. 5. Modelos do Sistema

I. Diagrama de Atores

II. Modelo de Caso de Uso

III. Modelo de Análise

IV. Modelo de Projeto

V. Diagrama de Pacotes

6. 6. Evolução do Sistema (Futuro)

7. 7. Apêndices

8. 8. Índice

(132)

Elicitação de Requisitos – Análise

Abrev. Significado Explicação / Condição ou situação no sistema

A Administrador Usuário com maiores privilégios no sistema

AT Auto-treinamento Um dos três perfis de avaliação. O operador/treinando solicita ao sistema uma avaliação que lhe é montada de modo randômico a partir de alguns parâmetros

CT Certificação

Técnica Um dos três perfis de avaliação. Os supervisores (RL/RS) agendam com antecedência dia ehora da avaliação. É o teste que certifica o treinando/operador.

O Operador Usuário. Treinando que realiza as avaliações. RL Responsável

Local Usuário. Responsável, na unidade da empresa, por um grupo de operadores. Propõe, eliminae valida questões e avaliações. RS Responsável

Setorial Usuário. Responsável por um setor da empresa. Coordena um ou mais RL. Propõe, elimina evalida questões e avaliações. TO Treinamento

Orientado Um dos três perfis de avaliação. Serve para os RS/RL diagnosticarem o estágio daaprendizagem dos operadores. V Validador Usuário. Checa e valida as questões propostas pelos RS/RL.

M Módulo Refere-se aos módulos do sistema.

Backup Refere-se à cópia de dados de um dispositivo para o outro com o objetivo de posteriormente os recuperar (os dados), caso haja algum problema.

Logon É a ação necessária para acessar um sistema computacional restrito inserindo uma identificação, podendo esta ser ou não única para cada usuário, e a senha relacionada a ela. Uma vez logado, o usuário passa a ser identificado no sistema, sendo restringido ou permitido a acessar recursos do sistema.

(133)

Problema da Análise de Requisitos

• Stakeholders em geral não sabem o que

querem

• Stakeholders expressam requisitos em sua

terminologia

• Stakeholders diferentes podem gerar requisitos

conflitantes

(134)

Problema da Análise de Requisitos

• Fatores

políticos

e organizacionais

podem

influenciar os requisitos do sistema

• Requisitos mudam durante o processo de

análise. Stakeholders novos podem surgir e o

ambiente de trabalho muda

(135)

Gerenciamento de Requisitos

• Gerenciamento de requisitos é o processo de

controlar as mudanças dos requisitos durante

• O processo da engenharia de requisitos

(136)

Gerenciamento de Requisitos

• Requisitos são inevitavelmente incompletos e

inconsistentes

• Requisitos novos surgem durante o processo de acordo com mudanças nas necessidades do negócio e um entendimento melhor do sistema é desenvolvido

• Diferentes pontos de vista têm diferentes requisitos e esses geralmente são contraditórios

(137)

Rastreamento de Requisitos

• Responsável

por

dependências

entre

requisitos, suas origens e projeto do sistema

• Rastreamento de Origem

• Associação entre requisitos e stakeholders que propuseram tais requisitos

(138)

Rastreamento de Requisitos

• Rastreamento de Requisitos

• Associação entre requisitos dependentes

• Rastreamento de Projeto

• Associação dos requisitos com o projeto

• Usar hipertexto ou referência cruzada

(139)

1. Rastrear requisitos do usuário nos do Sistema.

2. Rastrear requisitos no projeto.

3. Rastrear requisitos nos procedimentos de teste.

4. Rastrear requisitos do usuário no plano

Projeto

Modelos Suítes Teste Teste 2 ₃ Req A 1 Requisitos Produto (Caracter.) Requisitos Detalhados (Casos de Uso) Req B Plano Doc. Usuário 4

Rastreamento de Requisitos

(140)

 Links dos requisitos devem ser marcados como “revisar”

 Links “revisar” devem ser analisados

Req A antes

“if return value > $5” Req B

Req C

“if return value > $2”

Req A depois

Req C Req B

(141)