Processos podem ser vistos como uma transformação de entradas em um conjunto de saídas bem definidas através da aplicação de uma série de atividades.
Uma característica dos processos de engenharia de requisitos é que são muito variáveis. Eles variam de processos não estruturados que são dependentes da experiência das pessoas envolvidas, para processos sistemáticos baseados na aplicação de alguma metodologia de análise. Estes processos sistemáticos são, em princípio, mais independentes das pessoas envolvidas, embora ainda necessitem de uma boa quantidade de julgamento pessoal.
Existe uma gama de fatores que contribuem para a variabilidade dos processos de engenharia de requisitos [9].
• Maturidade Técnica: os tecnologias e métodos utilizados para engenharia de requisitos variam de uma organização para outra.
• Envolvimento das disciplinas: os tipos de disciplinas de engenharia e gerencial envolvidas na engenharia de requisitos variam de uma organização para outra.
• Cultura organizacional: a cultura de uma organização tem importante efeito em todos os processos de negócio e, como a cultura varia, o mesmo ocorre com o processo de engenharia de requisitos.
• Domínio de aplicação: diferentes tipos de sistemas necessitam de diferentes tipos de processos de engenharia de requisitos.
Segundo XEXÉO [8], o cliente vive em um ambiente de evolução permanente, onde novos desafios e oportunidades, novos problemas e restrições surgem com freqüência. Isso cria a necessidade de um processo de realimentação ao longo de todo o ciclo de desenvolvimento do projeto, proporcionando a oportunidade de modificar requisitos já estabelecidos a partir da detecção de novas informações. A Elicitação de Requisitos é repetida ao longo do projeto, como conseqüência do aumento do conhecimento sobre o domínio, alterações nos limites tecnológicos e o aumento do entendimento do problema por parte dos clientes. A realimentação está presente durante o próprio ciclo de elicitação, no momento em que um requisito precisa ser modificado para atender a uma nova expectativa ou pela adoção de outro requisito. O conceito de divisão dos requisitos em iterações, segundo SOMMERVILLE e KOTONYA [9], é representado na Figura 2.1, a seguir.
Figura 2.1: Modelo Espiral do Processo de Engenharia de Requisitos [9]
O modelo espiral é realizado, passando pelos quatro quadrantes, proporcionando entradas e obtendo artefatos de saída ao fim de cada fase. Ao termino do primeiro ciclo os artefatos gerados, sendo o documento de requisitos o principal. Ele e os demais artefatos são validados e caso seja acordado entre os stakeholders, o processo de requisitos é finalizado, dando início à próxima etapa do processo de desenvolvimento de software. Caso exista algum conflito de interesse ou problemas nos requisitos, um novo ciclo no modelo espiral pode ser executado.
A dinâmica da economia atual e a volatilidade do interesse dos clientes fazem com que os modelos do processo de requisitos que refletem sua natureza iterativa e a falta da condição de terminação facilmente definida tornem-se populares.
As principais fases do processo de Engenharia de Requisitos são:
• Elicitação de Requisitos
• Análise e Negociação de Requisitos
• Documentação de Requisitos
• Validação de Requisitos
Em paralelo às fases citadas, é executado permanentemente o processo de Gerência de Requisitos que é responsável pelo gerenciamento de mudanças dos requisitos. Mudanças nos requisitos são inevitáveis quando a prioridade do negócio muda, quando erros ou omissões nos requisitos são descobertos e quando novos requisitos emergem. A intenção da Gerência de Requisitos é manter rastreamento destas mudanças e garantir que mudanças são realizadas no documento de requisitos de uma maneira controlada.
As principais fases do processo de Engenharia de Requisitos serão analisadas com mais detalhes abaixo.
2.2.1 Elicitação de Requisitos
Elicitação de requisitos é o nome usual dado às atividades envolvidas na descoberta de requisitos do sistema. Desenvolvedores e engenheiros de requisitos trabalham junto aos clientes e usuários finais para descobrir qual problema deve ser resolvido, quais os serviços o sistema deve prover, o desempenho desejado, restrições de sistemas, e outros. No entanto, a elicitação de requisitos não envolve apenas perguntar as pessoas o que elas desejam, requer uma análise minuciosa da organização, do domínio da aplicação e processos de negócio onde o sistema será inserido. Portanto, existem quatro dimensões que a elicitação de requisitos deve atacar [9]:
• Entendimento do domínio da aplicação: conhecimento do domínio da aplicação é conhecimento da área geral onde o sistema é aplicado.
• Entendimento do problema: os detalhes do problema específico do cliente onde o sistema será aplicado devem ser entendidos.
• Entendimento do negócio: sistemas são geralmente intencionados a contribuir de alguma forma para o desenvolvimento de um negócio ou organização. É necessário entender como estes sistemas se interagem e afetam diferentes partes do negócio e como eles podem contribuir para os objetivos gerais do negócio.
• Entendimento das necessidades e restrições dos stakeholders do sistema: stakeholders do sistema são aquelas pessoas que são afetadas de alguma forma pelo sistema. Eles podem ser usuários finais do sistema, gerentes do departamento onde o sistema será implantado, entre outros. É necessário entender, em detalhes, suas necessidades específicas para suporte do sistema em seu trabalho.
Um bom processo de elicitação de requisitos deveria incluir quatro atividades críticas [9]. Estas atividades são exemplificadas na Figura 2.2.
• Estabelecimento dos objetivos: os objetivos gerais da organização devem ser estabelecidos neste estágio.
• Aquisição de conhecimento base: este é um estágio muito importante onde os engenheiros de requisitos coletam e entendem informações base sobre o sistema.
• Organização do conhecimento: a grande quantidade de conhecimento que tem sido coletada nos estágios anteriores deve ser organizada e correlacionada.
• Coleta dos requisitos dos stakeholders: envolve consultar stakeholders do sistema para descobrir seus requisitos.
Figura 2.2: Um processo genérico de Elicitação de Requisitos [9]
Existe uma coleção de técnicas que vêm sendo utilizadas pelos engenheiros de requisitos durante a elicitação de requisitos do software. Destacaremos algumas das técnicas de elicitação de requisitos propostas até o momento que vêm oferecendo importantes contribuições para a Engenharia de Requisitos, em geral, e para a elicitação de requisitos, em particular. A Tabela 2.1 apresenta algumas técnicas, mostrando uma definição de cada técnica, suas vantagens e desvantagens [10].
Técnica Definição Vantagem Desvantagem
Introspecção É o ato de “imaginar”
como deveria ser um
Questionário Útil na elicitação de
Técnica Definição Vantagem Desvantagem
Entrevista Existem basicamente
Análise de
Tabela 2.1: Técnicas de Elicitação de Requisitos [9]
2.2.2 Análise e Negociação de Requisitos
A análise e negociação dos requisitos estão relacionadas com a avaliação de alto nível dos requisitos elicitados junto aos stakeholders. Engenheiros de requisitos
Técnica Definição Vantagem Desvantagem
Prototipação Consiste na
A saída do processo de elicitação de requisitos deve ser um documento rascunho que descreve os requisitos do sistema. Este documento passa pela fase de análise para descobrir problemas e conflitos na definição dos requisitos. Conflitos e sobreposições são quase inevitáveis, então deve existir um estágio de negociação, no qual diferentes stakeholders do sistema são envolvidos para resolver estes conflitos e acordar em um conjunto de requisitos.
SOMMERVILLE e KOTONYA [9] apresentam um modelo geral para o processo de análise e negociação. Este modelo pode ser visualizado na Figura 2.3.
O objetivo da análise de requisitos é encontrar problemas no documento de rascunho de requisitos. As atividades que fazem tipicamente parte da análise de requisitos são descritas abaixo.
• Checagem da necessidade: a necessidade para o requisito é analisada. Em alguns casos, os requisitos propostos podem não contribuir para os objetivos do negócio da organização ou para o problema específico a ser endereçado pelo sistema.
• Checagem da consistência e da completude: é realizada uma checagem cruzada dos requisitos para avaliar a consistência e a completude.
Consistência significa; que nenhum requisito deve ser contraditório;
completude significa a grau de detalhamento que um requisito possui.
• Checagem da viabilidade: os requisitos são checados para garantir que eles são viáveis no contexto do orçamento e cronograma disponíveis para o desenvolvimento do sistema.
As atividades do processo de análise de requisitos resultam na identificação de um conjunto de requisitos (requisitos não necessários, requisitos conflitantes e incompletos, requisitos inviáveis) que são discutidos no processo de negociação de requisitos. As atividades do processo de negociação de requisitos são detalhadas abaixo e podem ser visualizadas na Figura 2.3.
• Discussão dos requisitos: requisitos que tem sido levantado como problemáticos são discutidos e os stakeholders envolvidos apresentam suas visões sobre os requisitos.
• Priorização dos requisitos: requisitos disputados são priorizados para identificar requisitos críticos e para ajudar no processo de tomada de decisão.
• Acordo dos requisitos: soluções para os problemas dos requisitos são identificadas e um conjunto compromissado de requisitos é acordado.
Figura 2.3: Processo de Análise e Negociação de Requisitos [9]
Algumas técnicas gerais para análise são:
• Checklist: uma lista de recordações para pensar sobre e usar para avaliar cada requisito.
• Matriz de interação ou dependência: uma matriz bidimensional onde cada requisito é comparado com todos os outros requisitos para avaliação sobre
A Tabela 2.2 apresenta alguns itens interessantes de um checklist de análise proposto por SOMMERVILLE e KOTONYA [9].
Item do Checklist Descrição
Design Prematuro Os requisitos incluem projeto prematuro ou informação de implementação?
Item do Checklist Descrição
Requisitos Combinados A descrição do requisito descreve um único requisito ou pode ser quebrado em vários requisitos diferentes?
Requisitos não necessários Os requisitos são realmente necessários ao sistema?
Uso de hardware não padrão Os requisitos fazem uso de hardware ou software não padrão?
Conformidade com objetivos do negócio Os requisitos estão consistentes com os objetivos do negócio definidos?
Requisitos ambíguos Os requisitos são ambíguos, isto é, podem ser lidos em maneiras diferentes por pessoas diferentes?
Requisitos realistas Os requisitos estão realistas dada a tecnologia que será usada para implementar o sistema?
Tabela 2.2: Itens do Checklist de Análise [9]
2.2.3 Documentação de Requisitos
A Documentação de Requisitos visa representar os resultados da Engenharia de Requisitos em um documento oficial e formal, contendo os requisitos do software que descrevem o que o mesmo vai fazer em um nível apropriado de detalhes, sem descrever como fazê-lo.
Segundo SOMMERVILLE e KOTONYA [9], a linguagem natural é a única que pode ser entendida por todos os envolvidos. Dessa forma, é muito interessante que ela seja utilizada na documentação dos requisitos. No entanto, ele não descarta a utilização de diagramas e gráficos como forma de facilitar o entendimento dos requisitos. Por outro lado, apesar da linguagem natural poder ser entendida por todos os participantes do processo de requisitos, ela apresenta um alto grau de ambigüidade, o que favorece o aparecimento de inconsistências.
O documento de requisitos, também chamado de Especificação de Requisitos de Software (ERS), conforme a norma IEEE 830-1998 [16] deve ser:
• Correto: uma ERS é correta se, e somente se, cada requisito documentado é aquilo que o software deve possuir;
• Não ambíguo: uma ERS não é ambígua se, e somente se, cada requisito documentado tem apenas uma interpretação;
• Completo: uma ERS é completa se, e somente se, ela inclui os seguintes elementos: todos os requisitos significativos; definição de todas as respostas do software para todas as classes de entrada de dados realizáveis; todas as legendas e referências às figuras, tabelas, etc e definição de todos os termos e unidades de medidas;
• Internamente consistente: uma ERS é internamente consistente se, e somente se, nenhum subconjunto de requisitos individuais descrito estiver conflitante;
• Graduado por importância e estabilidade: para tanto, cada requisito de uma ERS deve possuir um identificador para indicar sua importância e estabilidade;
• Verificável: uma ERS é verificável se, e somente se, cada requisito documentado é verificável;
• Modificável: uma ERS é modificável se, e somente se, sua estrutura e estilo são tais que qualquer mudança nos requisitos possa ser feita de maneira fácil, completa e consistente, enquanto se mantém a estrutura e estilo originais do documento;
• Rastreável: uma ERS é rastreável se a origem de cada um de seus requisitos está clara e se ela facilita a referência de cada requisito no desenvolvimento futuro ou em documentos de apoio.
Essas características estão diretamente relacionadas à qualidade de um Documento de Requisitos, que envolve aspectos relativos ao controle da qualidade dos artefatos de software produzidos no processo de requisitos [17].
Em relação ao conteúdo de uma ERS, existe a dependência de diversos fatores, como por exemplo, a natureza do sistema que está sendo especificado, o nível de detalhamento dos requisitos, práticas organizacionais, além de restrições orçamentárias e de tempo disponível ao processo de Engenharia de Software [12].
Para se estruturar o conteúdo, é necessário que a organização de software defina seus modelos de documentos de requisitos de acordo com as características de classes de projeto. Para isso, pode-se, por exemplo, partir de um modelo como o proposto pelo padrão IEEE 830-1998 [16] e adequá-lo às necessidades organizacionais.
A construção de uma ERS de qualidade conduz a vários ganhos nas próximas atividades do processo de desenvolvimento, uma vez que esse documento será utilizado, maciçamente, como insumo para essas atividades. TOGNERI [18]
destaca que, dentre outros, o documento de requisitos facilita a comunicação entre os envolvidos no desenvolvimento de software, fornece uma base para validação e verificação, e serve como base para futuras modificações ou incremento de novas funcionalidades.
2.2.4 Validação de Requisitos
Após o documento de requisitos ter sido produzido, inicia-se o processo de validação, buscando determinar se os requisitos estão corretos, ou seja, descritos de forma apropriada, procurando eliminar problemas de incompleteza, ambigüidade e inconsistência. A preocupação maior desta fase é com a qualidade do documento de requisitos produzido [11].
Validação de requisitos visa garantir que os requisitos reflitam a funcionalidade levantada pelos clientes. A atividade de validação de requisitos requer que analistas, usuários e especialistas do domínio estejam envolvidos na aprovação do documento final de requisitos.
A principal técnica utilizada na validação de requisitos é basicamente aquela utilizada em outras atividades do processo de software: revisões. Além desta técnica, são também utilizadas validação por Protótipos, Validação de Modelos e Teste. A seguir serão detalhadas as técnicas: Revisões e Protótipos.
Revisões
LOPES [12] define esta técnica de validação de requisitos da seguinte forma:
“Revisões consistem de reuniões estruturadas onde um grupo de pessoas, prévia e cuidadosamente escolhidas, após lerem e analisarem o documento de requisitos se reúnem para discutir os problemas encontrados e chegam a uma solução de consenso em relação às ações a serem adotadas para corrigi-los”.
Esta técnica exige formalização das reuniões, documentando tudo o que foi discutido para melhor andamento das discussões. Exige-se também um rigoroso critério de seleção dos participantes deste processo. Pessoas com diferentes bases de conhecimento trazem mais experiência à reunião de revisão e torna mais provável a identificação de problemas nos requisitos. Além disso, ao discutir os problemas identificados com profissionais de outras especializações, os stakeholders tendem a entender melhor as razões para as mudanças nos requisitos por eles propostos [11].
SOMMERVILLE e KOTONYA [9] apresentam um modelo simples de processo
Figura 2.4: Processo de Revisão [9]
1 Planejar a revisão: o time de revisão é selecionado e um horário e local para o encontro de revisão é escolhido.
2 Distribuir documentos: o documento de requisitos e quaisquer outros documentos relevantes são distribuídos para os membros do time de revisão.
3 Preparar para revisão: os revisores individuais lêem o documento de requisitos para identificar conflitos, omissões, inconsistências, desvios dos padrões e quaisquer outros problemas.
4 Realizar encontros de revisão: os comentários individuais e problemas são discutidos e um conjunto de ações para endereçar os problemas é acordado.
5 Executar ações: o chefe de revisão checa que as ações acordadas estão sendo realizadas.
6 Revisar documento: o documento de requisitos é revisado para refletir as ações acordadas. Neste estágio, ele pode ser aceito ou ele pode ser re-revisado.
Desenvolvimento de Protótipos
Com o auxílio de um stakeholder, um desenvolvedor tem a possibilidade de construir protótipos para validar um conjunto de requisitos. Este tipo de validação não se restringe a realização de discussões de interfaces com o usuário. Um protótipo simula uma parte do sistema e pode ser desenvolvido de diversas maneiras.
Se possível, use uma ferramenta de simulação que garanta que o cliente não espere utilizar o protótipo no produto final – jogue fora o protótipo. Se o desenvolvedor achar que há alguma possibilidade de reutilização do protótipo, ele deve ser avaliado da mesma maneira como avaliamos a reutilização de código, planos, modelos, testes, e assim por diante [11].
Um protótipo para validação dos requisitos deverá incluir um número razoável de facilidades para possibilitar o uso prático do sistema. Caso contrário, os stakeholders não poderão utilizar o sistema de uma forma natural, invalidando o esforço de validação [12].
Os protótipos são construídos na maioria das vezes para simular importantes interfaces e as principais funcionalidades do sistema pretendido, não necessariamente em ambientes similares aos de produção. Eles, em sua grande maioria, não incluem tratamento de erros, respostas corretas a entradas inválidas ou encerramento claro de um processo [13].
LOPES [12] sugere que caso seja escolhida a prototipação como técnica de elicitação dos requisitos, a posterior validação destes requisitos poderá ser através do protótipo construído. Os requisitos de um sistema nem sempre são totalmente descritos, nem totalmente entendidos. Prototipação auxilia o cliente na formalização e solidificação dos requisitos do sistema.
2.2.5 Gerenciamento de Requisitos
Uma vez que os requisitos são passíveis de alteração por uma série de motivos, tem-se, portanto, a necessidade de uma atividade que apóie as demais
gerenciar as mudanças nos requisitos para que todas as alterações sejam feitas de forma consistente e controlada. Essa atividade é a Gerência de Requisitos.
Requisitos podem sofrer alterações de várias naturezas e SOMMERVILLE [19] destaca quatro tipos de requisitos voláteis:
• Requisitos mutáveis: são aqueles que se modificam devido a mudanças no ambiente do sistema;
• Requisitos emergentes: são os que emergem à medida que a compreensão do sistema aumenta;
• Requisitos conseqüentes: são os que resultam da introdução do sistema computadorizado;
• Requisitos de compatibilidade: são aqueles que dependem de outros sistemas ou processos organizacionais.
Ao surgir uma necessidade de alteração em um ou mais requisitos, basicamente, o que necessita ser feito é registrar uma solicitação de mudança, que deve ser avaliada por algum membro da equipe do projeto de software. Nessa avaliação, o impacto da alteração deve ser determinado e valores de custo, esforço, tempo e viabilidade devem ser repassados ao solicitante da mudança.
Para determinar o impacto de uma alteração em um requisito, deve ser possível, por exemplo, saber quais são os requisitos dependentes desse requisito e em quais artefatos do processo de desenvolvimento esse requisito é tratado.
Portanto, é necessário estabelecer uma rede de ligações de modo que um requisito e os elementos ligados a ele possam ser rastreados. Surge, então, o conceito de rastreabilidade.
Rastreabilidade
Segundo JARKE [20] a rastreabilidade de requisitos está emergindo como uma eficiente ponte que possibilita unir evolução de sistemas com necessidades de mudança dos interessados (stakeholders).
A rastreabilidade de requisitos é possível, basicamente, se houver ligações entre requisitos, e entre requisitos e outros elementos do processo de software.
Dessa forma, a identificação das dependências entre requisitos, de requisitos conflitantes, da origem dos requisitos e de seus interessados, além da identificação de em qual artefato (documento, módulo, diagrama, componente, etc) produzido durante o desenvolvimento de software um requisito é tratado, é de fundamental importância para que a rastreabilidade possa ser implantada [21], [22], [9].
SOMMERVILLE e KOTONYA [9] classificaram quatro tipos de informações de rastreabilidade interessantes para que uma análise de impacto de mudanças possa ser feita mais facilmente:
• Regressiva a partir dos requisitos (backward-from traceability): relaciona requisitos com suas origens em outros documentos ou pessoas;
• Progressiva a partir dos requisitos (forward-from traceability): relaciona requisitos aos artefatos de projeto e implementação;
• Regressiva em direção aos requisitos (backward-to traceability):
relaciona artefatos de projeto e implementação aos requisitos;
• Progressiva em direção aos requisitos (forward-to traceability): relaciona outros documentos (os quais podem ter precedido o documento de requisitos) aos requisitos relevantes.
Segundo LOPES [12], “a dificuldade envolvida com a rastreabilidade está no grande volume de informações gerado. As informações do processo de requisitos
Segundo LOPES [12], “a dificuldade envolvida com a rastreabilidade está no grande volume de informações gerado. As informações do processo de requisitos