Thanks to visit codestin.com
Credit goes to pt.scribd.com

0% acharam este documento útil (0 voto)
1K visualizações14 páginas

Elicitacao

Matéria da Alindacir
Direitos autorais
© Attribution Non-Commercial (BY-NC)
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato PDF, TXT ou leia on-line no Scribd
0% acharam este documento útil (0 voto)
1K visualizações14 páginas

Elicitacao

Matéria da Alindacir
Direitos autorais
© Attribution Non-Commercial (BY-NC)
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato PDF, TXT ou leia on-line no Scribd
Você está na página 1/ 14

Objetivos

◆ Descrever o processo da elicitação e análise


requisitos.
Elicitação e Análise de ◆ Introduzir um número de técnicas elicitação de
requisitos e análise de requisitos.
Requisitos ◆ Discutir como protótipos podem ser usados no
processo de ER.

DI - UNISC Slide 1 DI - UNISC Slide 2

Uma caso real! ELICITAÇÃO DE REQUISITOS MOTIVAÇÃO

... Quatro Meses Depois ...


◆ O Sistema que queremos deve fazer isto, isto
◆ Srs. Usuários, após o emprego das mais
..., e nesse caso também isto;
modernas técnicas de especificação,
◆ Sim, Sim estou anotando; produzimos este documento que descreve
◆ Conversei com os usuários e basicamente este minuciosamente o Sistema;
é o Sistema que teremos que desenvolver; ◆ Ótimo! Bom! Hum! ... é um documento com
◆ Sim chefe; 300 páginas e todos estes gráficos, tabelas.
◆ Ótimo, começaremos a especificar os Enfim, vamos analisá-lo e voltamos a falar;
requisitos imediatamente;

DI - UNISC Slide 3 DI - UNISC Slide 4


ELICITAÇÃO DE REQUISITOS MOTIVAÇÃO Componentes da elicitação de requisitos

... Depois de um mês e meio ...


◆ Sr. Analista, nosso pessoal analisou com
cuidado o documento. Tivemos muita
dificuldade e dúvidas em entendê-lo. Mas o
que percebemos é que NÃO FOMOS
Application Problem to be
CORRETAMENTE ENTENDIDOS!!! domain solved
◆ Como não? Tudo que aí está, foi fruto de nosso
entendimento pessoal. REALMENTE VOCÊS
NÃO SABEM O QUE QUEREM!!! Stakeholder Business
needs and context
constraints

DI - UNISC Slide 5 DI - UNISC Slide 6

Elicitação de Requisitos Elicitação de Requisitos: Dificuldades

◆ Usuários podem não ter uma idéia precisa do sistema


por eles requerido;
◆ ELICITAR: descobrir, tornar explícito, obter o
máximo de informações para o conhecimento do ◆ Usuários têm dificuldades para descreverem seu
objeto em questão conhecimento sobre o domínio do problema;
◆ Cabe à elicitação a tarefa de identificar os fatos ◆ Usuários e Analistas têm diferentes pontos de vista
que compõem os requisitos do Sistema, de forma do problema (por terem diferentes formações);
a prover o mais correto e mais completo ◆ Usuários podem antipatizar-se com o novo sistema e
entendimento do que é demandado daquele se negarem a participar da elicitação (ou mesmo
software fornecer informações errôneas).

DI - UNISC Slide 7 DI - UNISC Slide 8


Atividades da Elicitação Elicitação, análise e negociação
◆ Entendimento do domínio da aplicação Draft
• O conhecimento do domínio da aplicação é o conhecimento statement of
requirements
geral onde o sistema será aplicado.
Requirements
◆ Entendimento do problema elicitation Requirements
analysis
• Os detalhes dos problemas específicos do problema do
cliente onde o sistema será aplicado deve ser entendido.
◆ Entendimento do negócio
• Você de entender como os sistemas interagem e contribuem
de forma geral com os objetivos de negócio.
◆ Entendimento das necessidades e limitações dos
Requirements
stakeholders do sistema Requirements problems
document
Requirements
negotiation
DI - UNISC Slide 9 DI - UNISC Slide 10

Processo da elicitação de requisitos Estágios da Elicitação


◆ Definir objetivos
Establish objectives Understand background Organise knowledge Collect requirements • Os objetivos organizacionais devem ser estabelecidos incluindo
objetivos gerais do negócio, um descrição geral do problema a ser
resolvidos porque o sistema é necessário e as limitações do sistema.
Business Organisational Stakeholder Stakeholder
goals structure identification requirements ◆ Aquisição de conhecimento do background
• Informação de background do sistema inclui informação acerca da
Goal Domain organização onde o sistema será instalado, o domínio de aplicação do
Problem to be Application prioritisation requirements
solved domain sistema e informação acerca de outros sistemas existente

Domain
◆ Organização do conhecimento
System Existing Organisational
constraints systems
knowledge requirements • A grande quantidade de conhecimento que foi coletada nos estágios
filtering anteriores devem ser organizadas e colocadas em ordem.
◆ Coletar os requisitos dos stakeholders
• Os stakeholders do sistema são consultados para descoberta de seus
requisitos.

DI - UNISC Slide 11 DI - UNISC Slide 12


Análise e negociação de requisitos Cheques da análise
◆ Checagem da necessidade
Requ irements analysis
• A necessidade os requisitos é analisada. Em alguns casos, alguns
requisitos propostos podem não contribuir para os objetivos de
Necessity Consistency and Feasibility
completeness negócio da organização ou para o problema específico tratado pelo
checking checking
checking sistema.
◆ Checagem de consistência e completude
Conflicting and • Os requisitos são checados entre si para determinar consistência e
Unnecessary incomplete Infeasible
requirements requirements completude. Consistência significa que nenhum requisito deve ser
requirements contraditório; completude significa que nenhum serviço (ou limitação)
que seja necessário foi esquecido.
◆ Checagem de viabilidade
Requirements Requirements Requirements
discussion prioritisation agreement • Os requisitos são checados para garantir que são viáveis dentro do
orçamento e tempo disponível para o desenvolvimento do sistema.

Requ irements negotiation


DI - UNISC Slide 13 DI - UNISC Slide 14

Negociação dos requisitos Técnicas de Elicitação


◆ Discutir os requisitos ◆ Técnicas especiais que podem ser usadas para coletar
• Os requisitos que foram identificados como problemáticos conhecimento sobre os requisitos dos usuários
são discutidos e os stakeholders envolvidos apresentam ◆ Este conhecimento deve ser estruturado
seus pontos de vista a cerca dos requisitos.
• Particionamento - agregando conhecimentos relacionados
◆ Priorizar os requisitos • Abstração - reconhecendo generalidades
• Os requisitos disputados são priorizados para identificar • Projeção - organizando de acordo com a perspectiva
requisitos críticos e ajudar a processo de tomada de
decisão. ◆ Problemas da elicitação
◆ Concordância dos requisitos • Não existir muito tempo para a elicitação
• Soluções para os problemas dos requisitos são • Preparação inadequada dos engenheiros
identificadas e um conjunto de requisitos são acordados. • Stakeholders não estarem convencidos da necessidade de
Geralmente isto envolve mudanças em alguns dos um novo sistema
requisitos.
DI - UNISC Slide 15 DI - UNISC Slide 16
Técnicas de elicitação Elicitação de Requisitos
◆ Entrevista ◆ O profissional de ER deve selecionar as técnicas a
◆ Leitura de documentos serem utilizadas e estabelecer de que maneira elas
serão integradas
◆ Questionários
◆ É importante utilizar uma técnica de modelagem de
◆ Análise de protocolos apoio para que os fatos elicitados fiquem
◆ Participação ativa dos usuários corretamente representados para futuro tratamento
◆ Cenários ◆ A escolha das técnicas e seu esquema de integração
dependerá do problema e da equipe participante
◆ Métodos Soft Systems
◆ O ponto importante é ter conhecimento sobre estas
◆ Observações e análise sociais técnicas e identificar onde uma técnica é superior a
◆ Reuso de requisitos outra

DI - UNISC Slide 17 DI - UNISC Slide 18

Técnicas específicas de elicitação Entrevistas


◆ O engenheiro de requisitos ou analista discute o
sistema com diferentes stakeholders e obtêm um
entendimento dos requisitos.
◆ Vantagens: contato direto com o usuário e validação
imediata
◆ Desvantagens: conhecimento tácito e diferenças de
cultura

DI - UNISC Slide 19 DI - UNISC Slide 20


Entrevistas: tipos Essencial das entrevistas
◆ Entrevistadores devem estar de “cabeça aberta” e não
◆ Entrevistas fechadas. O engenheiro de requisitos fazer a entrevista com noções pré-concebidas sobre o
busca respostas para um conjunto de questões pré- que é necessário
definidas ◆ Informar aos stakeholders o ponto inicial da discussão.
◆ Entrevistas abertas. Não há uma agenda pré-definida e Isto pode ser uma questão, uma proposta de requisitos
o engenheiro de requisitos discute, de forma aberta, o ou um sistema existente
que o stakeholders quer do sistema. ◆ Entrevistadores devem estar cientes da política
◆ Tutorial: o cliente está no comando - aula organizacional - muitos requisitos reais podem não
serem discutidos devido as implicações políticas

DI - UNISC Slide 21 DI - UNISC Slide 22

Leitura de Documentos Questionários


◆ Quando existe conhecimento sobre o problema e
◆ Abstrações grande número de clientes
◆ Vocabulário da aplicação ◆ Dão idéia definida sobre como certos aspectos
◆ Vantagens: facilidade de acesso e volume de universo de informação/software são percebidos
informações ◆ Possibilitam análises estatísticas
◆ Desvantagens: dispersão das informações e volume de ◆ Vantagens: padronização das perguntas e tratamento
trabalho estatístico das respostas
◆ Desvantagens: limitação do universo de respostas e
pouca iteração

DI - UNISC Slide 23 DI - UNISC Slide 24


Análise de Protocolos Participação Ativa dos Usuários

◆ Consiste em analisar o trabalho de determinada ◆ Incorporação dos usuários ao grupo de ER


pessoa através de verbalização ◆ Os usuários precisam aprender as linguagens de
◆ Objetivo: estabelecer a racionalidade utilizada na modelagem utilizadas para ler as descrições e
execução de tarefas criticá-las
◆ Vantagens: possibilidade de elicitar fatos não ◆ Integração dos usuários com os ER na
facilmente observáveis e permitir melhor modelagem do sistema
entendimento dos fatos ◆ Vantagens: envolvimento dos clientes e usuários
◆ Desvantagens: desempenho do entrevistado e “o ◆ Desvantagens: treinamento dos usuários e falsa
que se diz é diferente do que se faz” impressão da eficácia do sistema

DI - UNISC Slide 25 DI - UNISC Slide 26

Cenários Cenário da biblioteca-pedido de documentos


◆ Cenários são estórias que explicam como um sistema poderá ◆ Entre no sistema EDDIS
ser usado. Eles devem incluir:
• uma descrição do estado do sistema antes de começar o cenário
◆ Escolha o comando pedido de documentos
• o fluxo normal de eventos do cenário ◆ Entre um número de referência do documento pedido
• exceções ao fluxo normal de eventos ◆ Selecione um ponto de entrega
• informações sobre atividades concorrentes
• uma descrição do estado do sistema ao final do cenário ◆ Saia do sistema EDDIS
◆ Cenários são exemplos de sessões de interação que descrevem ◆ Esta sequência de eventos pode ser ilustrada num
como o usuário interage com o sistema diagrama
◆ A descoberta de cenários expõe interações possíveis do sistema
e revela as facilidades que o sistema pode precisar

DI - UNISC Slide 27 DI - UNISC Slide 28


Cenário da biblioteca Cenários e Projeto OO
Operational terminal
◆ Cenários são partes inerentes de alguns métodos de
Login OK desenvolvimento orientados a objeto
Order accepted
User id
Login to Document reference OK ◆ O termo “caso de uso” ou use-case (um caso
EDDIS
Passwd Select order
document Input document
Delivery confirmed
específico do uso do sistema) é usado as vezes para se
Exceptions reference
Invalid id or Exceptions
Confirm referir a um cenário
delivery details Logout from
password Exceptions
Login retry
Permission denied
Incorrect
EDDIS ◆ Existem diferentes visões sobre o relacionamento
Enter help system
reference
Input doc. Exceptions entre caso de uso e cenários :
reference Timeout
• Um caso de uso é um cenário
Enter help system Auto-logout
• Um cenário é uma coleção de casos de uso. Portanto, cada
interação excepcional é representada como um caso de uso
separado
DI - UNISC Slide 29 DI - UNISC Slide 30

Métodos Soft Systems Estágios do SSM


◆ Produzem modelos informais de um sistema técnico- ◆ Avaliação da situação do problema
social. Eles consideram o sistema, as pessoas e a ◆ Descrição da situação do problema
organização.
◆ Definição abstrata do sistema a partir de pontos de
◆ Não são técnicas para elicitação detalhada de
requisitos. Servem para o entendimento do problema e vistas selecionados
de seu contexto organizacional. ◆ Modelagem conceitual do sistema
◆ A técnica mais conhecida é provavelmente a ◆ Comparação do modelo e mundo real
Software Systems Methodology (SSM) ◆ Identificação de mudança
◆ A essência do SSM é o reconhecimento que sistemas
são embutidos num contexto maior que envolve seres ◆ Recomendações para ação
humanos e organização

DI - UNISC Slide 31 DI - UNISC Slide 32


Observação e Análise Social Diretrizes para Etnografia
◆ As pessoas geralmente acham difícil descrever o que elas fazem ◆ Assuma que as pessoas são boas no que fazem e
pois isto é muito natural para elas. As vezes, a melhor forma procure formas não padronizadas de trabalho
de entende será observá-las no trabalho. ◆ Gaste algum tempo conhecendo as pessoas e
◆ Etnografia é uma técnica das ciências sociais que se mostrou estabeleça um relacionamento de confiança
útil no entendimento das processos reais realizados nos
trabalhos
◆ Tome nota de forma detalhada de todas as práticas de
trabalho. Analise-as e chegue a uma conclusão a partir
◆ Os processo reais de trabalho geralmente diferem daqueles
delas
processos formais descritos
◆ Um etnógrafo passa algum tempo observando as pessoas no
◆ Combine observação com entrevistas abertas
trabalho e constrói uma imagem de como o trabalho é realizado ◆ Organize regularmente seções de relato, onde o
etnógrafo fale para pessoas externas ao processo
◆ Combine etnografia com outras técnicas de elicitação
DI - UNISC Slide 33 DI - UNISC Slide 34

Etnografia Etnografia na elicitação


◆ Etnográfo procura ter a mesma perspectiva do cliente
◆ Vantagem: visão mais completa e perfeitamente
ajustada ao contexto Ethnographic De briefing Focused
analysis meetings ethnography
◆ Desvantagem: tempo gasto e pouca sistematização do
processo
System System
protoyping prototype

User
experiments

DI - UNISC Slide 35 DI - UNISC Slide 36


Perspectivas da etnografia Reuso de requisitos
◆ O ponto de vista do ambiente de trabalho ◆ Reuso envolve considerar requisitos que foram
• Descreve o contexto e localização física do trabalho e como as pessoas desenvolvidos para um sistema e usá-los em sistemas
usam objetos para executarem tarefas. Assim, no caso de um serviço
de help desk, seriam descritos os objetos que o funcionário precisaria diferentes
manusear e como eles estão organizados
◆ O reuso de requisitos economiza tempo e esforço, pois
◆ Perspectiva social e organizacional requisitos reutilizados já foram analisados e validados
• Tentar levantar a experiência diária do trabalho, de acordo com as
diferentes pessoas envolvidas. Cada indivíduo tipicamente vê o em outros sistemas
trabalho de forma diferente. Assim este ponto de vista tenta ◆ Atualmente o reuso de requisitos é um processo
organizar e integrar todas estas percepções.
informal. Contudo, um reuso mais sistemático
◆ Ponto de vista de fluxo de trabalho
• Este ponto de vista apresenta o trabalho a partir de um série de
economizaria muito esforço
atividades com informações fluindo de uma atividade para outra.

DI - UNISC Slide 37 DI - UNISC Slide 38

Possibilidades de reuso Reuso


◆ É justamente a capacidade de se aproveitar análises
◆ Na existência de um domínio (encapsulamento do anteriores que diferencia um analista experiente de um
conhecimento da área de aplicação) do qual o inexperiente
requisito está relacionado ◆ Vantagens: produtividade e qualidade (componentes já
• Na mesma área de aplicação, apenas 15% dos validados)
requisitos de um novo sistema são exclusivos dele. O
restante são os mesmos de outros sistemas similares ◆ Desvantagens: dificuldade de se promover reutilização
◆ Na apresentação da informação. O reuso levaria sem modificação
a consistência dos estilos entre aplicações.
◆ Onde o requisito refletir políticas da companhia,
tais como segurança.

DI - UNISC Slide 39 DI - UNISC Slide 40


Prototipagem Benefícios da prototipagem
◆ Um protótipo é uma versão inicial de um sistema que ◆ O protótipo permite que os usuários experimentem e
poderá ser usado para experimentação. descubram o que eles realmente necessitam para
suportar o trabalho deles
◆ Protótipos são úteis para elicitação de requisitos
porque os usuários poderão experimentar com o ◆ Estabelece a viabilidade e utilidade antes que altos
custos de desenvolvimento tenha sido realizado
sistema e mostrar os pontes fortes e fracos do sistema.
Eles terão algo concreto para criticar. ◆ Essencial para desenvolvimento do aspecto ‘look and
feel’ da interface do usuário
◆ O desenvolvimento rápido dos protótipos é essencial
◆ Pode ser usado para teste do sistema e
para que eles fiquem disponíveis logo para o processo desenvolvimento da documentação
de elicitação . ◆ Força um estudo detalhado dos requisitos que revela
inconsistências e omissões
DI - UNISC Slide 41 DI - UNISC Slide 42

Tipos de prototipagem Custos e problemas da protipagem


◆ Prototipagem descartável ◆ Custos de treinamento - o desenvolvimento de
• Útil para ajudar a elicitação e desenvolvimento dos requisitos. protótipos pode requerer o uso de ferramentas de
• Os requisitos que devem ser prototipados devem ser aqueles que propósito especial
causam mais dificuldades para os clientes e que são mais difíceis de
entender. Requisitos que são bem entendidos não precisam ser ◆ Custos de desenvolvimento - depende do tipo de
implementados pelo protótipo. protótipo sendo desenvolvido
◆ Prototipagem evolucionária ◆ Extensão dos prazos de desenvolvimento -
• Tem como objetivo a entrega rápida de um sistema que funciona para desenvolver um protótipo pode estender o prazo,
o cliente. embora o tempo de prototipagem possa ser recuperado
• Assim, os requisitos que devem ser suportados pela versão inicial do
protótipo, são aqueles que estão bem entendidos e que podem prover
pois o trabalho de correção de erros possa ser evitado
funcionalidade ao usuário final. Somente após largo uso do sistema é ◆ Incompletudo - pode não ser possível prototipar os
que requisitos que foram pouco entendidos deverão ser implementados requisitos críticos do sistema

DI - UNISC Slide 43 DI - UNISC Slide 44


Abordagem para prototipagem Desenvolvimento de um protótipo executável

◆ Prototipagem no papel ◆ Linguagem de quarta geração em volta de um sistema


• uma simulação do sistema é desenvolvida em papel e de banco de dados
usada para experimentação do sistema ◆ Linguagem de programação visual tais como Visual
◆ Prototipação ‘Mágico de Oz’ Basic ou ObjectWorks
• uma pessoa simula as respostas do sistema em resposta a ◆ Soluções de prototipagem para internet baseadas em
alguma entrada do usuário
algum folheador (browsers) para World Wide Web e
◆ Prototipagem executável linguagens tais como Java
• uma linguagem de quarta geração ou um ambiente de
prototipagem rápida é usada para o desenvolvimento de
um protótipo executável

DI - UNISC Slide 45 DI - UNISC Slide 46

Análise de requisitos Lista de verificação da análise


◆ O objetivo da análise é descobrir problemas, ◆ Projeto prematuro
incompletude e inconsistência nos requisitos • Os requisitos incluem informação prematura de projeto ou
implementação?
elicitados. Eles normalmente são retornados aos
◆ Requisitos combinados
stakeholders para resolvê-los através de um processo • A descrição dos requisitos descreve um requisito único ou pode ser
de negociação descritos em vários requisitos diferentes?
◆ A análise é intercalada com elicitação pois problemas ◆ Requisitos desnecessários
são descobertos quando os requisitos são elicitados • O requisito é realmente necessária, ou será que é uma mera adição
cosmética ao sistema?
◆ Uma lista de verificação de problemas poderá ser ◆ Uso de hardware não padronizado
usada para ajudar a análise. Cada requisito poderá ser • Os requisitos implicam no uso de uma plataforma de hardware não
avaliado contra esta lista padronizada? Para tomar esta decisão, você precisa conhecer os
requisitos de plataforma do computador.

DI - UNISC Slide 47 DI - UNISC Slide 48


Lista de verificação da análise Interação de requisitos
◆ Um importante objetivo da análise de requisitos é
◆ Está de acordo com os objetivos de negócio
• O requisito é consistente com os objetivos de negócio definidos na
descobrir as interações entre requisitos e informar as
introdução do documento de requisitos? conflitos e sobreposições de requisitos
◆ Ambiguidade de requisitos ◆ Uma matriz de interação de requisitos mostrará como
• O requisito é ambíguo, isto poderá ser lido de forma diferente por
pessoas diferentes? Quais são as possibilidades de interpretação um requisito interage com outros. Os requisitos são
dos requisitos? mostrados nas linhas e colunas da matriz
◆ Realismo dos requisitos
• Para cada requisito que conflita, preencha 1
• É o requisito realístico em relação a tecnologia usada para a
implementação do sistema? • Para cada requisito que sobrepõe-se, preencha 1000
◆ Teste dos requisitos • Para cada requisito que é independente, preencha um 0
• Podemos testar os requisitos, ou seja, eles foram escritos de tal
forma que um engenheiro de teste poderá derivar o teste que
mostrará se o sistema satisfaz os requisitos?
DI - UNISC Slide 49 DI - UNISC Slide 50

Matizes de Interação Negociação de requisitos


◆ Problemas nos requisitos são inevitáveis quando um
sistema possui muitos stakeholders. Conflitos não são
falhas mas refletem necessidades e prioridades
Requi rement R1 R2 R3 R4 R5 R6
R1 0 0 1000 0 1 1 diferentes entre as partes interessadas
R2 0 0 0 0 0 0
R3 1000 0 0 1000 0 1000
◆ A negociação de requisitos é o processo de discussão
R4 0 0 1000 0 1 1 dos conflitos de requisitos e busca de um
R5 1 0 0 1 0 0
R6 1 0 1000 1 0 0
compromisso no qual todas as partes interessadas
concordem
◆ No planejamento do processo de engenharia de
requisitos, é importante deixar bastante tempo para
negociação. Alcançar um compromisso aceitável pode
tomar um tempo considerável
DI - UNISC Slide 51 DI - UNISC Slide 52
Encontros de negociação Pontos chave
◆ Um estágio de informação onde a natureza dos problemas
associados com os requisitos são explicados. ◆ A elicitação de requisitos envolve a compreensão do
◆ Um estágio de discussão onde as partes interessadas discutem domínio da aplicação, o problema específico a ser
com o problema poderá ser resolvido. resolvido, as necessidades e limitações organizacionais e
• Todas as partes interessadas no requisito devem ter a oportunidade de
as facilidades especificas necessárias para as partes
comentar. Neste estágio atribuir prioridades aos requisitos. interessadas.
◆ Estágio de resolução onde as ações que dizem respeito ao ◆ Os processos de elicitação de requisitos, análise e
negociação são interativos e intercalados, precisando
requisito são concordadas.
serem repetidos várias vezes.
• Estas ações podem ser deletar o requisito, sugerir modificações ao
requisito ou elicitar mais informações sobre o requisito. ◆ Existem várias técnicas de elicitação de requisitos que
podem ser usadas, incluindo entrevistas, cenários,
métodos soft systems, prototipagem e observação dos
participantes.

DI - UNISC Slide 53 DI - UNISC Slide 54

Pontos chave

◆ Protótipos são efetivos para a elicitaçãod de requisitos


pois as partes interessadas têm algo para experimentar e
encontrar seus reais requisitos.
◆ Listas de checagem são formas particularmente úteis para
organizar o processo de validação dos requisitos. Elas
lembram ao analista o que deve ser checado quando da
leitura dos requisitos propostos.
◆ Negociação dos requisitos é sempre necessário para
resolver conflitos e remover a sobreposição de requisitos.
Negociação envolve a troca de informação, discussão e
resolução de conflitos.

DI - UNISC Slide 55

Você também pode gostar