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

Requisitos Externos

São requisitos procedentes de fatores externos ao sistema e ao seu processo de desenvolvimento, como:

• Requisitos Éticos;
• Requisitos Legais (como política de privacidade e direitos autorais);
• Requisitos Reguladores.

Exemplos: o sistema não deverá revelar aos operadores nenhuma informação pessoal sobre os clientes, além de seus nomes e o número de referência (legislação de privacidade); em razão das restrições referentes aos direitos autorais, alguns documentos devem ser excluídos imediatamente ao serem fornecidos; utilização de uma interface padrão utilizando uma determinada norma; disponibilização de arquivos somente para leitura por causa dos direitos autorais.

Etapas da Engenharia de Requisitos

A Engenharia de Requisitos reúne as primeiras atividades a serem realizadas nos diversos modelos de processo de software. Seu objetivo é definir o que deve ser feito e não a forma como será implementado o sistema. Serve como ponte entre o projeto e a construção do software e define as bases do contrato entre o desenvolvedor e o cliente. Realiza a aquisição, o refinamento e a verificação das necessidades do sistema. A meta é sistematizar o processo de definição dos requisitos, obtendo uma especificação correta e completa do sistema para elaboração do DERS (Documento de Especificação de Requisitos de Software).

A Engenharia de Requisitos fornece um mecanismo adequado para entender o que o cliente deseja, analisar as suas necessidades, negociar uma solução adequada ao seu problema, validar a especificação e administrar os requisitos à medida que eles são transformados em um sistema em operação. De acordo com Pressman (2011, p. 127), o processo de ER abrange as etapas de concepção, levantamento, elaboração, negociação, especificação, validação e gestão, que são apresentadas a seguir.

Engenharia de requisitos. Fonte: Danang Setiawan/shutterstock

Concepção ou Estudo de Viabilidade do Sistema

O estudo de viabilidade é um estudo breve, direcionado, que se destina a responder a algumas perguntas:

• O sistema contribui para os objetivos gerais da empresa?
• O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e prazo?
• O sistema pode ser integrado com outros sistemas já em operação?

Após responder essas questões é necessário questionar as fontes de informação (stakeholders). Para isso, são recomendadas algumas perguntas, como:

• Como a empresa se comportaria se esse sistema não fosse implementado?
• Quais são os problemas com os processos atuais e como um novo sistema ajudaria a diminuir esses problemas?
• Que contribuição direta o sistema trará para os objetivos da empresa?
• As informações podem ser transferidas para outros sistemas e também podem ser recebidas a partir deles?
• O sistema requer tecnologia que não tenha sido utilizada anteriormente na empresa?
• O que precisa e o que não precisa ser compatível com a empresa?
• Quem vai usar o sistema?

Após obter essas respostas, deve-se preparar um relatório de viabilidade.

Levantamento dos Requisitos

O levantamento de requisitos busca descobrir mais informações sobre o domínio da aplicação, que serviços o sistema deve oferecer, o desempenho exigido, dentre outros. O levantamento de requisitos pode envolver diferentes tipos de pessoas da empresa, os stakeholders. Frequentemente os clientes não sabem o que querem do sistema computacional, a não ser em termos muito gerais. Costumam expressar os requisitos utilizando seus próprios termos e com o conhecimento implícito de sua área de atuação. Diferentes stakeholders têm em mente diferentes requisitos e podem expressá-los de maneiras distintas. Além disso, fatores políticos podem influenciar os requisitos do sistema. O ambiente econômico e de negócios, no qual a análise de requisitos ocorre, é dinâmico, ou seja, inevitavelmente o ambiente se modifica durante o projeto. Como consequência, a importância dos requisitos específicos pode mudar. Assim, novos requisitos podem surgir por parte dos novos stakeholders, que não haviam sido consultados inicialmente.

Análise de Requisitos

As informações obtidas do cliente durante a concepção e o levantamento são expandidas e refinadas durante a análise (ou elaboração) de requisitos. Esta atividade da ER tem por objetivo desenvolver um modelo técnico refinado das funções, características e restrições do software. É guiada pela criação e refinamento de cenários do usuário que descrevem como o usuário final (e outros atores) vão interagir com o sistema.

Negociação de requisitos. Fonte: Reenya/shutterstock

Negociação dos Requisitos

A negociação categoriza e organiza os requisitos em subconjuntos relacionados. Neste passo, as seguintes perguntas devem ser respondidas:

• Cada requisito está consistente com o objetivo global do sistema?
• Todos os requisitos foram especificados no nível de abstração adequado?
• O requisito é realmente necessário ou representa uma característica adicional que pode não ser essencial para o objetivo do sistema?
• Cada requisito é limitado e não ambíguo?
• Cada requisito tem atribuição (será utilizado por alguém)?
• Algum requisito conflita com outros requisitos?
• Cada requisito é realizável no ambiente técnico?
• Cada requisito pode ser testado quando estiver implementado?
• Qual é a prioridade desse requisito?

Especificação dos Requisitos

Especificação de Requisitos geralmente é um documento escrito, que contém o detalhamento do sistema, os requisitos funcionais e não funcionais e os modelos do sistema que podem ser representados por meio de diagramas como IDEF0 (Integration Definition for Function Modeling), diagramas de casos de uso da UML (Unified Modeling Language), diagramas de classes preliminar, diagramas de sequência e prototipação.

Validação dos Requisitos

A validação de requisitos examina a especificação de requisitos para garantir que todos os requisitos do sistema tenham sido identificados e detalhados, que as inconsistências, omissões e erros tenham sido detectadas e corrigidas e que as prioridades tenham sido estabelecidas. Tem a função de mostrar que os requisitos realmente definem o sistema que o cliente deseja. São realizadas diversas verificações, como:

• Verificações de validade: Um usuário pode pensar que um sistema é necessário para realizar certas funções, mas mais estudos e análises podem identificar funções adicionais ou diferentes necessárias.
• Verificações de consistência: Os requisitos em um documento não devem ser conflitantes, ou seja, não devem existir restrições contraditórias ou descrições diferentes para uma mesma função do sistema.
• Verificações de completeza: O documento de requisitos (DERS) deve incluir requisitos que definam todas as funções e restrições exigidas pelo usuário do sistema.
• Verificações de realismo: Utilizando o conhecimento da tecnologia existente, os requisitos devem ser verificados, a fim de assegurar que eles realmente podem ser implementados. Essas verificações devem também levar em conta o orçamento e os prazos para o desenvolvimento do sistema.
• Facilidade de verificação: Para reduzir o potencial de divergências entre cliente e desenvolvedor, os requisitos do sistema devem sempre ser escritos de modo que possam ser verificados. Isso significa que um conjunto de verificações pode ser projetado para mostrar que o sistema entregue cumpre com esses requisitos, como:
• O requisito é realmente passível de ser testado, como foi definido?
• O requisito pode ser adequadamente compreendido pelos compradores ou usuários finais do sistema?
• A origem do requisito é claramente definida?
• O requisito é adaptável?
• Ele pode ser modificado sem que isso provoque efeitos em grande escala em outros requisitos do sistema?

De acordo com Pressman (2011, p. 381) um dos mecanismos de validação de requisitos é a RTF (Revisão Técnica Formal). Em uma RTF com esse propósito, a equipe de desenvolvimento deve conduzir o cliente pelos requisitos do sistema, explicando as implicações de cada requisito. A equipe de revisão deve verificar cada requisito, em termo de sua consistência e verificar os requisitos como um todo sob o ponto de vista de sua completeza. A RTF é uma atividade que garante a qualidade do software.

Gestão de Requisitos

 

 

Gestão de requisitos. Fonte: Iconic Bestiary/shutterstock

Gestão de Requisitos é um conjunto de atividades que ajuda a equipe de projeto a identificar, controlar e rastrear requisitos e modificações de requisitos a qualquer momento no desenvolvimento do sistema. Para auxiliar na gestão de requisitos tabelas de rastreamento são criadas com o objetivo de verificar as relações entre requisitos e o impacto da mudança de requisitos. Os requisitos mudam e há uma série de razões para isso, como: os problemas podem ser muito intricados, as especificações podem ficar incompletas, o aumento do entendimento do sistema ocorre ao longo do projeto,como há vários usuários, há várias visões,  quem paga pelo sistema geralmente é diferente de quem o usa, a empresa e o ambiente se modificam e, na medida em  que os  usuários se familiarizam com o sistema, novos requisitos surgem. A gestão de requisitos precisa de apoio automatizado, como ferramentas CASE (Computer Aided Software Engineering), para:

• Armazenamento de requisitos: os requisitos devem ser mantidos em um depósito de dados seguro, gerenciado, que seja acessível por todos os envolvidos no processo de engenharia de requisitos.
• Gerenciamento de mudanças: esse processo pode ser simplificado se o apoio de ferramentas estiver disponível.
• Gerenciamento de facilidade de rastreamento: o apoio de ferramentas para a rastreabilidade permite que requisitos relacionados sejam descobertos.

Sommerville (2011, p. 70) apresenta as atividades de Engenharia de Requisitos, conforme ilustra a figura.

Visão em espiral das atividades da Engenharia de Requisitos

Fonte: SOMMERVILLE (2011, p. 70)

O autor define a ER como um conjunto de atividades que visam avaliar se o sistema é útil para a organização (estudo de viabilidade), realizar o levantamento de requisitos (elicitação e análise), converter os requisitos para um padrão (especificação) e verificar se realmente os requisitos são capazes de definir o que o cliente deseja (validação). Essas atividades são organizadas em torno de uma espiral, como um processo iterativo, cuja saída resulta no DERS (Documento de Especificação de Requisitos de Software).

Requisitos de Produto

 São requisitos que especificam ou restringem o comportamento do produto, como:

• Requisitos de Usabilidade: referem-se ao esforço para utilizar ou aprender a utilizar o produto. Estão relacionados com a interação do usuário junto ao sistema.
• Requisitos de Confiabilidade: referem-se à frequência de ocorrência de falhas e recuperabilidade em caso de falha, como: tempo médio de falhas; probabilidade de indisponibilidade; taxa de ocorrência de falhas; tempo de reinício após falha; percentual de eventos causando falhas; probabilidade de corrupção de dados após falha.
• Requisitos de Eficiência: incluem os Requisitos de Espaço e os Requisitos de Desempenho do sistema e estão associados à eficiência, uso de recursos e tempo de resposta da aplicação, como: transações processadas/segundo; tempo de resposta do usuário/evento, entre outros.
• Requisitos de Proteção: são relativos às regras de segurança da informação que garantem a proteção da informação.

Requisitos Organizacionais

São requisitos derivados das políticas organizacionais do cliente e do desenvolvedor, como:

• Requisitos Operacionais: ligados às restrições de software e hardware usados para desenvolver ou executar o sistema.
• Requisitos de Desenvolvimento: referem-se à definição da linguagem de programação e às normas que devem ser seguidas pelo sistema ou no processo de desenvolvimento, bem como as regras de codificação.
• Requisitos Ambientais: referem-se ao modo como será implantada a solução nos ambientes do usuário, como configurações necessárias e ordem de instalação dos pacotes, capacidade de transferir o produto para outros ambientes etc.

Requisitos Funcionais e Não Funcionais

Os requisitos de software são classificados como funcionais e não funcionais, mas os não funcionais ainda apresentam uma subclassificação. Uma breve descrição destes tipos de requisitos é apresentada a seguir, com base em Sommerville (2011).

Requisitos de software

Fonte: alphaspirit/shutterstock

Requisitos Funcionais

São requisitos que descrevem o que o sistema deve fazer, ou seja, sua funcionalidade (funções que o sistema deve realizar) ou os serviços que se espera que o sistema faça. Quando definidos como requisitos de usuários, os requisitos funcionais são expressos de forma mais abstrata para facilitar sua compreensão. Mas requisitos funcionais de sistema podem detalhar mais as funções do sistema, suas entradas e saídas, exceções etc. Exemplos de requisitos funcionais:

• O usuário deve ser capaz de pesquisar as listas com os agendamentos de atendimento.
• O sistema deve gerar, diariamente, a lista com os agendamentos de clientes.
• Cada usuário do sistema deve ser identificado pelo número de identificação de 8 dígitos.
• O sistema deve solicitar uma senha de acesso de cada usuário.

Requisitos Não Funcionais

São requisitos que não dizem respeito diretamente à funcionalidade do sistema, mas expressam propriedades do sistema e/ou restrições sobre os serviços ou funções por ele providas. Incluem propriedades do sistema como confiabilidade, disponibilidade, desempenho, segurança etc., capacidade dos dispositivos de E/S, tempo de resposta, representações de dados do sistema, detalhes técnicos de softwares e ferramentas, linguagens de programação etc.

Sua classificação é abrangente e é mostrada na figura.

Classificação dos requisitos não funcionais. Fonte: Sommerville (2011, p. 61)