INTRODUÇÃO A ENGENHARIA DE REQUISITOS

Prévia do material em texto

INTRODUÇÃO A ENGENHARIA DE REQUISITOS
Veja neste artigo o que é a engenharia de requisitos e como funciona o seu processo e as suas atividades
A Engenharia de Requisitos é a atividade fundamental no desenvolvimento de software, a Engenharia de Requisitos é a etapa na qual são elicitadas/identificadas as funcionalidades a serem implementadas, assim como as condições a serem atendidas pela aplicação.
Requisitos são as bases para todo projeto, definindo o que as partes interessadas de um novo sistema necessitam e também o que o sistema deve fazer para satisfazer as suas necessidades. Os requisitos guiam as atividades do projeto e normalmente são expressos em linguagem natural para que todos possam obter o entendimento.
Além dos requisitos definirem os problemas e soluções também devemos definir os riscos e prover soluções satisfatórias casos esses riscos venham a falhar. Dessa forma, os requisitos definem as bases para:
- Planejamento do Projeto
- Gerenciamento de Riscos 
- Testes de Aceitação
- Controle de Mudanças
Os requisitos são tão importantes que normalmente eles possuem um grande impacto nas falhas dos projetos de software. Abaixo destacamos os três principais problemas para falhas em projetos de software:
- Requisitos: requisitos pobremente organizados, muito mal expressados, probremente relatados para as partes interessadas, mudanças muito rápidas ou desnecessárias, expectativas não realistas.
- Gerenciamento de Problemas de Recursos: incapacidade de ter dinheiro suficiente e falta de apoio ou fracasso para impor disciplina e planejamento. Muitas delas surgem pela falta de controle de requisitos.
- Politicas: Contribui para o primeiro e segundo problema.
O mais interessante é que todos esses problemas podem ser resolvidos com pouco dinheiro.
Dessa forma, podemos afirmar que a engenharia de requisitos é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo.
Ao longo do artigo veremos mais o que é engenharia de requisitos, como se dá o processo de engenharia de requisitos e quais são as suas principais atividades.
1. Processo de Engenharia de Requisitos
Portanto, a engenharia de requisitos é o processo pelo qual os requisitos de um produto de software são coletados, analisados, documentados e gerenciados ao longo de todo o ciclo de vida do software.
Entendido o que é a engenharia de requisitos, podemos partir para conhecer como funciona o processo de engenharia de requisitos. Fazendo um paralelo com o processo de desenvolvimento de software, tem-se que um processo de software envolve diversas atividades que podem ser classificadas em: Atividades de Desenvolvimento onde temos atividades que contribuem para o desenvolvimento do produto de software como levantamento e análise de requisitos, projeto e implementação; Atividades de Gerência que envolvem atividades de planejamento e acompanhamento gerencial do projeto; e Atividades de Controle da Qualidade que estão relacionadas com a avaliação da qualidade do produto.
De uma forma geral os requisitos possuem um papel fundamental para o desenvolvimento de software. Os requisitos de software são uma das principais medidas de sucesso de um software, visto que se eles atendem aos objetivos e requisitos para os quais foi construído o software e está totalmente de acordo com as necessidades dos clientes. Requisitos são a base para estimativas, modelagem, projeto, implementação, testes e até mesmo para a manutenção. Assim, os requisitos estão presentes ao longo de todo o ciclo de vida de um software.
Já no início de um projeto temos que levantar os requisitos, entende-los e documentá-los. Como os requisitos são extremamente importantes para o sucesso de um projeto, devemos também realizar atividades de controle da qualidade para verificar, validar e garantir a qualidade dos requisitos. Outra medida fundamental é gerenciarmos a evolução dos requisitos, visto que os negócios são dinâmicos e não temos como garantir que esses requisitos não sofrerão alterações. Dessa forma devemos manter a rastreabilidade entre os requisitos e os demais artefatos produzidos no projeto.
Portanto, podemos constatar que os requisitos envolvem atividades de desenvolvimento através do Levantamento e Análise e Documentação de Requisitos, gerência através da Gerência de Requisitos e por fim o controle da qualidade através da Verificação, Validação e Garantia da Qualidade de Requisitos. Todas essas atividades que são relacionadas a requisitos é o Processo de Engenharia de Requisitos.
No restante do artigo veremos um pouco mais o que são cada uma das dessas atividades que fazem parte do processo de engenharia de requisitos.
2. Levantamento de Requisitos
Esta é a fase inicial do processo de engenharia de requisitos. Nessa atividade levam-se em conta as necessidades dos usuários e clientes, informações de domínio, sistemas já existentes na organização, regulamentos vigentes, leis, etc.
O objetivo nessa fase é entendermos a organização como um todo, seus processos, necessidades, possibilidades de melhorias e restrições existente. Dessa forma, nos preocupamos na descoberta dos requisitos.
Essa fase é bastante complexa e também exige obtermos informações dos interessados, consultar documentos, obter conhecimentos do domínio e estudar o negócio da organização.
No levantamento de requisitos devemos atentar para quatro entendimentos que devemos possuir: Entendimento do Domínio da Aplicação onde se entende, de uma maneira geral, a área na qual o sistema será aplicado; Entendimento do Problema onde entendemos os detalhes do problema específico a ser resolvido com o auxílio do sistema a ser desenvolvido; Entendimento do Negócio onde entendemos como o sistema afetará a organização e como contribuirá para que os objetivos do negócio e os objetivos gerais da organização sejam atingidos; e por fim o Entendimento das Necessidades e das Restrições dos Interessados onde entende-se as demandas de apoio para a realização do trabalho de cada um dos interessados no sistema, entende-se os processos de trabalho a serem apoiados pelo sistema e o papel de eventuais sistemas existentes na execução e condução dos processos de trabalho.
Para o levantamento de requisitos temos diversas técnicas úteis que podem ser empregadas para ajudar o levantamento desses requisitos, são elas: entrevistas, questionários, observação do ambiente e dos indivíduos nas suas tarefas cotidianas na organização, análise de documentos existentes na organização, cenário de interação entre o usuário final e o sistema onde o usuário pode simular a sua interação com o sistema explicando para o analista o que ele está fazendo e de que informações ele precisa para realizar a tarefa, prototipagem onde uma versão preliminar do sistema, muitas vezes não operacional e descartável, é apresentada ao usuário para capturar informações específicas sobre seus requisitos de informação, observação reações, dinâmica de grupo, e diversas outras técnicas que também podem ser empregadas.
3. Análise de Requisitos
Após a atividade de Levantamento de Requisitos inicia-se a atividade de Análise de Requisitos, que é onde os requisitos levantados são usados como base para a modelagem do sistema.
Os requisitos são escritos tipicamente em linguagem natural, no entanto, é útil expressarmos requisitos mais detalhados do sistema de maneira mais técnica através de diversos tipos de modelos que podem ser utilizados. Esses modelos são representações gráficas que descrevem processos de negócio, o problema a ser resolvido e o sistema a ser desenvolvido. Representações gráficas são muito mais compreensíveis do que descrições detalhadas em linguagem natural e por isso são utilizados.
Dessa forma, a análise é uma atividade de modelagem. Vale ressaltar que essa modelagem é conceitual, pois estamos preocupados com o domínio do problema e não com soluções técnicas. Portanto, os modelos de análise são elaborados a fim de obtermos uma compreensão maior dosistema a ser desenvolvido e para especificá-lo.
Na análise de requisitos buscam-se principalmente duas perspectivas, a primeira delas é a estrutural onde se busca modelar os conceitos, propriedades e relações do domínio que são consideradas relevantes para o sistema em desenvolvimento. A segunda perspectiva é a comportamental onde se busca modelar o comportamento geral do sistema, de uma de suas funcionalidades ou de uma entidade.
Os diagramas da UML proveem suporte a todos os diagramas necessários nessa fase de análise.
4. Documentação de Requisitos
Os requisitos e modelos capturados nas etapas de Levantamento de Requisitos e Análise de Requisitos devem ser descritos e apresentados em documentos. A documentação é uma atividade de registro e oficialização dos resultados da engenharia de requisitos. Como resultado, um ou mais documentos devem ser produzidos.
Essa documentação escrita de uma boa forma apresenta diversos benefícios como facilidade na comunicação dos requisitos, redução no esforço de desenvolvimento, fornece uma base realista para estimativas, boa base para verificação e validação, entre outros benefícios.
A documentação produzida também possui diversos interessados que usam a documentação para diferentes propósitos. Os clientes, Usuários e Especialistas de Domínio atuam na especificação, avaliação e alteração dos requisitos. Gerentes de Cliente utilizam a documentação para planejar uma proposta para o sistema e para planejar e acompanhar o processo de desenvolvimento. Os desenvolvedores utilizam a documentação para compreender o sistema e a relação entre as suas partes. Os Testadores utilizam a documentação para projetar casos de teste.
O Documento de Requisitos deve conter uma descrição do propósito do sistema, uma breve descrição do domínio do problema e listas de requisitos funcionais, não funcionais e regras de negócio, tudo descrito em linguagem natural. Desenvolvedores, clientes, usuários e gerentes utilizam esse documento. Outro documento que pode ser produzido é o Documento de Especificação de Requisitos que deve conter os requisitos escritos a partir da perspectiva do desenvolvedor, contendo inclusive uma correspondência direta com os requisitos no Documento de Requisitos. Os modelos produzidos na fase anterior devem ficar dentro deste documento de especificação de requisitos.
5. Verificação, Validação e Garantia da Qualidade de Requisitos
Essa fase deve ser iniciada o quanto antes no processo de desenvolvimento de software. Os requisitos são a base para o desenvolvimento, dessa forma é fundamental que eles sejam cuidadosamente avaliados. Portanto, os documentos produzidos durante a fase anterior devem ser submetidos à verificação e validação de requisitos.
A diferença entre verificação e validação é que verificação assegura que o software esteja sendo construído de forma correta. Por sua vez a validação assegura que o software que está sendo desenvolvido é o software correto. Portanto, a verificação assegura que os artefatos produzidos atendem aos requisitos e a validação assegura que os requisitos e o software que foi derivado desses requisitos atendem ao uso proposto.
A validação envolve a participação do usuário e do cliente, pois apenas eles possuem condições de confirmar que os requisitos atendem aos propósitos do sistema.
Nessa fase examinam-se os documentos de requisitos para garantir que todos os requisitos tenham sido declarados de modo não ambíguo, que as inconsistências, conflitos, omissões e erros tenham sido detectados e corrigidos, que os documentos estão em conformidade com os padrões estabelecidos, que os requisitos realmente satisfazem às necessidades dos clientes e usuários.
Portanto, os requisitos devem ser completos, corretos, consistentes, realistas, necessário, passível de ser priorizado, verificável e rastreável.
6. Gerência de Requisitos
Mudanças nos requisitos ocorrem durante todo o processo de software, desde o levantamento de requisitos até durante a operação do sistema em produção. Isso ocorre devido à descoberta de erros, omissões, conflitos, inconsistência nos requisitos, melhor entendimento dos usuários sobre as suas necessidades, problemas técnicos, mudanças de prioridades do cliente, mudanças no negócio, concorrentes, mudanças econômicas, mudanças no ambiente de software, mudanças organizacionais, etc.
Para minimizar os problemas causados por essas mudanças é necessário gerenciar requisitos. O Processo de Gerencia de Requisitos envolve atividades que ajudam a equipe a identificar, controlar e rastrear requisitos e gerenciar mudanças de requisitos em qualquer momento ao longo do ciclo de vida do software.
Portanto, os objetivos do processo são gerenciar alterações nos requisitos acordados, gerenciar relacionamentos entre requisitos, gerenciar dependências entre requisitos e outros documentos produzidos durante o processo de software. Dessa forma, a gerência de requisitos possui as seguintes atividades: controle de mudanças, controle de versão, acompanhamento do estado dos requisitos e rastreamento de requisitos.
A definição de um processo apropriado para uma organização é muito importante e traz diversos benefícios, pois uma boa descrição de um processo fornece orientações e reduz a probabilidade de erros ou esquecimentos. O mais importante é saber que não existe um processo ideal, portanto adaptar um processo para as necessidades internas é sempre a melhor escolha ao invés de impor um processo à organização. 
ENGENHARIA DE SOFTWARE E REQUISITOS
Neste artigo, faremos uma introdução à Engenharia de Requisitos, atividade base para as demais tarefas associadas ao desenvolvimento de software.
A Engenharia de Software visa à criação de produtos de software que atendam às necessidades de pessoas e instituições e, portanto, tenham valor econômico. Para isso, usa conhecimentos científicos, técnicos e gerenciais, tanto teóricos quanto empíricos. Ela atinge seus objetivos de produzir software com alta qualidade e produtividade quanto é praticada por profissionais treinados e bem informados, utilizando tecnologias adequadas, dentro de processos que tirem proveito tanto da criatividade quando da racionalização do trabalho.
Introdução à Engenharia de Requisitos
Desenvolver software é uma atividade complexa por natureza. Uma das razões para esta afirmação é que não existe uma única solução para cada cenário de desenvolvimento. Além disso, lidamos o tempo todo com pessoas, o que torna o sucesso do projeto bastante relacionado à competência da equipe e à forma como trabalham, e, para dificultar ainda mais, muitas vezes não fazemos uso de um processo bem definido para apoiar as atividades do projeto.
Entende-se por processo, neste contexto, como sendo um conjunto de atividades bem definidas com os respectivos responsáveis por execução, ferramentas de apoio e artefatos produzidos. Ou seja, define-se como a equipe deverá trabalhar para alcançar o objetivo: desenvolver software com qualidade dentro de prazos, custos e requisitos definidos.
A boa notícia é que muitas empresas estão se movimentando no sentido de definirem detalhadamente seus processos para apoiarem suas atividades de desenvolvimento. Uma recente matéria publicada na revista Exame relata o crescimento do número de empresas que atingiram níveis de maturidade considerando modelos como MPS.BR e CMMI. Este resultado é um forte indicador de que as empresas nacionais estão se preocupando com a qualidade dos serviços que oferecem, conseguindo, dessa forma, uma inserção maior no mercado internacional de desenvolvimento de software.
Neste artigo, faremos uma introdução à Engenharia de Requisitos, atividade base para as demais tarefas associadas ao desenvolvimento de software.
Vimos na introdução que se busca cada vez mais o apoio dos fundamentos da engenharia de software no desenvolvimento de sistemas. Entendemos engenharia de software como sendo, de acordo com o IEEE, a aplicação de uma abordagem sistemática, disciplinada e quantificável no desenvolvimento, operaçãoe manutenção de software. Sistemática por que parte do princípio de que existe um processo de desenvolvimento definindo as atividades que deverão ser executadas. Disciplinada por que parte do princípio de que os processos definidos serão seguidos. Quantificável por que se deve definir um conjunto de medidas a serem extraídas do processo durante o desenvolvimento de forma que as tomadas de decisão relacionadas ao desenvolvimento do software (por exemplo, melhoria de processo) sejam embasadas em dados reais, e não em “achismos”. Alguns de seus principais objetivos são:
Qualidade de software; 
Produtividade no desenvolvimento, operação e manutenção de software; 
Permitir que profissionais tenham controle sobre o desenvolvimento de software dentro de custos, prazos e níveis de qualidade desejados. 
Entretanto, o cenário de desenvolvimento de software atual e o cenário idealizado junto à engenharia de software ainda estão distantes. Vários fatores contribuem para isso, podemos citar dois:
O não uso dos fundamentos da engenharia de software para apoiar as atividades do desenvolvimento; 
O mau uso dos fundamentos da engenharia de software para apoiar as atividades do desenvolvimento. 
Isso tem diversas consequências. Gostaríamos de destacar neste artigo o crescente custo com manutenção dos sistemas. Consideramos como manutenção neste artigo como sendo qualquer retrabalho (em nível de requisitos, projeto, codificação, teste) causado por uma definição do domínio do problema mal elaborada nas fases iniciais do desenvolvimento.
Neste ponto, é importante analisamos os dados da Tabela 1. Perceba que o custo das atividades relacionadas à análise de requisitos é baixo. Por outro lado, é nesta fase que grande parte dos defeitos são inseridos. Podemos perceber ainda analisando a primeira linha que o custo de correção destes problemas nesta fase é baixo. Continuando a análise, percebemos que estes defeitos não são tratados no momento devido, o que pode aumentar bastante o custo com o projeto.
Embora simples, esta análise nos permite concluir que é importante que seja dada maior importância às atividades relacionadas à especificação dos requisitos do software. 
Tabela 1. Cenário atual de desenvolvimento.
Reforçando a importância que as atividades relacionadas a requisitos devem possuir na indústria de software, estudo realizado pelo Standish Group, considerando 350 companhias e 8.000 projetos de software, em 1995 revelou que (ver Figura 1): 
16,2% dos projetos são finalizados com sucesso, ou seja, cobre todas as funcionalidades em tempo e dentro do custo previsto; 
52.7% dos projetos são considerados problemáticos, ou seja, não cobre todas as funcionalidades exigidas, custo aumentado e está atrasado. 
31,1% dos projetos fracassam, ou seja, o projeto é cancelado durante o desenvolvimento. 
Figura 1. Distribuição da conclusão dos projetos de software.
O Standish Group ainda fez uma análise sobre os fatores críticos para sucesso dos projetos de software. O resultado dos dez mais lembrados pode ser visto na Tabela 2. Podemos perceber que três dos principais fatores estão relacionados às atividades de requisitos: (1) Requisitos Incompletos; (2) Falta de Envolvimento do Usuário; (6) Mudança de Requisitos e Especificações.
	Fatores Críticos
	%
	1. Requisitos Incompletos
	13.1%
	2. Falta de Envolvimento do Usuário
	12.4%
	3. Falta de Recursos
	10,6%
	4. Expectativas Irreais
	9,9%
	5. Falta de Apoio Executivo
	9,3%
	6. Mudança de Requisitos e Especificações
	8,7%
	7. Falta de Planejamento
	8,1%
	8. Sistema não mais necessário
	7,5%
Tabela 2. Fatores críticos do sucesso.
Neste ponto, sabemos que um trabalho mais criterioso na área de requisitos é fundamental para o sucesso de projetos de software. A partir da próxima seção conheceremos a definição de requisitos e algumas de suas definições relacionadas antes de discutirmos mais profundamente a engenharia de requisitos.
Requisitos
Existem diferentes definições encontradas na literatura técnica para requisitos:
Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos; 
As descrições das funções e restrições são os requisitos do sistema; 
Um requisito é uma propriedade que o software deve exibir para resolver algum problema no mundo real; 
Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto... 
Percebe-se que as citações encontradas definem o mesmo conceito sob diferentes perspectivas. Podemos entender requisitos como sendo o conjunto de necessidades explicitadas pelo cliente que deverão ser atendidas para solucionar um determinado problema do negócio no qual o cliente faz parte. É importante estar atento para esta definição: embora o requisito seja definido pelo cliente, nem sempre o que o cliente quer é o que o negócio precisa. Cabe à equipe de consultores identificar a real necessidade do negócio.
Neste contexto, requisitos são importantes para:
Estabelecer uma base de concordância entre o cliente e o fornecedor sobre o que o software fará; 
Fornecer uma referência para a validação do produto final; 
Reduzir o custo de desenvolvimento (como vimos anteriormente, requisitos mal definidos causam retrabalho). 
Entendida a definição de requisitos, é preciso conhecer seus tipos.
Requisitos funcionais
São requisitos diretamente ligados a funcionalidade do software, descrevem as funções que o software deve executar. Alguns exemplos são:
O software deve permitir o cadastro de clientes; 
O software deve permitir a geração de relatórios sobre o desempenho de vendas no semestre; 
O software deve permitir o pagamento das compras através de cartão de crédito. 
Requisitos não funcionais
São requisitos que expressam condições que o software deve atender ou qualidades específicas que o software deve ter. Em vez de informar o que o sistema fará, os requisitos não-funcionais colocam restrições no sistema. Alguns exemplos são:
O software deve ser compatível com os browsers IE (versão 5.0 ou superior) e Firefox (1.0 ou superior); 
O software deve garantir que o tempo de retorno das consultas não seja maior do que 5 segundos. 
Requisitos de domínio
São requisitos 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. Dois exemplos de requisitos do domínio são:
O cálculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 + Nota2 * 3)/5; 
Um aluno pode se matricular em uma disciplina desde que ele tenha sido aprovado nas disciplinas consideradas pré-requisitos. 
A partir da próxima seção apresentaremos os conceitos envolvidos na engenharia de requisitos.
Engenharia de Requisitos
Existem diferentes definições encontradas na literatura técnica para engenharia de requisitos:
Termo usado para descrever as atividades relacionadas à investigação e definição de escopo de um sistema de software; 
Processo sistemático de desenvolvimento de requisitos através de um processo cooperativo de análise onde os resultados das observações são codificados em uma variedade de formatos e a acurácia das observações é constantemente verificada; 
Processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema. 
Embora coerentes, estas definições podem ser melhoradas. Perceba que elas referem-se apenas às atividades relacionadas à produção de requisitos. Entretanto, nada é dito a respeito da gerência destas atividades, também conhecida como gerência de requisitos. Com isto em mente, podemos evoluir a definição de engenharia de requisitos para: termo usado para descrever as atividades relacionadas à produção (levantamento, registro, validação e verificação) e gerência (controle de mudanças, gerência de configuração, rastreabilidade,gerência de qualidade dos requisitos) de requisitos. A Figura 3 representa essa definição.
Figura 3. Engenharia de Requisitos.
Desta forma, os dois conceitos base (produção e gerência) devem ser considerados em conjunto ao se definir estratégias de trabalho com requisitos nas organizações (ver Figura 4).
Figura 4. Produção e Gerência de Requisitos.
Neste ponto podemos citar alguns dos principais objetivos da engenharia de requisitos:
estabelecer uma visão comum entre o cliente e a equipe de projeto em relação aos requisitos que serão atendidos pelo projeto de software; 
registrar e acompanhar requisitos ao longo de todo o processo de desenvolvimento; 
documentar e controlar os requisitos alocados para estabelecer uma baseline para uso gerencial e da engenharia de software; 
manter planos, artefatos e atividades de software consistentes com os requisitos alocados. 
Para apoiar o alcance destes objetivos, é importante que se tenha um processo de engenharia de requisitos bem definido. Um processo de engenharia de requisitos é um conjunto estruturado de atividades a serem seguidas para criar, validar e manter um documento de requisitos. Poucas organizações têm um processo de ER explicitamente definido e padronizado. Entretanto, sugere-se que cada organização deva desenvolver um processo adequado à sua realidade. A Figura 5 apresenta um modelo genérico de atividades que pode descrever a maioria dos processos de engenharia de requisitos. Perceba que ele está concentrado nas atividades de produção dos requisitos.
Figura 5. Processo de Engenharia de Requisitos.
Apesar do aparente fluxo entre as atividades, não existe uma fronteira explícita elas. Na prática existe muita sobreposição e interação entre uma atividade e outra.
Como entradas para o processo são consideradas:
Descrições do que os stakeholders necessitam para suportar suas atividades; 
Informações a respeito do sistema que será substituído ou de qualquer sistema com o qual o sistema sendo definido terá que interagir; 
Padrões vigentes na organização a respeito de práticas de desenvolvimento de sistemas, gerência de qualidade, etc.; 
Regulamentos externos, tais como leis, regulamentos de segurança ou saúde; 
Informações gerais sobre o domínio de aplicação. 
Em paralelo à execução das atividades definidas no processo da Figura 5, está o processo de gerência dos requisitos, voltado ao endereçamento de modificações nos requisitos. Os aspectos relacionados às atividades de gerência podem ser vistos na Figura 3.
A partir de agora conheceremos cada um dos conceitos que, em conjunto, definem a engenharia de requisitos.
Produção de Requisitos
A cada fase do ciclo de vida do software produzimos um documento contendo uma representação distinta do software a ser construído. Cada um desses documentos representa o software em um determinado nível de abstração. A tendência é diminuirmos o nível de abstração através da inclusão de mais e mais detalhes, até que, sua última representação seja o código fonte na linguagem escolhida.
Um dos artefatos produzidos no início do processo de desenvolvimento de software é a sua especificação de requisitos. Ele é base para as demais atividades de desenvolvimento e sua qualidade é fundamental para o sucesso do projeto. Uma especificação de requisitos bem elaborada é pré-requisito para um software de qualidade, embora não seja garantia disso. Desta forma, durante a produção de requisitos devemos possuir, além das atividades essenciais de levantamento e especificação, atividades relacionadas à garantia da qualidade. Conheceremos nesta seção as quatro atividades base relacionadas com a produção de requisitos. 
Levantamento
Esta atividade relaciona-se à obtenção dos requisitos do software. Para isto, analistas e engenheiros de software trabalham com clientes e usuários finais para descobrir o problema a ser resolvido, os serviços do sistema, o desempenho necessário, restrições de hardware e outras informações.
Existem algumas técnicas que apóiam as atividades de levantamento de requisitos. Uma breve descrição de algumas delas é:
Entrevista: esta técnica resume-se em “conversas” realizadas com o usuário (entrevistado) para levantar os requisitos do sistema a ser desenvolvido. Podemos decompor esta técnica nas seguintes atividades:
Ler material de suporte;
Estabelecer os objetivos da entrevista;
Decidir quem entrevistar;
Preparar o entrevistado;
Decidir os tipos de questões e a sua estrutura.
Uma entrevista pode ser estruturada de três diferentes formas:
Estrutura em pirâmide: iniciamos as entrevistas com perguntas mais especificas sobre o sistema e fechamos com perguntas mais genéricas. Geralmente utilizadas com usuários mais relutantes;
Estrutura em funil: iniciamos as entrevistas com perguntas mais genéricas sobre o sistema e fechamos com perguntas mais especificas. Geralmente utilizadas com usuários que tem uma relação mais afetiva com o assunto;
Estrutura em diamante: esta estrutura combina as duas estruturas anteriores e é utilizadas para manter a usuário entrevistado interessado no assunto e para isto se utiliza de perguntas variadas.
Prototipação: é uma versão inicial de um sistema para experimentação. Permite aos utilizadores identificar os pontos fortes e fracos do sistema por ser algo concreto que pode ser criticado. Temos dois tipos de protótipos:
Protótipos “Throw-away”: ajudam o levantamento e desenvolvimento dos requisitos e suportam os requisitos mais difíceis de perceber;
Protótipos Evolutivos: ajudam o desenvolvimento rápido de uma versão inicial do sistema e suportam os requisitos bem definidos e conhecidos.
Algumas das desvantagens da prototipação são os custos de aprendizagem e os custos de desenvolvimento.
JAD (Joint Application Development): é uma técnica que permite a interação entre pessoas que necessitam tomar decisões que afetem múltiplas áreas de uma organização. Esta técnica envolve atividades de preparação para as reuniões, sessões de workshop com os participantes, agenda para as reuniões, participantes assumindo papeis de facilitador / condutor e documentador além de facilidades visuais, como a utilização de flipchart, quadro negro.
Esta técnica deve ser utilizada nos casos onde existe a necessidade de consenso entre diversos usuários, pois possibilita a todos os envolvidos ter uma visão global do sistema, ajudando a consolidar interesses de diversos usuários quanto ao sistema a ser desenvolvido.
O objetivo desta técnica é aumentar o comprometimento e participação do usuário e obter subsídios para elaborar o documento de Especificação de Requisitos para o sistema com consenso de todos de forma a ser uma validação formal dos requisitos do sistema. 
O JAD é divido quem quatro fases. A Figura 6 apresenta estas fases e os artefatos produzidos por cada uma delas.
 Figura 6. Fases da técnica para levantamento de requisitos JAD.
A atividade de levantamento de requisitos não é trivial. Existe um conjunto grande e variado de fatores que a tornam complexa, por exemplo:
Falta de conhecimento do usuário das suas reais necessidades 
Usuário com vaga noção do que precisa e do que um produto de software pode oferecer. 
Falta de conhecimento do desenvolvedor do domínio do problema 
Desenvolvedor sem conhecimento adequado do domínio, o que leva a decisões erradas. 
Domínio do processo de levantamento de requisitos pelos desenvolvedores 
Desenvolvedor não ouve o que os usuários têm a dizer e força suas próprias visões e interpretações. 
Comunicação inadequada entre os desenvolvedores e usuários 
Usuários incapazes de expressar suas necessidades apropriadamente; 
Significados diferentes a termos comuns. 
Dificuldade do usuário tomar decisões 
Falta de entendimento sobre as consequências das decisões ou as alternativas possíveis. 
Problemas de comportamento 
O levantamento de requisitos é um processo social; 
Conflitos e ambiguidades nos papéis que os usuários e desenvolvedores desempenham. 
Questões técnicas 
Complexidade crescentedos sistemas atuais. 
Registro
Uma vez identificados e negociados, os requisitos devem ser documentados para que possam servir de base para o restante do processo de desenvolvimento.
Entre os muitos problemas que enfrentamos na documentação de requisitos, certamente, administrar o grande volume de informações gerado pelo processo de requisitos é um dos principais.
Os requisitos são documentados em um nível apropriado de detalhe. Em geral é produzido um documento de especificação de requisitos, de forma que todos os stakeholders possam entendê-lo.
O registro dos requisitos num documento próprio facilita o controle de alterações de todos os envolvidos na manutenção dos requisitos, bem como a geração de versões do documento e a facilidade de acesso por todos os envolvidos. 
Verificação
Esta atividade examina a especificação do software, de forma a assegurar que todos os requisitos foram definidos sem ambiguidades, inconsistências ou omissões, detectando e corrigindo possíveis problemas ainda durante a fase de definição dos requisitos.
Neste contexto, sabe-se que o custo da correção de defeitos aumenta na medida em que o processo de desenvolvimento progride. Revisões de artefatos de software têm se mostrado uma abordagem eficiente e de baixo custo para encontrar defeitos logo após terem sido introduzidos, reduzindo o retrabalho e melhorando a qualidade dos produtos. Não é em vão que modelos de maturidade de processo de software, como o CMMI e o MPS BR exigem a condução de revisões.
Um tipo particular de revisão de software são as inspeções. Inspeções possuem um processo de detecção de defeitos rigoroso e bem definido. Os benefícios de se aplicar inspeções são maiores para artefatos desenvolvidos no início do processo, como o documento de requisitos. Conheceremos um pouco mais sobre inspeção de software em um segundo artigo a ser publicado na segunda edição da Engenharia de Software Magazine.
Validação
A validação representa a atividade em que obtemos o aceite do cliente sob determinado artefato. No cenário de engenharia de requisitos, esta atividade significa aprovar junto ao cliente os requisitos que foram especificados. Embora aparentemente simples, esta atividade pode ser bastante dificultada pelo cliente ou mesmo por um processo de validação inadequado utilizado pela empresa.
Gerência de Requisitos
Requisitos são por natureza voláteis. Diversos fatores contribuem para sua instabilidade ao longo do tempo. Mudanças externas no ambiente (mudanças de legislação, mudanças no mercado, mudança no posicionamento estratégico da empresa), erros incorridos no processo de requisitos, entre outros. Todos esses fatores fazem com que seja necessário alterar os requisitos. Tais alterações precisam ser conduzidas de forma ordenada para que não se perca controle sobre o prazo e o custo do desenvolvimento.
Denominamos a atividade de administrar os requisitos ao longo do tempo de gerenciamento de requisitos. Os benefícios desta atividade são percebidos no médio prazo, sendo que são necessários investimentos no curto prazo. Assim, a atividade é, muitas vezes, tida como um fardo desnecessário à condução do processo. Contudo, sua não implementação faz com que as economias de curto prazo sejam logo suplantadas pelas despesas no longo prazo, verificadas com superação de custo e prazo nos projetos conduzidos.
Veremos a partir de agora algumas das atividades que devem ser consideradas durante a gerência dos requisitos.
Controle de Mudanças
Conforme foi citado anteriormente, os requisitos são voláteis e, portanto, sofrem mudanças ao logo do tempo, para conduzir estas mudanças recomenda-se preparo e planejamento. Uma das maneiras bastante utilizadas para organizar estas mudanças é a “baseline” de requisitos que nos permite diferenciar o que era o requisito original, o que foi introduzido e o que foi descartado. Além disto, é interessante estabelecer um único canal para controle de mudanças, bem como utilizar um sistema para este controle.
Apresentamos a seguir uma sugestão de passos que devem ser seguidos para um processo de controle de mudança:
Checar validade da solicitação de mudança;
Identificar os requisitos diretamente afetados com a mudança;
Identificar dependências entre requisitos para buscar os requisitos afetados indiretamente;
Assegurar com solicitante a mudança a ser realizada;
Estimar custos da mudança;
Obter acordo com usuário sobre o custo da mudança.
Após a realização desta análise, podemos aceitar ou rejeitar a mudança, conforme os impactos e custos que ela pode ter no sistema.
Gerência de Configuração
Durante o ciclo de vida do desenvolvimento, o software passa por uma série de modificações, desde a especificação dos requisitos até a implantação do sistema. A gerência de configuração de software existe no intuito de definir critérios que permitam realizar tais modificações mantendo-se a consistência e a integridade do software com as especificações, minimizando problemas decorrentes ao processo de desenvolvimento, através de um controle sistemático sobre as modificações.
A criação de um plano de gerência de configuração consiste em estabelecer normas, ferramentas e templates que permitam gerenciar de maneira satisfatória os itens de configuração de um sistema, que são definidos por Pressman como: “cada um dos elementos de informação que são criados durante o desenvolvimento de um produto de software, ou que para este desenvolvimento sejam necessários, que são identificados de maneira única e cuja evolução é passível de rastreamento”. 
Em cada fase do processo de desenvolvimento, um conjunto bem definido de itens de configuração deve ser estabelecido. A este conjunto é dado o nome de baselines. Estas baselines servem como marco no processo de desenvolvimento, pois ao final de cada fase é estabelecida uma nova baseline e, portanto, todos os itens de configuração estão sob total controle de seus desenvolvedores. Desta forma, nesta baseline é guardada “uma foto” dos artefatos criados até aquele momento:
tornando mais fácil realizar modificações nos artefatos de maneira controlada;
possibilitando ter um controle sistemático sobre todos os itens de configuração abordados em cada fase do ciclo de vida do software, e;
tornando possível que sejam realizadas, mais facilmente, avaliações sobre seu grau de evolução.
Rastreabilidade
No centro da atividade de gerenciamento de requisitos está a rastreabilidade. Esta é definida como a habilidade de se acompanhar a vida de um requisito em ambas as direções (por exemplo: partindo de requisitos e chegando a projeto ou, partindo de projeto e chegando a requisitos) do processo de software e durante todo o seu ciclo de vida.
A dificuldade envolvida com a rastreabilidade está no grande volume de informações gerado. As informações do processo de requisitos devem ser catalogadas e associadas aos outros elementos de forma que possam ser referenciadas através dos diversos itens de informação registrados. É um trabalho extenso que, sem o auxílio de ferramentas adequadas, muito provavelmente não poderá ser feito
Para implementar a rastreabilidade, usualmente é confeccionado em conjunto com a especificação de requisitos um artefato chamado matriz de rastreabilidade, que tem como objetivo mapear os rastros dos requisitos descritos na especificação.
Os rastros dos requisitos podem ser de dois tipos:
Pré-rastreabilidade: os rastros (artefatos: plano de negocio, atas de reunião com o usuário) que fundamentaram a criação do requisito.
Pós-rastreabilidade: os rastros (artefatos: código, documentos) que se formaram a partir do requisito criado.
Gerência de Qualidade de Requisitos
Segundo o padrão IEEE 830, devemos considerar alguns critérios de qualidade ao trabalharmos com requisitos:
Correção: um documento de requisitos é considerado correto se todos os requisitos representam algo que deve estar presente no sistema que está sendo desenvolvido, ou seja, os requisitos reais do usuário devem coincidir com os requisitos identificados.Esta não é uma tarefa trivial e parte de seu sucesso está associada a uma boa atividade de validação dos requisitos.
Não ambiguidade: um conjunto de requisitos é não ambíguo quando somente pode ser interpretado por todos os envolvidos em um projeto de uma única maneira.
Completude: um conjunto de requisitos é dito completo quando descreve todas as demandas de interesse dos usuários. Estas demandas incluem requisitos funcionais, de desempenho, restrições, atributos e interfaces externas.
Consistência: um conjunto de requisitos é dito consistente se nenhum subconjunto destes requisitos entra em conflito com os demais requisitos do sistema.
Verificabilidade: um requisito é verificável se existe uma forma efetiva, em termos de tempo e custo, para que pessoas ou ferramentas indiquem se um sistema cumpre o requisito (IEEE). Em quase todas as situações, é difícil provar de forma conclusiva que um requisito é cumprido por um software. Entretanto, escrever bem o requisito pode ajudar a aumentar a confiança na avaliação.
Modificabilidade: um conjunto de requisitos é modificável quando seu estilo e estrutura é tal que as alterações podem ser realizadas de forma simples e consistente com os demais requisitos.
A gerência, neste cenário, é responsável por manter uma infra-estrutura necessária para atividades de verificação que tornem possível investigarmos a qualidade dos requisitos que estamos definindo.
Conclusão
A engenharia de requisitos define, sem dúvida, um dos mais importantes conjuntos de atividades a serem realizadas em projetos de desenvolvimento de software. Embora não garanta a qualidade dos produtos gerados, é um pré-requisitos básico para que obtenhamos sucesso no desenvolvimento do projeto. Este artigo é apenas uma breve introdução ao tema, que deverá ser bastante explorado em edições futuras da Engenharia de Software Magazine.
Bibliografia
[1] PRESSMAN, Roger, Engenharia de Software, McGraw-Hill, 6ª edição, 2006.
[2] Livro online de Engenharia de Requisitos, disponível em http://livrodeengenhariaderequisitos.blogspot.com.br/
TÉCNICAS PARA LEVANTAMENTO DE REQUISITOS
O início para toda a atividade de desenvolvimento de software é o levantamento de requisitos, sendo esta atividade repetida em todas as demais etapas da engenharia de requisitos.
Sommerville (2003) propõe um processo genérico de levantamento e análise que contém as seguintes atividades:
Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação;
Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade;
Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;
Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos;
Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes;
Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
O levantamento e análise de requisitos é um processo iterativo, com uma contínua validação de uma atividade para outra, conforme exemplificado pela Figura 1.
Figura 1. Processo de levantamento e análise de requisitos (SOMMERVILLE, 2003).
Dificuldades encontradas
O problema de não saber especificar corretamente o que o sistema deverá fazer é muito antigo. Pompilho (1995) cita um exemplo do relatório produzido por McKinsey, em 1968, e mencionado por B. Langefords e B. Sundgren onde se afirmava que dois terços das empresas ali estudadas estavam desapontadas com o atendimento recebido em sistemas de informação.
Após mais de 30 anos da elaboração do relatório a situação não é muito diferente. Algumas das razões para o baixo grau de satisfação dos usuários para os sistemas destacam-se:
Na fase de levantamento de requisitos do projeto, onde não é utilizada uma técnica adequada para extrair os requisitos do sistema;
A falha do analista em não descrever os requisitos do sistema de modo claro, sem ambiguidades, conciso e consistente com todos os aspectos significativos do sistema proposto.
Entre as dificuldades encontradas na fase de levantamento de requisitos estão: o usuário principal do sistema não sabe o que quer que o sistema faça ou sabe e não consegue transmitir para o analista; requisitos identificados, mas que não são realistas e não identificam os requisitos similares informados por pessoas diferentes. Um stakeholder errado afetará em perda de tempo e dinheiro para ambas as partes envolvidas no desenvolvimento do sistema.
Identifica-se um levantamento de requisitos adequado através da boa definição do projeto, da efetividade do projeto, de informações necessárias a um perfeito diagnóstico e de soluções inteligentes. Quanto ao levantamento de requisitos inadequado, o resultado é um diagnóstico pobre com conclusões comprometidas, não identificação das causas dos problemas, custos elevados, prazos vencidos ou comprometedores, omissão de processos fundamentais e descréditos.
Link vídeo: https://www.devmedia.com.br/levantamento-requisitos/ 
Técnicas de Levantamento de Requisitos
As técnicas de levantamento de requisitos têm por objetivo superar as dificuldades relativas a esta fase. Todas as técnicas possuem um conceito próprio e suas respectivas vantagens e desvantagens, que podem ser utilizadas em conjunto pelo analista.
Serão apresentadas de forma resumida nesse artigo algumas técnicas de levantamento de requisitos.
Levantamento orientado a pontos de vista
Para qualquer sistema, de tamanho médio ou grande, normalmente há diferentes tipos de usuário final. Muitos stakeholders têm algum tipo de interesse nos requisitos do sistema. Por esse motivo, mesmo para um sistema relativamente simples, existem muitos pontos de vista diferentes que devem ser considerados. Os diferentes pontos de vista a respeito de um problema ‘vêem’ o problema de modos diferentes. Contudo, suas perspectivas não são inteiramente independentes, mas em geral apresentam alguma duplicidade, de modo que apresentam requisitos comuns.
As abordagens orientadas a ponto de vista, na engenharia de requisitos, reconhecem esses diferentes pontos de vista e os utilizam para estruturar e organizar o processo de levantamento e os próprios requisitos. Uma importante capacidade da análise orientada a pontos de vista é que ela reconhece a existência de várias perspectivas e oferece um framework para descobrir conflitos nos requisitos propostos por diferentes stakeholders.
O método VORD (viewpoint-oriented requirements definition – definição de requisitos orientada a ponto de vista) foi projetado como um framework orientado a serviço para o levantamento e análise de requisitos.
A primeira etapa da análise de ponto de vista é identificar os possíveis pontos de vista. Nessa etapa os analistas se reúnem com os stakeholders e utilizam a abordagem de brainstorming para identificar os serviços em potencial e as entidades que interagem com o sistema.
A segunda etapa é a estruturação de pontos de vista, que envolve agrupar pontos de vista relacionados, segundo uma hierarquia. Serviços comuns estão localizados nos níveis mais altos da hierarquia e herdados por pontos de vista de nível inferior.
A etapa de documentação do ponto de vista tem por objetivo refinar a descrição dos pontos de vista e serviços identificados.
O mapeamento de sistema conforme ponto de vista envolve identificar objetos em um projeto orientado a objetos, utilizando as informações de serviço que estão encapsuladas nos pontos de vista.
A Figura 2 exemplifica a técnica de levantamento orientado a ponto de vista.
Figura 2. Método VORD, SOMMERVILLE– 2003.
Etnografia
A etnografia é uma técnica de observação que pode ser utilizada para compreender os requisitos sociais e organizacionais, ou seja, entender a política organizacional bem como a cultura de trabalho com objetivo de familiarizar-se com o sistema e sua história. Os cientistas sociais e antropólogos usam técnicas de observação para desenvolver um entendimento completo e detalhado de culturas particulares.
Nesta técnica, o analista se insere no ambiente de trabalho em que o sistema será utilizado. O trabalho diário é observado e são anotadas as tarefas reais em que o sistema será utilizado. O principal objetivo da etnografia é que ela ajuda a descobrir requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais, onde as pessoas estão envolvidas.
Etnografia é particularmente eficaz na descoberta de dois tipos de requisitos:
Os requisitos derivados da maneira como as pessoas realmente trabalham, em vez da maneira pelas quais as definições de processo dizem como elas deveriam trabalhar;
Os requisitos derivados da cooperação e conscientização das atividades de outras pessoas.
Alguns itens importantes que devem ser executados antes, durante e depois do estudo de observação:
Antes, é necessário identificar as áreas de usuário a serem observadas; obter a aprovação das gerências apropriadas para executar as observações; obter os nomes e funções das pessoas chave que estão envolvidas no estudo de observação; e explicar a finalidade do estudo;
Durante, é necessário familiarizar-se com o local de trabalho que está sendo observado. Para isso é preciso observar os agrupamentos organizacionais atuais; as facilidades manuais e automatizadas; coletar amostras de documentos e procedimentos escritos que são usados em cada processo específico que está sendo observado; e acumular informações estatísticas a respeito das tarefas, como: freqüência que ocorrem, estimativas de volumes, tempo de duração para cada pessoa que está sendo observada. Além de observar as operações normais de negócios acima é importante observar as exceções;
Depois, é necessário documentar as descobertas resultantes das observações feitas. Para consolidar o resultado é preciso rever os resultados com as pessoas observadas e/ou com seus superiores.
A análise de observação tem algumas desvantagens como, consumir bastante tempo e o analista ser induzido a erros em suas observações. Mas em geral a técnica de observação é muito útil e frequentemente usada para complementar descobertas obtidas por outras técnicas.
Workshops
Trata-se de uma técnica de elicitação em grupo usada em uma reunião estruturada. Devem fazer parte do grupo uma equipe de analistas e uma seleção dos stakeholders que melhor representam a organização e o contexto em que o sistema será usado, obtendo assim um conjunto de requisitos bem definidos.
Ao contrário das reuniões, onde existe pouca interação entre todos os elementos presentes, o workshop tem o objetivo de acionar o trabalho em equipe. Há um facilitador neutro cujo papel é conduzir a workshop e promover a discussão entre os vários mediadores. As tomadas de decisão são baseadas em processos bem definidos e com o objetivo de obter um processo de negociação, mediado pelo facilitador.
Uma técnica utilizada em workshops é o brainstorming. Após os workshops serão produzidas documentações que refletem os requisitos e decisões tomadas sobre o sistema a ser desenvolvido.
Alguns aspectos importantes a serem considerados: a postura do condutor do seminário deve ser de mediador e observador; a convocação deve possuir dia, hora, local, horário de início e de término; assunto a ser discutido e a documentação do seminário.
Prototipagem
Protótipo tem por objetivo explorar aspectos críticos dos requisitos de um produto, implementando de forma rápida um pequeno subconjunto de funcionalidades deste produto. O protótipo é indicado para estudar as alternativas de interface do usuário; problemas de comunicação com outros produtos; e a viabilidade de atendimento dos requisitos de desempenho. As técnicas utilizadas na elaboração do protótipo são várias: interface de usuário, relatórios textuais, relatórios gráficos, entre outras.
Alguns dos benefícios do protótipo são as reduções dos riscos na construção do sistema, pois o usuário chave já verificou o que o analista captou nos requisitos do produto. Para ter sucesso na elaboração dos protótipos é necessária a escolha do ambiente de prototipagem, o entendimento dos objetivos do protótipo por parte de todos os interessados no projeto, a focalização em áreas menos compreendidas e a rapidez na construção.
Entrevistas
A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê margem ao entrevistado para expor as suas ideias. É necessário ter um plano de entrevista para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados.
As seguintes diretrizes podem ser de grande auxilio na direção de entrevistas bem sucedidas com o usuário: desenvolver um plano geral de entrevistas, certificar-se da autorização para falar com os usuários, planejar a entrevista para fazer uso eficiente do tempo, utilizar ferramentas automatizadas que sejam adequadas, tentar descobrir que informação o usuário está mais interessado e usar um estilo adequado ao entrevistar.
Para planejar a entrevista é necessário que antes dela sejam coletados e estudados todos os dados pertinentes à discussão, como formulários, relatórios, documentos e outros. Dessa forma, o analista estará bem contextualizado e terá mais produtividade nos assuntos a serem discutidos na entrevista.
É importante determinar um escopo relativamente limitado, focalizando uma pequena parte do sistema para que a reunião não se estenda por mais de uma hora. O usuário tem dificuldade de concentração em reuniões muito longas, por isso é importante focalizar a reunião no escopo definido.
Após a entrevista é necessário validar se o que foi documentado pelo analista está de acordo com a necessidade do usuário, que o usuário não mudou de opinião e que o usuário entende a notação ou representação gráfica de suas informações.
A atitude do analista em relação à entrevista é determinar seu fracasso ou sucesso. Uma entrevista não é uma competição, deve-se evitar o uso excessivo de termos técnicos e não conduzir a entrevista em uma tentativa de persuasão. O modo como o analista fala não deve ser muito alto, nem muito baixo, tampouco indiretamente, ou seja, utilizar os termos: ele disse isso ou aquilo na reunião para o outro entrevistado. O modo melhor para agir seria, por exemplo, dizer: O João vê a solução para o projeto dessa forma. E o senhor André, qual é a sua opinião? Em uma entrevista o analista nunca deve criticar a credibilidade do entrevistado. O analista deve ter em mente que o entrevistado é o perito no assunto e fornecerá as informações necessárias ao sistema.
Para elaborar perguntas detalhadas é necessário solicitar que o usuário:
Explique o relacionamento entre o que está em discussão e as demais partes do sistema;
Descreva o ponto de vista de outros usuários em relação ao item que esteja sendo discutido;
Descreva informalmente a narrativa do item em que o analista deseja obter informações;
Perguntar ao usuário se o item em discussão depende para a sua existência de alguma outra coisa, para assim poder juntar os requisitos comuns do sistema, formando assim um escopo conciso.
Pode-se utilizar a confirmação, para tanto o analista deve dizer ao usuário o que acha que ouviu ele dizer. Neste caso, o analista deve utilizar as suas próprias palavras em lugar das do entrevistado e solicitar ao entrevistado confirmação do que foi dito.
Saiba mais sobre entrevistas para coleta de requisitos
Questionários
O uso de questionário é indicado, por exemplo, quando há diversos grupos de usuários quepodem estar em diversos locais diferentes do país. Neste caso, elaboram-se pesquisas específicas de acompanhamento com usuários selecionados, que a contribuição em potencial pareça mais importante, pois não seria prático entrevistar todas as pessoas em todos os locais.
Existem vários tipos de questionários que podem ser utilizados. Entre estes podemos listar: múltipla escolha, lista de verificação e questões com espaços em branco. O questionário deve ser desenvolvido de forma a minimizar o tempo gasto em sua resposta.
Na fase de preparação do questionário deve ser indicado o tipo de informação que se deseja obter. Assim que os requisitos forem definidos o analista deve elaborar o questionário com questões de forma simples, clara e concisa, deixar espaço suficiente para as repostas que forem descritivas e agrupar as questões de tópicos específicos em um conjunto com um título especial. O questionário deve ser acompanhado por uma carta explicativa, redigida por um alto executivo, para enfatizar a importância dessa pesquisa para a organização.
Deve ser desenvolvido um controle que identifique todas as pessoas que receberão os questionários. A distribuição deve ocorrer junto com instruções detalhadas sobre como preenchê-lo e ser indicado claramente o prazo para devolução do questionário. Ao analisar as respostas dos participantes é feito uma consolidação das informações fornecidas no questionário, documentando as principais descobertas e enviando uma cópia com estas informações para o participante como forma de consideração pelo tempo dedicado a pesquisa.
Brainstorming
Brainstorming é uma técnica para geração de ideias. Ela consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem ideias.
As principais etapas necessárias para conduzir uma sessão de brainstorming são:
Seleção dos participantes: Os participantes devem ser selecionados em função das contribuições diretas que possam dar durante a sessão. A presença de pessoas bem informadas, vindas de diferentes grupos garantirá uma boa representação;
Explicar a técnica e as regras a serem seguidas: O líder da sessão explica os conceitos básicos de brainstorming e as regras a serem seguidas durante a sessão;
Produzir uma boa quantidade de ideias: Os participantes geram tantas ideias quantas forem exigidas pelos tópicos que estão sendo o objeto do brainstorming. Os participantes são convidados, um por vez, a dar uma única ideia. Se alguém tiver problema, passa a vez e espera a próxima rodada.
No brainstorming as ideias que a princípio pareçam não convencionais, são encorajadas, pois elas frequentemente estimulam os participantes, o que pode levar a soluções criativas para o problema. O número de ideias geradas deve ser bem grande, pois quanto mais ideias forem propostas, maior será a chance de aparecerem boas ideias. Os participantes também devem ser encorajados a combinar ou enriquecer as ideias de outros e, para isso, é necessário que todas as ideias permaneçam visíveis a todos os participantes.
Nesta técnica é designada uma pessoa para registrar todas as ideias em uma lousa branca ou em papel. À medida que cada folha de papel é preenchida, ela é colocada de forma que todos os participantes possam vê-la.
Analisar as ideias é a fase final do brainstorming. Nessa fase é realizada uma revisão das ideias, uma de cada vez. As consideradas valiosas pelo grupo são mantidas e classificadas em ordem de prioridade.
JAD
JAD (Joint Application Design) é uma técnica para promover cooperação, entendimento e trabalho em grupo entre os usuários desenvolvedores.
O JAD facilita a criação de uma visão compartilhada do que o produto de software deve ser. Através da sua utilização os desenvolvedores ajudam os usuários a formular problemas e explorar soluções. Dessa forma, os usuários ganham um sentimento de envolvimento, posse e responsabilidade com o sucesso do produto.
A técnica JAD tem quatro princípios básicos:
Dinâmica de grupo: são realizadas reuniões com um líder experiente, analista, usuários e gerentes, para despertar a força e criatividade dos participantes. O resultado final será a determinação dos objetivos e requisitos do sistema;
Uso de técnicas visuais: para aumentar a comunicação e o entendimento;
Manutenção do processo organizado e racional: o JAD emprega a análise top down e atividades bem definidas. Possibilita assim, a garantia de uma análise completa reduzindo as chances de falhas ou lacunas no projeto e cada nível de detalhe recebe a devida atenção;
Utilização de documentação padrão: preenchida e assinada por todos os participantes. Este documento garante a qualidade esperada do projeto e promove a confiança dos participantes.
A técnica JAD é composta de duas etapas principais: planejamento, que tem por objetivo elicitar e especificar os requisitos; e projeto, em que se lida com o projeto de software.
Cada etapa consiste em três fases: adaptação, sessão e finalização. A fase de adaptação consiste na preparação para a sessão, ou seja, organizar a equipe, adaptar o processo JAD ao produto a ser construído e preparar o material. Na fase de sessão é realizado um ou mais encontros estruturados, envolvendo desenvolvedores e usuários onde os requisitos são desenvolvidos e documentados. A fase de finalização tem por objetivo converter a informação da fase de sessão em sua forma final (um documento de especificação de requisitos).
Há seis tipos de participantes, embora nem todos participem de todas as fases:
Líder da sessão: é responsável pelo sucesso do esforço, sendo o facilitador dos encontros. Deve ser competente, com bom relacionamento pessoal e qualidades gerenciais de liderança;
Engenheiro de requisitos: é o participante diretamente responsável pela produção dos documentos de saída das sessões JAD. Deve ser um desenvolvedor experiente para entender as questões técnicas e detalhes que são discutidos durante as sessões e ter habilidade de organizar idéias e expressá-las com clareza;
Executor: é o responsável pelo produto sendo construído. Tem que fornecer aos participantes uma visão geral dos pontos estratégicos do produto de software a ser construído e tomar as decisões executivas, tais como alocação de recursos, que podem afetar os requisitos e o projeto do novo produto;
Representantes dos usuários: são as pessoas na empresa que irão utilizar o produto de software. Durante a extração de requisitos, os representantes são frequentemente gerentes ou pessoas-chave dentro da empresa que tem uma visão melhor do todo e de como ele será usado;
Representantes de produtos de software: são pessoas que estão bastante familiarizadas com as capacidades dos produtos de software. Seu papel é ajudar os usuários a entender o que é razoável ou possível que o novo produto faça;
Especialista: é a pessoa que pode fornecer informações detalhadas sobre um tópico específico.
O conceito do JAD de abordagem e dinâmica de grupo poderá ser utilizado para diversas finalidades, como: planejamento de atividades técnicas para um grande projeto, discussão do escopo e objetivos de um projeto e estimativa da quantidade de horas necessárias para desenvolver sistemas grandes e complexos.
A maioria das técnicas JAD funciona melhor em projetos pequenos ou médios. Para um sistema grande e complexo podem ser usadas múltiplas sessões JAD para acelerar a definição dos requisitos do sistema.
Saiba mais sobre as competências para se tornar um Engenheiro de Requisitos
Conclusão
Não existe uma técnica padrão para o processo de levantamento de requisitos. Para alcançar um levantamento de requisitos mais preciso é importante o conhecimento de diversas técnicas para saber que técnica de levantamento aplicar em cada situação.
É primordial que o analista possua perfil adequado. O analista de sistemas precisa de mais do que apenas a capacidade de desenhar fluxogramas e outros diagramas técnicos. O analista de sistemas tem a função de projetar e analisar sistemas de ótimo desempenho. Para que esse objetivo seja alcançado, é necessárioo analista de sistema possuir a capacidade de:
Compreender conceitos abstratos, reorganizá-los em divisões lógicas e sintetizar soluções baseadas em cada divisão;
Absorver fatos pertinentes de fontes conflitantes ou confusas;
Entender os ambientes do usuário/cliente;
Aplicar elementos do sistema de hardware e/ou software aos elementos do usuário/cliente;
Comunicar bem nas formas escrita e verbal e entender o objetivo global do software.
A Tabela 1 apresenta os grupos de técnicas para o levantamento de requisitos.
	Técnicas tradicionais
	São aplicadas em várias áreas do conhecimento. Exemplo: questionários, entrevistas, observação, e análise de documentos.
	Técnicas de elicitação de grupo
	Tem por objetivo compreender melhor o pensamento e comportamento dos grupos e as necessidades dos usuários. Exemplo: brainstorming e as sessões JAD (Joint Application Design).
	Prototipação
	O uso de protótipo auxilia na elicitação e validação dos requisitos de sistema.
A prototipação pode ser utilizada para elicitar requisitos quando há um alto grau de incerteza ou quando é necessário um rápido feedback dos usuários.
	Técnicas contextuais
	Surgiram como uma alternativa para as técnicas tradicionais e cognitivas e inclui técnicas de etnografia e análise social.
Tabela 1. Grupos de técnicas para levantamento de requisitos
Referências
CARVALHO, Adriane M. B. Rizzoni; CHIOSSI, Thelma C. dos Santos. Introdução à engenharia de software. Campinas, SP. Ed UNICAMP, 2001
FILHO, Wilson de Pádua Paula. Engenharia de software Fundamentos, Métodos e Padrões. Rio de Janeiro, RJ. Ed LTC, 2001
FOURNEIR, Roger. Guia prático para desenvolvimento e manutenção de sistemas estruturados. São Paulo. Ed. Makron Books, 1994
POMPILHO, S. Análise Essencial Guia Prático de Análise de Sistemas. Rio de Janeiro: Ed Ciência Moderna Ltda, 1995.
PRESSMAN, Roger S. Engenharia de Software. São Paulo. Ed. Markon Books, 1995
REZENDE, Denis Alcides. Engenharia de software e sistemas de informação. 2.ed. Rio de Janeiro: Ed. Brasport, 2002
SOMERVILLE, I. Engenharia de software. 6° ed. Tradução Maurício de Andrade. São Paulo: Ed Addison-Wesley, 2003
Observação 
Observação é uma técnica em que o engenheiro escuta, vê, “sente”. Nesse caso a fonte de informação é o contexto, ou o local. Nessa técnica o Engenheiro de Requisitos coloca-se numa posição onde possa visualizar num determinado contexto, o comportamento dos atores, como eles lidam com recursos, e com outros atores. 
Seguindo a máxima de Becker, que “pessoas definem atividade”, pode-se observar quais atividades elas desempenham (papéis). Os atores podem também ser agentes não humanos, quando se observa situações com máquinas.
Na observação, o Engenheiro deve tomar nota, tentando extrair o conhecimento da situação (campo visual) registrando os elementos citados: atores/agentes (humanos ou máquinas), os recursos que eles manipulam, e seus papéis (inferindo as atividades desenvolvidas).
A observação é fundamentalmente não participativa, sem interação ou com o mínimo de interação com o campo visual observado. Pode ser necessário, que num mesmo contexto, diferentes campos visuais devam ser utilizados, para evitar uma observação parcial.
A Figura do livro do Prof. Sá Carvalho  (Análise de Sistemas: O Outro Lado da Informática)
Requisitos Propriamente Ditos 
A palavra requisitos pode ter diferentes semânticas.  Três em particular são mais comuns:
A primeira, de cunho geral, que denota um conjunto de informações necessárias para a construção de um software.  Esse conjunto é composto de informações que procuram significar desejos dos que demandam o software e de informações sobre fatos do contexto onde o software irá operar.
A segunda, muito usada na literatura, denota modelos escritos em linguagens artificiais que procuram organizar algumas das informações necessárias para a construção de um software.
A terceira, de cunho específico, denota frases que representam diretivas explícitas a serem levadas adiante pelo software (demanda).  Chamamos essas frases de: Requisitos Propriamente Ditos.
Sobre como representar essas frases (RPD), que devem ser atômicas e com identificador único, leia aqui.