Resumo

Neste artigo é apresentada uma declaração do que vem a ser requisito e qual a sua importância no contexto de desenvolvimento de software. É detalhada uma abordagem recursiva (requisitos para o conhecimento dos requisitos de desenvolvimento de software), como um auto-exercício para aplicação dos conceitos tratados e apresentados. São especificados os objetivos do trabalho, a motivação pelo tema adotado e o foco e abrangência do trabalho.

Este artigo corresponde ao primeiro de uma série de artigos referentes à extração de requisitos, que será apresentada em edições posteriores. Nos próximos (como explicitado em próximos passos) serão tratados os tópicos sobre o estado da arte na engenharia de requisitos, o conhecimento do problema na engenharia de requisitos, o modelo de qualificação da fonte de informação e do requisito, a aplicação prática do modelo e o relato dos resultados obtidos.

Palavras-chave: ambiente, aplicação, atributo, domínio, expectativa, prefe-rência, prioridade, problema, produto, requisito, restrição, stakeholder .

Produzir software é um processo que envolve muitas pessoas e consome muitos recursos. O termo software é adotado no trabalho em substituição à palavra sistema, cujo significado é muito abrangente e de aplicação comum a variados contextos. Sendo assim, toda vez em que estiver referido software, traduza-se como uma ferramenta de suporte à solução de problema com o uso da tecnologia de informática. Isto pressupõe, também, como verdadeira a afirmação que, independente das características de forma, conteúdo, tecnologia e aplicação, a abrangência da denominação software refere-se à linguagem aplicável à automatização do funcionamento das máquinas. Utiliza-se o termo máquina para qualquer aparelho ou instrumento próprio para produção ou geração de serviço que admita a programação de atividades sistematizadas.

O processo produtivo pertinente à área denominada Engenharia de Software [LEI94] (Software Engineering) fundamenta-se em procedimentos sistematizados compostos de métodos, técnicas, padrões, medições, validações e o gerenciamento de qualidade do produto e do próprio processo.

O universo de pessoas envolvidas no processo produtivo, também denominado stakeholder [KOT98, MAC96, SID96, SOM97] abrange aqueles que, direta ou indiretamente, influenciam ou são afetados pelo software. Ou seja, o pessoal envolvido com os processos de definição, criação, desenvolvimento, gerenciamento, comercialização, bem como o pessoal identificado como cliente e usuário demandante do produto ou simplesmente qualquer usuário compulsório.

Os recursos envolvidos na produção de software abrangem investimentos de ordem financeira e tecnológica, de capacitação de recursos humanos, tanto para o processo produtivo quanto para a implementação do software no ambiente operacional de forma integrada ao hardware e à infra-estrutura de comunicação.

Embora haja uma oferta incessante de inovações tecnológicas no mercado, os recursos humanos são insuficientes para construir software que possa satisfazer a demanda das necessidades ou desejos de cada cliente. Sendo assim, é necessário o conhecimento das exigências e condições que são essenciais nas organizações para, de maneira seletiva, priorizar a implementação destas necessidades.

A abordagem sistemática deste conhecimento é apoiada por uma área específica da Engenharia de Software, denominada Engenharia de Requisitos (Requirements Engineering), cujo elemento constituinte é a descrição de requisitos com o foco no conhecimento do problema (o que é, com quais características).

O tema deste trabalho baseia-se nos aspectos relatados.

Para o melhor entendimento do que vem a ser requisito e qual a sua importância no contexto de desenvolvimento de software, é detalhada na seqüência uma abordagem recursiva (requisitos para o conhecimento dos requisitos de desenvolvimento de software), como um auto-exercício para aplicação dos conceitos tratados e apresentados na continuidade desta introdução. Os tópicos, conforme a figura 1.1 compreendem: ambiente ou domínio da aplicação, problema, requisitos, aplicação, produto, atributos, restrições, preferências e expectativas. Alguns dos conceitos e a abordagem de esclarecimentos de expectativas são apresentados por Gause [GAU89], como integrantes do processo de exploração de requisitos.

2.1 Ambiente ou Domínio da Aplicação

O ambiente ou domínio da aplicação é onde ocorrem os fenômenos que caracterizam os problemas referentes aos requisitos particulares do cliente.

A dinâmica social e organizacional do fator humano, a universalidade dos fatores econômicos e políticos, tendo como pano de fundo o avanço tecnológico, impõem ao processo de produção de software um tratamento cada vez mais complexo. A competitividade dos fatores produtivos depara-se em questões básicas de sobrevivência organizacional do produtor de software, tais como a política de atendimento às mudanças de necessidades ou desejos do demandante do produto durante o ciclo de vida do software. Outro fator que se faz presente é a exigência do mercado na obtenção de produto adequado, no momento certo e a custo reduzido. Isto se aplica necessariamente também às soluções de software do tipo feito em casa, pois as organizações estão em alerta aos fatores de custos de produção e de benefícios associados e aos investimentos em software, hardware e tecnologia de comunicação do ambiente de solução.

O cliente vive em um ambiente de contínuas mudanças, que podem ser traduzidas em oportunidades de negócios ou agregação de novos problemas e restrições. Portanto, a solução de software atual nem sempre estará adequada a demandas futuras. Conseqüentemente, a mudança será inevitável.

É evidente que satisfazer necessidades ou desejos vai depender da vontade de solução do problema pelo demandante. Nem sempre o produto resultante é um novo software. Pode simplesmente ser uma característica adicional, uma substituição para uma versão mais eficaz da solução existente. O software produto com certeza deve ser adequado à demanda de quem irá utilizá-lo.

Como produzir software no tempo certo, do tamanho exato e a baixo custo, adequado às características de qualidade exigidas para o produto?

Como atender o universo de stakeholder, tendo como cenário as dificuldades inerentes ao contexto organizacional, tais como:

• administração de conflitos de interesses e de poder;

• definição do que é prioritário no interesse da organização;

• delimitação da fronteira de aplicação da solução;

• conhecimento do universo de stakeholder atual e futuro;

• gerenciamento continuado da dinâmica dos requisitos para alinhamento às mudanças organizacionais;

• restrições de recursos de produção quer sejam humanos, financeiros ou tecnológicos?

Como evitar erros típicos na produção de software, relativos a fatos incorretos, omissões, inconsistências e ambigüidades?

Por que requisitos?

Erros em definição de requisitos são os fatores mais comuns do insucesso de projetos de software, acarretando altos custos e insatisfação do cliente.

Segundo Shelton [SHE92], os erros na fase de requisitos são extremamente caros de reparar. Em seu estudo de um projeto da Força Aérea dos EUA, os erros foram classificados segundo suas fontes. Os erros citados concentram-se na fase inicial de estudos. Destes, 41% referem-se à definição de requisitos, 28% a projeto lógico e varia em torno de 6% a 5% os demais fatores como: dados, interface, ambiente e pessoas, ficando a documentação com 2%.

Conhecer sobre o que trata o assunto em questão e quais os fenômenos presentes no ambiente são as condições fundamentais para a descrição de requisitos. Portanto, é necessário:

• conhecer o domínio da aplicação, o ambiente onde os requisitos dos clientes são encontrados, a definição do alvo do problema e a abrangência do domínio da solução;

• identificar o problema a resolver, promovendo o entendimento, a especialização e o domínio do conhecimento, compreendendo: o quê, com quê, para quê e para quem;

• delimitar o contexto do negócio do cliente, estabelecendo objetivos, dominando assuntos organizacionais, fatores políticos, conflitos de poder, relações de influência, entendendo o histórico e estrutura organizacional e a organização do conhecimento acerca da organização;

• identificar qual o universo de fonte de informação (stakeholder);

• identificar as exigências e condições para satisfação das necessidades ou desejos do ponto de vista dos stakeholder;

• validar as informações obtidas e o relacionamento entre elas e compatibilizar idéias;

• administrar, revisar e negociar conflitos de interesse no atendimento às necessidades;

• priorizar a demanda pela solução dos problemas;

• planejar a ordem de implementação e compatibilizar emergência de requisitos;

• documentar os requisitos, com recuperação acessível do ciclo de vida;

• aperfeiçoar o processo de comunicação;

• gerenciar as mudanças nos requisitos.

O universo da fonte de informação (stakeholder) é para quem o resultado do processo de desenvolvimento de software constitui interesse. O primeiro princípio é conhecer o universo atual e o universo potencial futuro. O segundo princípio é contatar e obter informação, se impossível do universo, mas de uma amostra representativa deste universo.

A aplicação dos processos de engenharia de requisitos deve se iniciar antes da definição do software a ser construído e basear-se no conhecimento inicial do problema, fase identificada como de descobrimento de requisitos.

A proposta é usar um modelo [ZAN98] que visa incrementar ao conteúdo do requisito parâmetros para qualificação e validação das informações. O foco de observação é sobre dois elementos: fonte de informação e características do requisito. Quanto à fonte de informação, o modelo propõe, primeiro, identificar a pessoa responsável pela declaração do requisito sob o ponto de vista de produtor e/ou consumidor da informação; segundo, visualizar claramente o papel que esta pessoa ocupa na organização (operacional, tático, estratégico) como formadora de opinião e, terceiro, qualificar o nível de exigência (essencial, expectativa, excedente) para a satisfação do requisito. Quanto ao requisito, o modelo propõe, primeiro, identificar a área de aplicação (operacional, tático, estratégico); segundo, identificar a área de origem do requisito (interno, externo, ordem legal) e terceiro, identificar a relação de dependência do requisito no contexto em estudo (individual, secundário, grupo).

O procedimento seguinte será a validação de requisitos pelo confronto das informações do requisito com as dos variados pontos de vista das pessoas. Isto é feito através da ponderação (valor) do grau de exigência e conforme necessidade e/ou desejo do cliente expressos no processo de extração de requisito, em relação ao produto ou serviço. O elemento de ligação é a qualificação funcional do requisito e a qualificação ocupacional da fonte de informação no contexto organizacional.

Como resultado, obtém-se um índice médio de qualificação do requisito, que permitirá avaliar o grau de risco (alto, médio e baixo) para sua implementação.

O resultado da aplicação dos processos de engenharia de requisitos caracteriza-se pelo documento de requisitos. Este documento deve conter os requisitos funcionais (que produzem transformação) identificados no contexto organizacional, correspondendo ao que se trata e com quais atributos, restrições e expectativas e ter agregado os requisitos não-funcionais (que refletem características de qualidade). Quanto aos requisitos funcionais, um quadro comparativo de relacionamento e interdependência entre requisitos, um quadro de qualificação de requisitos, um quadro de qualificação da fonte de informação e um mapa geral de resumo dos riscos de implementação de requisitos.

Os atributos são dimensões das características de funcionalidade e de não-funcionalidade dos requisitos. Devem ser consistentes, confiáveis e completos, com representatividade de pontos de vista das fontes de informação (stakeholder) para que se promova a garantia de qualidade do produto descrito.

Os requisitos devem ser qualificados pela funcionalidade, pela área de origem da informação e pelo inter-relacionamento com os demais requisitos.

A fonte de informação (stakeholder) deve ser qualificada pelo posicionamento de produtor/consumidor da informação e pela ocupação funcional na organização para proceder à declaração do nível de exigência dos requisitos.

As restrições são limitações que delineiam o espaço de solução do problema. As mais comuns referem-se às limitações para o conhecimento e acesso ao universo de fonte de informação, atual e o potencial futuro.

Um dos fatores restritivos mais complexos é que a solução de negócio passa muitas vezes por uma necessidade de novos procedimentos de trabalho, de reestruturação organizacional e por mudanças no relacionamento entre clientes e fornecedores.

As preferências são condições desejáveis e particulares do cliente, porém opcionais. São condicionadas à definição prévia dos atributos e das restrições. Ou seja, são circunscritas no espaço de solução do problema.

Optar por uma ferramenta de software para apoio ao processo de descobrimento de requisitos é uma alternativa preferencial em relação ao processo manual. Auxilia o processo de: descrever e montar o documento de requisitos, fazer comparações de dependências entre requisitos, tratar critérios e índices de qualificação do requisito e da fonte de informação, prover facilidades para cálculo do grau de risco de implementação do requisito, relacionar o nível de representatividade das informações obtidas com o universo de stakeholder.

As expectativas são formas de expressão de desejo do cliente. São originadas do conhecimento do problema e do ambiente, cuja satisfação refere-se à esperança de solução.

O retorno da aplicação do modelo proposto é identificar falhas de representatividade de pontos de vista do universo de stakeholder, identificar ambigüidades nas declarações de prioridades de requisitos, obter a qualificação dos requisitos checando a presença ou ausência de características de essencialidade de conteúdo, sob os aspectos do domínio da aplicação.

A definição de prioridade é uma condição essencial no processo de desenvolvimento de software. O processo é essencialmente limitado pela disponibilidade de recursos (humanos, financeiros, tecnológicos...) e pelo fator custo de produção.

Obter o nível de exigência de solução para produtos ou serviços mais prioritários, além de acelerar a entrega do resultado fazendo antes o que é realmente essencial, contribui para a negociação da forma de trabalho e para a medição de resultado da satisfação do cliente de forma gradativa.

A experiência pessoal como analista de sistemas (foco em solução de problemas de negócios, com a tecnologia de informática) na área de produção de software motivou a demanda por um resultado do trabalho de exploração e captura de requisitos que seja um documento de contratação de serviços.

Para efetivar a contratação dos serviços de produção de software é necessário ter a definição clara do que se vai construir. Esta definição deverá estar embasada num trabalho inicial de análise do problema em questão, para a proposição das alternativas de solução. Partir do conhecimento do problema para obter a definição de prioridade de solução e o consenso do universo de stakeholder envolvido é uma atividade complexa e de difícil negociação com o demandante patrocinador. Normalmente ele está interessado no resultado e não na co-autoria da tomada de decisão, ou seja, o comprometimento com a solução. Sobra para o engenheiro de software a responsabilidade não somente pela solução técnica, mas o envolvimento com a solução de negócio. Este é um risco que deve ser contornado pelo detalhamento da descrição e documentação dos requisitos, a partir do universo de stakeholder, origem da informação.

Por mais que se utilize os mais notórios métodos e técnicas de aquisição e de representação do conhecimento, os modelos construídos não garantem a continuidade do processo construtivo. É essencial que se qualifique a fonte de informação e o nível de exigência das necessidades ou desejos para seleção e priorização do que se vai construir.

O aprofundamento no estudo em RE trouxe resposta a uma série de questionamentos, o que viabilizou a formulação da heurística e criação de um modelo para geração de um documento de requisitos com os atributos necessários à qualificação dos requisitos e da fonte de informação [ZAN98]. A aplicação dos critérios estabelece condições para análise das expectativas dos stakeholder e validação dos requisitos em relação à identificação de prioridade para seleção de sua implementação.

O esforço do trabalho está concentrado sobre quem, do universo de stakeholder, está demandando a informação e com que características, focado, principalmente, na representatividade da fonte de informação como formadora de opinião na área de interesse respectiva.

A abrangência do trabalho é a aplicação do modelo de qualificação do requisito e da fonte de informação, a um universo representativo do ambiente estabelecido pela fronteira do problema a resolver, ou seja, no espaço de solução definido pelas funções, atributos e restrições obtidos e descritos durante o processo de descobrimento de requisitos.

O trabalho tem como objetivos:

a nível geral,

• enfatizar a importância da fase de descrição de requisitos no processo que antecede a produção de software, com a aplicação de um modelo de qualificação da fonte de informação (stakeholder) e do requisito, relatando os resultados obtidos e validando os critérios de qualificação quanto ao risco de implementação do requisito;

a nível específico,

• identificar o esforço participativo da fonte de informação (stakeholder);

• quantificar o universo de fonte de informação (stakeholder) representado no trabalho de extração de requisitos;

• qualificar o requisito pela sua característica funcional;

• qualificar a fonte de informação (stakeholder) pela sua característica básica de produtor, consumidor ou interessado na informação como cliente potencial;

• identificar o relacionamento de dependência entre requisitos;

• identificar os conflitos de interesse pelo tratamento da informação;

• medir o nível de exigência para o requisito para definição de prioridade e seleção;

• definir e adequar parâmetros de qualificação da fonte de informação (stakeholder) e do requisito para avaliação do grau de risco de sua implementação;

• aplicar o modelo de qualificação no ambiente de uma biblioteca técnica de informática;

• apresentar os resultados, conclusões e trabalho futuro sobre o assunto.

O trabalho não abrange a relação de custos de software. Outra característica não atendida é o gerenciamento do ciclo de vida do requisito ante as mudanças ambientais. Permite visualizar a interdependência entre os requisitos para viabilizar um futuro rastreamento destas mudanças como um pré-requisito para o gerenciamento.

O modelo é aplicável num contexto organizacional estruturado, com pessoas interagindo no ambiente, interna e externamente, cujo resultado é um produto ou um serviço.

O contexto de definição de requisitos, conforme mostrado na figura 1.1 editada na introdução, apresenta quatro elementos fundamentais para os processos de engenharia de requisitos: o universo de stakeholder, o ambiente ou domínio da aplicação, os problemas e os requisitos. Ambos interagem dinamicamente e sustentam os processos de engenharia de requisitos na captura de informações para geração do documento de requisitos. A proposta de abordagem de requisitos para descobrimento de requisitos é uma forma de apresentar os elementos constituintes do processo e o inter-relacionamento entre eles.

Próximos Passos

No próximo artigo será relatada a pesquisa sobre o estado da arte, através de revisão bibliográfica, vista sob os aspectos dos processos e técnicas aplicáveis ao descobrimento, análise, validação e gerenciamento de requisitos. Dentre os pontos considerados mais importantes, destacam-se: a mensuração de qualidade do processo e do produto de requisitos, a resolução de conflitos, a determinação do relacionamento e interação de requisitos, a priorização para implementação das especificações de requisitos e, uma visão genérica de gerenciamento de requisitos.

Referências Bibliográficas

[IC98] INTERNATIONAL CONFERENCE ON REQUIREMENTS ENGINEERING, 3., 1998, Los Alamitos. Anais... Los Alamitos : IEEE, 1998. 250 p.

[GAU89] GAUSE, Donald C; WEINBERG, Gerald M. Exploring requirements : quality before design. USA : Dorset House Publishing, 1989. 300 p.

[KOT98] KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements engineering : processes and techniques. England : John Wiley & Sons, 1998. 282 p.

[LEI94] LEITE, Júlio C.S.P. Engenharia de requisitos. Rio de Janeiro : PUC-RIO, 1994. 63 p. (Notas de Aula).

[MAC96] MACAULAY, Linda A. Requirements engineering. Great Britain : Springer-Verlag London, 1996. 202 p.

[SHE92] SHELDON, F. et al. Reliability measurement from theory to practice. USA : IEEE Software, July 1992. p. 10.

[SID96] SIDDIQI, Jawed; SHEKARAN, M.Chandra. Requirements engineering: the emerging wisdom. USA : IEEE Software, March 1996. p. 15-19.

[SOM97] SOMMERVILLE, Ian; SAWYER, Pete. Requirements engineering : a good practice guide. England : John Wiley & Sons, 1997. 391 p.

[ZAN98] ZANLORENCI, Edna P.; BURNETT, Robert C. Modelo para qualificação da fonte de informação cliente e de requisito funcional. In: XII SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE. 12., 1998, Maringá. Anais... Maringá : SBC, 1998. p. 39-48.