O que é qualidade de software

Para definirmos qualidade de software vamos começar com uma definição de qualidade de uma forma mais geral indicada por Pressman (2011, p. 359):

Qualidade é um conceito complexo e multifacetado que pode ser descrito segundo cinco pontos de vista diferentes:

• A visão transcendental sustenta que qualidade é algo que se reconhece imediatamente, mas não se consegue definir explicitamente.
• A visão do usuário dimensiona a qualidade em termos de metas específicas de um usuário final. Se um produto atende a essas metas, ele apresenta qualidade.
• A visão do fabricante define qualidade em termos da especificação original do produto. Se o produto atende às especificações, ele tem qualidade.
• A visão do produto sugere que a qualidade pode ser ligada a características inerentes (por exemplo função e recursos) de um produto.
• A visão baseada em valor mede a qualidade tomando como base o quanto um cliente estaria disposto a pagar por um produto.

Mas... na realidade, qualidade engloba todas essas visões e outras mais. (PRESSMAN, 2011, p. 359).

Há, ainda, diversas outras definições de qualidade de software. Vamos considerar as principais delas:

Norma ISO/IEC 9126 (1991)

Fonte: <www.iec.ch> e <worldvectorlogo.com>.

• De acordo com o glossário padrão de terminologia em Engenharia de Software do IEEE 610.12 (1990) (disponível em: <standards.ieee.org>), qualidade pode ser definida como “o grau no qual um sistema, componente, ou processo atende aos requisitos especificados e às necessidades ou expectativas do cliente ou usuário”.
• A norma ISO/IEC 9126 (1991) define qualidade como “a totalidade de funcionalidades e características de um produto ou serviço que atendem à sua capacidade de satisfazer necessidades específicas ou implícitas”. Além disso, o padrão identifica seis atributos fundamentais de qualidade que um produto de software deve atender: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.

• No contexto de desenvolvimento de software, qualidade
  

  [...] é o resultado de um bom gerenciamento de projeto e uma prática consistente de Engenharia de Software. O gerenciamento e a prática são aplicados no contexto de quatro grandes atividades que ajudam uma equipe de software a atingir alto padrão de qualidade de software: métodos de engenharia de software, técnicas de gerenciamento de projetos, ações de controle de qualidade e garantia da qualidade de software. (PRESSMAN, 2011; p. 370, grifo nosso).

O termo qualidade pode assumir diferentes significados, em função de estar ligado à percepção das pessoas, que têm gostos e formas de pensar distintos. Isso pode nos permitir concluir que a definição de qualidade de software também esteja ligada à percepção subjetiva dos seres humanos. Desta forma, a qualidade de software, assim como a qualidade de outros produtos, está sujeita à opinião das pessoas que, neste caso, assumem o papel de clientes, usuários e demais envolvidos com o projeto do software.

No entanto, ainda não há regras definitivas que indiquem claramente como desenvolver produtos de software de qualidade, embora a qualidade do produto seja considerada fortemente dependente da qualidade e adequação de seu processo de desenvolvimento. Mas podemos elencar as seguintes características para a qualidade de software:

• Está fortemente relacionada à conformidade com os requisitos.
• Caracteriza o grau de satisfação do cliente.
• Não é responsabilidade de apenas uma área da empresa, e sim de todos.
• Deve estar presente desde o planejamento do software.

Guia PMBOK

Fonte: <mefair.com >.

Além disto, a qualidade deve satisfazer um conjunto de diferentes pontos de vista:

• Usuário:
• Qualidade consiste na capacidade de satisfazer desejos.
• Qualidade é a adequação ao uso.
• Valor:
• Qualidade é o grau de excelência a um preço aceitável e o controle da variabilidade a um custo aceitável.
• Entrega:
• Um produto ou serviço produzido de acordo com as especificações, com custo competitivo, mas entregue fora do prazo, pode ser considerado de qualidade?

As empresas de desenvolvimento de software vêm valorizando bastante a qualidade dos sistemas e aplicações, pois tornou-se claro que os gastos com qualidade não são um dispêndio financeiro, mas um importante investimento. Além disso, os clientes estão cada vez mais exigentes, o que também exige dos desenvolvedores muito mais cuidado na criação dos produtos de software.

Saiba mais

Modelo de Qualidade no Contexto SPB – Software Público Brasileiro

“A Qualidade de Produto de Software está passando por uma evolução, antes estava ligada à funcionalidade e agora está ligada à confiabilidade.A Qualidade de um Produto de Software pode ser percebida por várias visões, como:

• Pela visão do desenvolvedor.
• Pela visão do responsável pelo desenvolvimento.
• Pela visão do usuário final.

Para o usuário final, o interesse está, por exemplo, na utilização, no desempenho, ou seja, em medidas externas de qualidade como:

• Funções específicas estão disponíveis?
• Qual é a confiabilidade do software e sua eficiência?
• É facil de usar?
• É facil para transferir para outro ambiente operacional?

Para o desenvolvedor, o interesse está na qualidade de produtos intermediários, ou seja, verificando, se estão coerentes com as expectativas do usuário final.

Para o responsável pelo desenvolvimento, o interesse está nos objetivos da comunidade, está em fazer o equilíbrio de melhoria de qualidade usando critérios como prazo e custo.

A definição de Qualidade de Produto de Software está baseada na definição de características de interesse em função da área de aplicação desse produto. De acordo com a área de aplicação do produto, certas características são mais desejáveis como:

• Para aplicações de missão critica, a confiabilidade.
• Para aplicações em tempo real, o desempenho.
• Para aplicações interativas com o usuário não especializado, a usabilidade.
• Para aplicações que mantêm informações sigilosas, a segurança.”

Fonte: CTI (2013).

Desenvolvimento de Casos de Uso

Na geração do documento preliminar dos requisitos extraídos em qualquer técnica, podem-se utilizar os diagramas de Caso de Uso da UML, que fornecem uma descrição de como o sistema será utilizado, através de cenários.

Essencialmente, um caso de uso conta uma história sobre como um usuário final (desempenhando diversos papéis) interage com o sistema sob um conjunto de situações diferentes. O primeiro passo ao se escrever um caso de uso é definir o conjunto de atores, que representam as diferentes pessoas ou dispositivos que usam o sistema no contexto.

Fonte: PRESSMAN (2011, p. 138)

De acordo com Pressman (2011, p. 138), o levantamento de requisitos é uma atividade evolucionária, portanto, nem todos os atores são identificados durante a primeira iteração. Atores primários são identificados na primeira iteração e atores secundários surgem quando mais conhecimento é obtido do sistema. Os atores primários trabalham de forma mais direta e frequente com o sistema e os secundários oferecem suporte ao sistema, de forma que os primários possam realizar o seu trabalho.

Booch, Rumbaugh e Jacobson (2006) sugerem diversas perguntas que podem ser respondidas por um caso de uso, dentre as quais se encontram:

• Há precondições que devem existir antes de uma história iniciar?
• Quem são os atores primários e secundários?
• Quais são os objetivos dos atores?
• Que tarefas ou funções são realizadas pelos atores?
• Que exceções devem ser consideradas à medida que a história se desenvolve?
• Quais são as possíveis variações na interação de cada ator?
• Que informações de sistema cada ator solicita, adquire, produz ou modifica?

Sommerville (2011, p. 74) afirma que o conjunto de casos de uso representa todas as possíveis interações que serão descritas nos requisitos de sistema. Os casos de uso identificam as interações individuais entre o sistema e seus usuários ou entre o sistema e outros sistemas. Cada caso de uso deve ser documentado com uma descrição textual e esta, por sua vez, pode ser ligada a outros diagramas da UML que desenvolverão o cenário com mais detalhes.

A figura apresenta os principais elementos de um diagrama de caso de uso da UML: ator (actor), caso de uso (use case), relacionamento (relationship) do tipo <<extend>> e <<include>>.

Elementos de um diagrama de caso de uso. Fonte: uml-diagrams.org (2016)

Caro aluno, as dicas que podemos lhe dar para quando você estiver tentando descobrir o que o seu cliente quer do seu novo software são:

• Em primeiro lugar, evite perguntar ao cliente o que ele quer que o novo sistema faça.
• Entenda, primeiro, como são atualmente os processos do seu cliente.
• Pergunte ao cliente quais processos que ele sabe que funcionam bem no sistema atual. Faça o cliente explicar porque ele acha que funcionam bem. Faça o mesmo com os processos que existem e funcionam mal.
• Descubra quais são os processos atuais que existem, mas que ninguém usa, e por que não são usados.
• Baseado nessas informações, utilize uma das técnicas de coleta de requisitos. Quanto mais claramente os requisitos puderem ser compreendidos pelo cliente, melhor. Por exemplo, se for um cliente da área técnica você poderá lhe mostrar os casos de uso ou usar diagramas mais técnicos. Se for um cliente de negócios, você vai precisar de algo mais visual, então faça desenhos ou crie um protótipo.
• Faça o cliente analisar seu protótipo ou sua lista, mesmo que seja difícil para ele. Procure estar sempre face a face com seu cliente.
• Assinale os requisitos com os quais o cliente concorda e aqueles com os quais ele discorda. Baseado nessas informações, descubra se ainda existem pontos do processo que você não entendeu corretamente.
• Refine e detalhe mais os requisitos. A partir daqui, o processo se repete até que o cliente concorde com a maioria dos requisitos do sistema. Ter 100% de concordância não é fácil, mas deve haver uma sensação de comprometimento e de entendimento entre você e seu cliente após esse processo.

Prototipação

Técnica que tem como objetivo extrair, entender e validar os requisitos. É baseada no conceito do processo de desenvolvimento de software de prototipação, já estudado anteriormente. Um protótipo do produto pode ser construído. Por meio do protótipo os usuários podem descobrir quais são as suas reais necessidades. É benéfica somente se o protótipo puder ser construído de forma mais rápida que o sistema real. É especialmente útil para superar dificuldades de comunicação de necessidades por parte dos usuários.

Etnografia

Etnografia é uma técnica de observação que pode ser utilizada para a compreensão de processos operacionais e ajudar na coleta de requisitos. A técnica inicia-se a partir da imersão de um engenheiro de software ou analista no ambiente de trabalho em que o sistema será usado. Todas as tarefas reais que ocorrem na rotina de trabalho dos futuros usuários é observado e anotado.

Esta técnica ajuda no levantamento de requisitos implícitos do sistema que refletem o trabalho real realizado pelas pessoas ao invés dos aspectos formais dos processos definidos pela organização. Além disso, fatores sociais e comportamentais que afetam o trabalho, e que não são notados pelos envolvidos, podem ser percebidos por um observador imparcial.

Caro aluno, as técnicas apresentadas visam superar as dificuldades inerentes ao processo de extração dos requisitos. Nenhuma técnica é suficiente por si só. Você, como desenvolvedor, deve escolher um conjunto de técnicas que melhor se adaptem ao produto a ser desenvolvido. Mas podemos elencar alguns procedimentos gerais que podem fazer parte de qualquer processo de coleta de requisitos e ajudá-lo neste processo:

• Você deve perguntar e identificar as pessoas apropriadas para responder quais são os requisitos.
• Você deve observar o comportamento dos usuários de um produto existente e inferir suas necessidades a partir de seu comportamento.
• Você deve discutir com os usuários suas necessidades e, junto com eles, formular um entendimento comum dos requisitos.
• É importante você negociar com os usuários, a partir de um conjunto-padrão de requisitos, quais serão incluídos, excluídos ou modificados.
• Você deve estudar e identificar os problemas; isso ajuda a identificar os requisitos que podem melhorar o produto.

5W1H

A técnica 5W1H é mundialmente difundida e utilizada em diversos tipos de situações, sendo muito útil na coleta de requisitos. A seguir conheceremos os 5 Ws e o único H, assim como algumas perguntas comumente aplicadas nestas fases.

Who (Quem) – refere-se às responsabilidades.

• Quem é o cliente/usuário do sistema?
• Quem executa?
• Quem gerencia?
• Quem fornece?
• Quem participa das decisões?

What (O Quê) – refere-se às etapas.

• Quais são as entradas do sistema?
• Quais são as saídas?
• Quais são os indicadores?
• Quais são as metas?
• Quais são os recursos?
• Quais são os problemas?
• Quais são os métodos/tecnologias empregados?
• Que informações ou insumos são necessários para o trabalho? Quem as fornece?
• Quais são as regras que determinam como o trabalho será feito?
• Há alguma coisa que possa parar, atrasar ou impedir o processo?
• Há espera para completar o processo?
• Quais são as exceções?
• Quais são as alternativas, caso o sistema não funcione conforme as expectativas?
• Qual ação é tomada quando uma etapa falha?

When (Quando) – refere-se ao tempo.  

• Quando é planejado o processo?
• Quando é executado?
• Quando é avaliado?
• Quanto tempo leva o processo?
• Com que frequência a atividade é executada?

Where (Onde) refere-se aos locais.    

• Onde é planejado o processo?
• Onde é executado?
• Onde é avaliado?

Why (Porque) – refere-se às justificativas.     

• Porque / para que esse processo existe?
• Quais são os fatores que determinam quando um produto é aceitável?

How (Como) – refere-se aos métodos.

• Como é planejado o processo?
• Como é executado?
• Como é avaliado?
• Como as informações são registradas e disseminadas?
• Como é avaliada a satisfação do cliente?
• Como são as medidas específicas associadas ao sistema, caso existam?

 

    

Técnica 5Ws e 1H. Fonte: elaborado pela autora

PIECES – Performance, Informação, Economia, Controle, Eficiência, Serviços

Técnica PIECES. Fonte: Sentavio/shutterstock

Quando o desenvolvedor inexperiente apresenta dificuldades em determinar como começar e o que perguntar para extrair os requisitos do cliente, é interessante utilizar a técnica PIECES, pois ela ajuda a resolver esse problema. A técnica fornece um conjunto de categorias de problemas que ajudam o engenheiro de requisitos a estruturar o processo de extração de requisitos. Em cada categoria existem várias questões que o desenvolvedor deve explorar com os usuários. Pode ser adaptada para domínios de aplicação específicos.

As seis categorias de questões são:

1. Performance: reflete o que usuário espera.
2. Informação (e dados): refere-se ao tipo de acesso às informações: relatórios, funções online; inclui a quantidade de informação oferecida pelo software: na medida certa, no tempo propício e em forma utilizável.
3. Economia: relaciona-se ao custo de usar um produto de software: processadores, armazenagem, conexões de rede etc.
4. Controle: inclui as restrições de acesso ao sistema, acesso a algumas informações e habilidade de monitorar o comportamento do sistema.
5. Eficiência: procura evitar coletar o mesmo dado mais de uma vez e armazená-lo em espaços múltiplos.
6. Serviços: refere-se a que tipo de serviços os usuários necessitam que o software realize.

Questionários

É uma forma rápida de se obter dados de uma grande quantidade de usuários que podem estar em lugares geograficamente distintos. Os tipos de dados que podem ser coletados por meio de questionários são:

• Dados sobre a utilização do sistema atual;
• Problemas e dificuldades que os usuários enfrentam em seu trabalho;
• Expectativa dos usuários em relação ao novo sistema.

As questões devem ser claras e objetivas. Deve-se preparar mais de uma questão para um tópico a fim de confirmar a resposta e deixá-la mais completa.

Os tipos de questões que compõem os questionários são:

• Abertas-dirigidas: Antecipam o tipo de resposta. Devem ser utilizadas quando não é possível ou não se devem criar alternativas. Por exemplo: “Por que você acha que os manuais do usuário do sistema financeiro não funcionam?”
• Fechadas: Utilizadas quando é possível listar as possíveis alternativas. Por exemplo: em “Os dados sobre vendas são entregues com que frequência?”, as alternativas podem ser: diariamente, semanalmente, quinzenalmente, mensalmente, trimestralmente.

Na elaboração do questionário, os seguintes cuidados devem ser tomados:

• Questões mais importantes devem vir primeiro.
• Questões com conteúdo semelhante e relacionadas devem estar próximas.
• Questões que podem gerar controvérsias devem ser deixadas para depois.

Brainstorming

É uma técnica básica para geração de ideias. Devem ser realizadas uma ou várias reuniões que permitam que as pessoas sugiram e explorem ideias sem que sejam criticadas ou julgadas. Deve existir um líder responsável por conduzir a reunião sem restringi-la. É especialmente útil no começo do processo de extração de requisitos. Mas apresenta uma desvantagem, já que não é uma técnica muito estruturada, pode não produzir a mesma qualidade ou nível de detalhe que se consegue com outras técnicas.

Brainstorming. Fonte: Ellagrin/shutterstock

O brainstorming (ou tempestade cerebral)
basicamente é dividido em duas etapas:

1. Geração das ideias:

São as reuniões que tem como objetivo fornecer ideias, sem discussões sobre o mérito delas. Existem quatro regras:

• É proibido criticar ideias.
• Ideias não convencionais ou estranhas são encorajadas.
• Número de ideias geradas deve ser bem grande.
• Os participantes devem ser encorajados a enriquecer as ideias dos outros participantes.

2. Consolidação das ideias:

As ideias geradas são discutidas, revisadas, organizadas, avaliadas, consolidadas, descartadas e priorizadas.

JAD – Joint Application Development

Técnica utilizada para promover a cooperação, o entendimento e o trabalho em grupo entre usuários e desenvolvedores. É baseada em quatro princípios:

• Dinâmica em grupo: utilização de sessões de grupo (encontros de usuários e desenvolvedores).
• Uso de técnicas visuais: utilização de data-show, projetor, vídeos etc.
• Manutenção do processo organizado e racional: controle da sessão por meio de um líder que tem o objetivo final de identificar um conjunto preliminar de requisitos.
• Utilização de documentação padrão: criação de um documento com os requisitos identificados.

Geralmente existem seis papéis (responsabilidades) divididos entre a equipe de desenvolvimento e usuários, que são: líder da sessão; engenheiro de requisitos; executor; representantes dos usuários; representantes de produtos de software; e especialistas.

Técnicas de Coleta de Requisitos

A coleta ou extração de requisitos é realizada por meio de técnicas, mas é essencialmente uma atividade que necessita de comunicação. Para que o que o cliente deseja seja realmente compreendido e que a entrega do produto seja realmente o que o cliente havia solicitado (veja a clássica figura, que ilustra os problemas de comunicação no levantamento e coleta de requisitos), Martins (2013) fornece algumas dicas importantes para ajudar a superar as barreiras da comunicação:

• Ouvir ativamente e de forma eficaz;
• Perguntar, investigando ideias e situações, para garantir melhor entendimento;
• Oferecer treinamento à equipe de engenheiros de requisitos;
• Levantar fatos para identificar ou confirmar informações;
• Identificar as expectativas dos stakeholderse persuadi-los a executarem a ação;
• Negociar para conseguir acordos aceitáveis;
• Solucionar conflitos para evitar impactos negativos;
• Resumir, recapitular e identificar as etapas seguintes do projeto.

Conflitos de comunicação na definição de projetos

Fonte: speakinbytes.com

A seguir serão apresentadas as principais técnicas de coleta de requisitos utilizadas.

Entrevistas

Entrevista

Fonte: speakinbytes.com

Refere-se a uma série de encontros com os clientes ou usuários que explicam o seu trabalho, o ambiente em que atua, necessidades, dentre outros assuntos pertinentes. Requer, do analista de requisitos, habilidades sociais como saber ouvir, saber inferir, saber dirimir conflitos. Estas habilidades são estendidas à equipe de desenvolvimento.

Os quatro passos de uma entrevista são:

1. Planejamento da Entrevista:
• Deve-se decidir quem será entrevistado.
• Preparar os entrevistados (agendar data e hora, comentar sobre o assunto).
• Preparar a lista de questões de diversos tipos:
• Abertas: “Explique como esse relatório é produzido.”
• Fechadas: “Quantos relatórios desse tipo são gerados?”
• Sequenciais: “Por quê?”, “Dê um exemplo”. Deve-se preocupar em dar continuidade a uma questão.
• Preparar mais de uma questão para um tópico a fim de confirmar a resposta e deixá-la mais completa.
2. Condução da Entrevista:
• Pirâmide: Começa com questões fechadas e expande para questões abertas dirigidas. É uma abordagem importante quando o entrevistado parece relutante em falar do assunto.
• Funil: Começa obtendo detalhes e dá continuidade obtendo respostas diretas. Muitas questões fechadas e sequenciais tornam-se necessárias.
• Diamante: Combina as duas abordagens anteriores. A entrevista fica menos cansativa, pois varia o tipo de questão. Na entrevista não se deve induzir respostas, como “O relatório deveria ser gerado semanalmente?”
3. Finalização da Entrevista:
   Deve-se reservar um tempo, o menor possível, que seja adequado para sumarizar as informações recebidas. O analista deve explicar os próximos passos ao cliente e apresentar a importância da entrevista, agradecendo o entrevistado.
4. Análise de Resultados:
   Deve-se produzir um documento da entrevista e descobrir ambiguidades, conflitos e omissões. As informações devem ser consolidadas e documentadas. Mas a técnica de entrevista apresenta diversos problemas:
• Observações divergentes: pessoas diferentes se concentram em diferentes aspectos e podem “ver” coisas diferentes.
• Interpretações diferentes: o entrevistador e o entrevistado podem estar interpretando palavras comuns de maneira diferente, tais como “pequena quantidade de dados” ou “caracteres especiais”.
• Ambiguidades: há ambiguidades inerentes à maioria das formas de comunicação, especialmente em linguagem natural.
• Conflitos: entrevistador e entrevistado podem ter opiniões conflitantes sobre um determinado problema e a tendência é registrar o ponto de vista do entrevistador.

Levantamento de Requisitos

Atividades ligadas ao Levantamento de Requisitos

De acordo com o PMBoK (Project Management Body of Knowledge), um guia que reúne o conjunto de Melhores Práticas em Gerenciamento de Projetos produzido pelo Project Management Institute (PMI, 2013, p. 110), o Plano de Gerenciamento dos Requisitos deve compor o Plano de Gerenciamento do Projeto de Software, sendo um documento que objetiva descrever como os requisitos serão analisados, documentados e gerenciados. De acordo com o guia, os componentes do Plano de Gerenciamento dos Requisitos podem incluir a definição:

• de como as atividades dos requisitos serão planejadas, rastreadas e relatadas;
• das atividades de gerenciamento da configuração: como as mudanças do produto serão iniciadas, como os impactos serão analisados, rastreados, monitorados e relatados, os níveis de autorização necessários para aprovar tais mudanças etc.;
• do processo de priorização dos requisitos;
• das métricas do produto que serão usadas e os argumentos que justificam o seu uso;
• da estrutura de rastreabilidade que reflita quais atributos dos requisitos serão capturados na matriz de rastreabilidade.

O guia define um processo para a Coleta de Requisitos, que objetiva determinar, documentar e gerenciar as necessidades e requisitos dos stakeholders de forma a atender aos objetivos do projeto.

Os requisitos incluem condições ou capacidades que devem ser atendidas pelo projeto ou estar presentes no produto, serviço ou resultado para cumprir um acordo ou outra especificação formalmente imposta. Os requisitos incluem as necessidades quantificadas e documentadas e as expectativas do patrocinador, cliente e outras partes interessadas. Estes requisitos precisam ser obtidos, analisados e registrados com detalhes suficientes para serem incluídos na linha de base do escopo e medidos uma vez que a execução do projeto se inicie.

Fonte: PMI (2013, p. 112)

O levantamento ou elicitação de requisitos tem como principal objetivo definir e documentar as funções e funcionalidades do sistema necessárias para atender às necessidades e expectativas dos stakeholders. O sucesso do sistema é diretamente influenciado pela atenção ao levantamento e ao gerenciamento dos requisitos.

Pressman (2011, p. 133) afirma que o levantamento de requisitos combina atividades ligadas à análise, negociação e especificação. O autor sugere que os stakeholders devam trabalhar juntos para identificar o problema, propor soluções, negociar abordagens diferentes e especificar os requisitos iniciais da solução, dentro de uma abordagem colaborativa.

Sommerville (2011, p. 70) indica como atividades essenciais ao levantamento de requisitos: descoberta de requisitos; classificação e organização dos requisitos, priorização e negociação dos requisitos e especificação dos requisitos.

A figura ilustra as principais atividades ligadas ao levantamento de requisitos:

Atividades do levantamento de requisitos.
Fonte: baseado em SOMMERVILLE (2011) e PRESSMAN (2011)

Sommerville (2011) enumera os seguintes motivos que tornam a elicitação de requisitos um processo difícil:

• Os stakeholders usualmente não sabem bem o que querem de um sistema computacional, não conhecem seus limites e muitas vezes solicitam coisas inviáveis;
• Os stakeholders expressam os requisitos usando seus termos, que têm implícito seu conhecimento de trabalho, e os engenheiros de requisitos podem não compreendê-los;
• Diferentes stakeholders possuem requisitos distintos e podem expressá-los de forma distinta, então os engenheiros de requisitos devem buscar descobrir semelhanças e conflitos;
• Fatores políticos, como gerentes desejarem requisitos que aumentem seu poder na organização, podem influenciar os requisitos;
• Novos requisitos podem surgir em função da entrada de novos stakeholders, mudanças no cenário econômico podem provocar mudanças nos requisitos e, ainda, a importância dos requisitos pode ser alterada.

Negociação

Fonte: dilbert.com

Como podemos notar, caro aluno, a negociação é essencial para balancear as diferentes opiniões e os conflitos provocados pelos diferentes stakeholders no processo de elicitação de requisitos.

Também é importante que os requisitos levantados sejam documentados para que possam ajudar na descoberta de novos requisitos. Os componentes da documentação podem incluir, mas não estão limitados, a:

• A necessidade do negócio ou oportunidade a ser aproveitada, descrevendo as limitações da situação atual e por que o projeto foi empreendido;
• Objetivos do negócio e do projeto para permitir rastreamento;
• Requisitos funcionais descrevendo processos de negócio, informações e interação com o produto de forma apropriada a ser documentada textualmente;
• Requisitos não funcionais, tais como nível de serviço, desempenho, cuidados, segurança, atendimento a leis e regulamentos etc.;
• Impactos em outras áreas organizacionais;
• Impactos em outras entidades internas ou externas à organização.

Para que este processo ocorra com sucesso, os requisitos devem ser claros, completos, sem ambiguidade, implementáveis, consistentes e testáveis, como mostra a tabela. Os requisitos que não apresentem tais qualidades são problemáticos: eles devem ser revistos e renegociados com os clientes e usuários.

TABELA – Características dos requisitos

Não ambíguo	Todo requisito tem apenas uma interpretação possível.
Correto	Todo requisito representa algo requerido do sistema ou funcionalidade a ser construída.
Completo	Contém o que o software deve fazer e atender em todas as situações possíveis.
Compreensível	Todas as pessoas podem facilmente compreender o significado de todos os requisitos com um mínimo de explicação.
Verificável	Atende ao conjunto de técnicas que podem ser usadas para verificar que todo requisito está implementado pelo sistema.
Internamente consistente	Não deve haver requisitos conflitantes entre si.
Externamente consistente	Não deve haver requisitos conflitantes com outra documentação de projeto já definida.
Realizável	Possibilita que um projeto seja implementado corretamente com todos os requisitos declarados.
Conciso	É tão pequeno quanto possível, sem afetar qualquer outra qualidade que deva atender.
Rastreável	É escrito de modo que facilite o “referenciamento” de cada requisito individualmente.
Modificável	Sua estrutura e estilo são tais que qualquer mudança pode ser feita facil, completa e consistentemente.
Anotado por importância relativa	Permite que se possa facilmente determinar qual requisito é mais importante para os clientes.
Anotado por estabilidade relativa	Permite que se possa facilmente determinar qual requisito é mais suscetível à mudança.
Organizado	Permite que se possa facilmente localizar informações e relacionamentos lógicos entre seções adjacentes.

Fonte: Gonsales, 2010