Este artigo é útil para que desenvolvedores de software conheçam medidas importantes que podem auxiliar todo o processo de desenvolvimento de software a partir do momento em que essas práticas ajudam na compreensão dos requisitos de software, dos solicitantes destes requisitos, da alteração dos mesmos, e dos principais problemas aos quais os requisitos de software estão sujeitos.
Por fim, a maior utilidade está em prover a compressão sobre como se executar bem a fase de engenharia de requisitos.
A engenharia de requisitos é a disciplina que de fato tem a missão de ajudar a equipe de desenvolvimento a entender o software a ser elaborado. É a base sólida para se andar do projeto até a construção. Ela é constituída pelas fases apresentadas na Figura 1. São elas:
- Concepção: fase inicial que define o escopo do problema de software;
- Elaboração: fase em que os requisitos são refinados e modelados em cenários;
- Validação: a fase em que ocorre a validação dos requisitos, onde a equipe faz uma revisão dos mesmos, para que se tenha a certeza de que os requisitos foram elicitados de maneira não ambígua;
- Gerência de Requisitos: fase em que se controla, analisa e registra as mudanças de requisito, isto a fim de verificar os impactos das alterações no produto de software em desenvolvimento.
Requisitos: O necessário para entendê-los
Um requisito é uma capacidade que o software deve possuir com a finalidade de resolver um problema do usuário. Os requisitos servem como especificação do que deve ser implementado no sistema.
Os requisitos devem descrever uma facilidade para o usuário, uma propriedade ou uma restrição do sistema, ou ainda, uma restrição do processo de desenvolvimento do sistema.
Saiba mais: Cursos de Engenharia de Software
Os requisitos de software são de três tipos:
- Requisitos funcionais: são requisitos que descrevem uma ação que o software deve ser capaz de realizar;
- Requisitos não funcionais: são requisitos que tratam das restrições do software visando sempre a qualidade, ou seja, é uma qualidade que o software deve possuir durante a sua execução;
- Requisitos inversos: são requisitos que definem o que nunca deve ocorrer durante a execução do software;
Os requisitos funcionais são de dois tipos:
- Requisitos estáveis: requisitos que não são alterados ou modificados com frequência, sua alteração é algo excepcional;
- Requisitos voláteis: são requisitos que vivem em constante modificação, eles podem ser divididos em quatro categorias: compatíveis, mutáveis, emergentes e consequentes.
Os requisitos ainda podem ser divididos em outra categoria, se vistos pelo aspecto da implementação:
-
Requisitos do cliente, ou requisitos de alto nível: são aqueles expostos pelo cliente em linguagem natural, ou ainda em forma de desenhos ou casos de uso, qualquer técnica que facilite o entendimento.
O importante é que esses requisito se caracterizam por dizer apenas aquilo que o usuário ou cliente quer que o sistema faça, não há a preocupação de como aquela funcionalidade será implementada;
- Requisitos do sistema, ou requisitos de baixo nível: são requisitos mais detalhados, que relatam não só o que deve ser implementado, mas como deve ser implementado, eles fazem restrições a aspectos de implementação e arquitetura, possuem detalhes que geralmente são obscuros para o cliente, mas que certamente os desenvolvedores conhecem bem.
Olhando por um aspecto mais ligado a gerência, outras duas classificações podem ser ofertadas aos requisitos, elas foram relatadas por Spence (2000), e são pontuadas a seguir:
- Grau de impacto que a implementação de um requisito pode ter em relação à elaboração de um sistema;
- O requisito pode impactar muito, pode impactar moderadamente, ou ainda causar pouco impacto em um projeto de software. Este tipo de classificação é muito importante para deixar ciente toda a equipe de desenvolvimento, de quais requisitos podem trazer resultados desastrosos caso não sejam bem gerenciados ou implementados;
- Grau de prioridade que o requisito tem diante às necessidades do cliente, um requisito pode ser altamente prioritário para o cliente, ou para o sistema, sua implementação e gestão devem ser muito bem elaboradas, caso contrário, a funcionalidade do sistema será deficitária. Um requisito também pode ter prioridade média ou baixa.
Este entendimento sobre a classificação dos requisitos é importante, pois ao identificar os tipos de requisitos, as equipes podem organizá-los em grupos, e conhecê-los melhor, o que torna mais fácil o controle sobre as mudanças e, como consequência, o gerenciamento. Assim, como veremos, a classificação dos requisitos é a primeira boa prática a ser seguida logo no início do projeto.
O estabelecimento de tipos diferentes de requisitos em um projeto ajuda a equipe a classificar os pedidos de alterações e a se comunicar mais claramente e firmemente com os clientes, portanto, a classificação já proporciona um entendimento e planejamento mais consistente sobre o que será implementado e em qual ordem.
Os requisitos de um software são sistemáticos, ou seja, é algo em que suas propriedades são conhecidas, mas que também são suscetíveis às mudanças. O Rational Software Corporation (RUP) oferece bons esclarecimentos que justificam a complexidade dos requisitos de software, estes esclarecimentos foram pontuados a seguir, os mesmos auxiliam no exercício de más práticas:
- Os requisitos podem vir de várias fontes e nem sempre são óbvios;
- Expressar os requisitos em palavras não é tão fácil;
- Existem níveis de detalhes para cada requisito;
- O número de requisitos pode prejudicar a gerência de requisitos, se não for controlado;
- Cada requisito é único;
- Os requisitos mudam.
Após a explanação anterior, é importante exibir as más práticas. Vale frisar que mais importante do que entender o que deve ser feito como boas práticas em um processo é entender o que não deve ser feito, bem como as armadilhas preparadas para provocar os erros.
Más práticas
De forma direta e objetiva, segue o que não deve ser adotado em processos de software na fase de engenharia de requisitos:
- Não corrigir erros e inconsistências em requisito durante sua análise, ou fase de elaboração;
- Não entender que os clientes e usuários finais do software costumam evoluir sua compreensão sobre o que desejam com o passar do tempo. Nem tão pouco se preparar para este fato;
- Provocar problemas técnicos e principalmente alterações bruscas de custo ou cronograma, isto acarreta mudança nos requisitos que podem ser impactantes para o produto;
- Não conhecer o cliente e o usuário final da aplicação;
- Não se preparar para as mudanças no ambiente em que o software será implementado;
- Ofertar as tarefas de requisitos para um profissional que não tem talento e principalmente apreço pela engenharia de requisitos;
- Desconhecer o negócio e a finalidade da instituição que está propondo o software a ser desenvolvido;
- Não fazer a modelagem de negócio (regras de negócio) antes de iniciar a engenharia de requisitos.
- Não adotar uma linguagem familiar com os clientes e solicitantes dos requisitos;
- Ofertar uma solução ao invés de se entender e registrar as necessidades e problemas dos solicitantes de requisitos;
- Não controlar a quantidade de requisitos solicitados, e nem dividir esses requisitos em grupos de implementação;
- Não relacionar os requisitos entre sim, e entre os produtos do processo de desenvolvimento de software;
- Estimar mal a quantidade de recursos humanos necessários para controlar as mudanças nos requisitos;
- Falta de habilidade para manter os documentos de requisitos consistentes;
- Ouvir muitos solicitantes de requisitos sem selecionar previamente os que mais entendem do negócio;
- Não exibir para os interessados os requisitos em prototipações gráficas.
Boas práticas
Para se conhecer e definir quais as boas práticas a serem aplicadas na engenharia de requisitos é interessante formular uma política de engenharia de requisitos.
Tal política deve explicar os objetivos dos processos definidos para engenharia de requisitos de forma clara aos envolvidos no projeto.
Além disso, deve levar em conta os padrões organizacionais, as regras de negócio da organização, e as características de cada projeto, além das aptidões de cada profissional da equipe. Por si só, tal política já se caracteriza como uma boa prática.
Uma forte recomendação dentro da engenharia de requisitos é passar a ideia de que requisitos nunca podem ser congelados, e dificilmente serão em algum projeto.
Sendo assim, outra boa prática é aplicar o gerenciamento de requisitos com o protocolo que deve ser seguido neste gerenciamento, pois a tarefa de se gerenciar requisitos pode ser extremamente burocrática, sem necessariamente agregar valor à engenharia de requisitos e ao processo de software.
Outras boas práticas são:
- Concordar com um vocabulário comum para o projeto;
- Descreve de forma clara e objetiva o problema a ser resolvido pelo sistema, bem como de seus recursos principais;
- Fazer o levantamento das necessidades dos envolvidos em pelo menos cinco áreas importantes para o sistema: funcionalidade, usabilidade, confiabilidade, desempenho e suportabilidade;
- Identificar membros da equipe que serão coautores e contribuirão para a formulação de um ou mais tipos de requisitos;
-
Decidir qual rastreabilidade de requisitos será necessária. A rastreabilidade de requisitos é o mecanismo mais eficiente de auxílio à gerência de requisitos, ela é responsável pela manutenção das modificações nos relacionamentos entre objetos e requisitos.
Tal rastreabilidade pode ser feita por meio de uma matriz. Com a rastreabilidade é possível ter visibilidade das consequências da alteração de um requisito;
-
Desenvolver uma Matriz de Rastreabilidade de Requisitos. A matriz é uma das formas mais usuais de se apresentar e estabelecer a rastreabilidade de requisitos, é ela que provê a visualização dos relacionamentos entre os objetos, ou artefatos de um projeto de software.
A Matriz de Rastreabilidade é um recurso útil dentro da gerência de requisitos, seu uso é extremamente recomendado pelos programas de melhoria de desenvolvimento de software. Um modelo de matriz é representado na Tabela 1;
- Criar relatórios de progresso e ‘status’ da matriz de rastreabilidade e dos requisitos, para que a equipe desenvolvedora entenda o impacto da alteração de um requisito;
- A equipe responsável pela engenharia de requisitos deve receber todas as solicitações de alteração nos requisitos por um formulário próprio, ou por um sistema automatizado, bem como as solicitações de adição de novos requisitos;
- Aprovar os requisitos com o cliente, usuários e demais solicitantes, isto dará oportunidade de conhecer requisitos errôneos e corrigi-los prematuramente;
- Efetuar revisões em planos e produtos de trabalho visando identificar e corrigir inconsistências em relação aos requisitos;
- Deve-se eleger um gerente de requisitos que deve avaliar o impacto das modificações solicitadas nos requisitos, e em tudo que está relacionado a eles;
- Deve ser mantido um histórico de alterações para cada requisito;
- Toda modificação em requisito deve ser comunicada aos envolvidos, devido aos impactos em potencial;
- Uma coleta periódica das métricas deve ser feita para melhor acompanhamento da gerência de requisitos. As métricas darão visibilidade da quantidade de alterações feitas e de que natureza elas são. Isto contribui para que a equipe saiba o que esperar em projetos futuros com requisitos semelhantes.
Em relação ao último tópico, a importância de se ter uma métrica se deve ao fato do gerente de requisitos poder ter o percentual de requisitos alterados, incluídos ou excluídos, dentro de um determinado período de tempo.
Isto poderá dar maior poder estratégico para os próximos projetos de software, onde o gerente poderá saber exatamente em que período ocorre maior modificação nos requisitos.
É importante salientar que muitos dos tópicos acima estão relacionados à alteração de requisitos.
Assim é relativamente fácil notar que a fase de gerência de requisitos é uma das mais importantes dentro da engenharia. Para a gerência de requisitos todas as mudanças precisam ser identificadas, avaliadas, documentadas, comunicadas e acompanhadas até sua finalização. É o que defende o CMMI.
Quando uma mudança ocorre, primeiramente deve-se analisar o requisito que está ligado àquela mudança, verificar a prioridade dele, as quais outros artefatos o requisito está ligado, verificar o impacto sobre estes artefatos; deve-se verificar também se o requisito é próprio do cliente ou do sistema, se é volátil, ou seja, se já se esperava esta solicitação de mudança, e qual a situação atual do requisito dentro do processo, enfim, deve-se tratar esta mudança a começar do reconhecimento do requisito.
Oberg (2002) escreveu que uma indústria americana formulou um estudo publicado na conferência internacional de requisitos, este estudo apontava que 76% de um total de 500 gerentes de TI nos Estados Unidos e no Reino Unido entrevistados, já tinham tido falhas em projetos inteiros durante suas carreiras. A causa mais frequentemente apontada como falha dos projetos foi a alteração de requisitos.
Atualmente, este percentual deve ter pelo menos duplicado, não só pelo aumento no número de sistemas implementados, mas também pelo aumento da complexidade nas relações e regras de negócios.
A gerência de requisitos é fundamental para o controle de mudanças dos requisitos, pois estes seguem evoluindo com o passar do tempo, já que estão inseridos em um ambiente real que muda com o tempo.
A rastreabilidade de requisitos contribui para a previsão do impacto que as mudanças dos requisitos causarão no projeto de software, sendo assim, a gerência de requisitos pode contribuir para a garantia da qualidade do sistema. A gerência de requisitos se restringe aos seguintes aspectos:
- Gerenciar mudanças em requisitos existentes;
- Gerenciar relacionamento entre os requisitos;
- Gerenciar dependências entre os produtos de trabalho durante o desenvolvimento de software.
Para que a gerência desenvolva seu papel de forma satisfatória, é necessário de antemão, definir novamente um conjunto de políticas. Estas políticas devem explicar os objetivos dos processos definidos de forma clara aos envolvidos no projeto.
E deve levar em conta os padrões organizacionais, as regras de negócio da organização, e as características de cada projeto, além das aptidões de cada profissional da equipe.
Tudo na gerência de requisitos parte da ideia de que requisitos nunca podem ser congelados, e dificilmente serão em algum projeto. Sendo assim, para que a gerência de requisitos cumpra sua missão é necessário que ela desenvolva algumas boas práticas, como: ter um modelo para rastrear requisitos, inclusive com a utilização de ferramentas que façam rastreabilidade.
Definir um modelo de rastreabilidade de requisitos para um projeto depende de muitos fatores, o primeiro deles é o software que está sendo construído. Projetos com relativa estabilidade costumam ter os requisitos alterados na ordem de 1% ao mês. Portanto, observar as características do sistema é algo que não se pode omitir (mais uma boa prática agregada). Deste modo, fica evidente que um modelo de rastreabilidade sempre é único e distinto de qualquer outro.
Um modelo de rastreabilidade inicia suas boas práticas selecionando os requisitos que devem ser rastreados. Rastrear muitos requisitos é uma tarefa burocrática e difícil, que pode agregar atrasos e erros ao analista de requisitos. Ademais, nem todo requisito, depende da sua classificação, necessita ser rastreado.
Outra boa prática dentro da rastreabilidade de requisitos estabelece que é necessário verificar (selecionar) as ferramentas de rastreabilidade que apoiarão de forma mais eficaz o processo de rastreabilidade de requisitos, é necessário ainda treinar a equipe para o uso da ferramenta.
É sadio ainda definir os momentos de registro e de controle da rastreabilidade, isto pode ocorrer no momento de fechamento de fases, por exemplo: efetuar rastreabilidade na finalização da etapa de análise e projeto, e na finalização da etapa de codificação. Não se pode esquecer que requisitos mudam a todo o momento e podem impactar mudanças em todos os artefatos de software.
Os pontos citados nos três parágrafos acima são os mais relevantes, sendo que o primeiro é mais ainda, visto que não é todo requisito que é passível de rastrear.
Deve-se fazer um catálogo, e observar através das questões a seguir, se no requisito elicitado pode-se descobrir as informações exigidas nas questões. Se o requisito atender a todas, possivelmente ele será candidato à rastreabilidade. As questões são pontuadas a seguir:
- Deve-se saber quem geriu o requisito;
- Saber o porquê da sua existência;
- Saber quais outros requisitos estão relacionados ao requisito elicitado;
- Como o requisito elicitado se relaciona com o sistema a ser implementado;
- Que documentações do processo de software podem ser afetadas pela modificação do requisito.
Após obter respostas a essas questões, em relação aos requisitos, devem-se saber os objetos a serem monitorados, bem como, os tipos de rastreabilidade que serão efetuadas, além de estabelecer corretamente o tipo de ligação que será gerenciada nesta matriz, isto dependerá exclusivamente da característica dos objetos (produtos de software), dos processos de software utilizados pela organização, e dos prazos e custos do projeto em questão.
Executando essas ações, é mais fácil fazer da rastreabilidade, uma tarefa que demande um trabalho pouco oneroso e com garantias na finalização.
Também é importante saber o grau de instabilidade dos requisitos. Ou seja, se são requisitos voláteis. Deve-se saber, ou pelo menos deduzir, com que frequência eles podem vir a se modificar.
Conhecer a instabilidade dos requisitos do software a ser desenvolvido é algo que também facilita o estabelecimento de uma matriz de rastreabilidade, visto que, alguns sistemas possuem requisitos funcionais que são pouco voláteis, onde os fatores que podem ocasionar mudanças existem, mas não são constantes, não provocam muitas variações.
Esses sistemas desenvolvem uma matriz relativamente simples, com poucos requisitos, ou com requisitos que não são tão voláteis. Neste caso, o gerenciamento é facilitado e pode-se usar até mesmo uma planilha eletrônica como ferramenta.
Vale salientar que se faz necessário a determinação de um modelo de matriz de rastreabilidade para todo software que será construído. Aliás, todo sistema deve fazer uso da rastreabilidade de requisitos, mesmo os mais estáveis. Os sistemas que necessitam de mais atenção na elaboração da matriz possuem o seguinte perfil:
- Aplicações para Internet, onde modificações surgem a todo o momento em várias etapas;
- Sistemas em que a equipe desenvolvedora geralmente possui prazos relativamente curtos para o desenvolvimento;
- Aplicações que possuem seus requisitos em constante evolução.
Após a definição do modelo, alguns outros aspectos, em relação ao desenvolvimento da rastreabilidade devem ser levados em consideração:
- Durante o processo de desenvolvimento da rastreabilidade, os elos (relacionamento entre os requisitos e os objetos de software) devem ser monitorados, pois eles também sofrem modificações, por exemplo: um elo que antes era de satisfação passa a ser de dependência, para isso, basta que o objeto a que ele esteja ligado sofra alguma alteração;
- Conscientizar a equipe da importância do processo de rastreabilidade, evidenciar que a rastreabilidade de requisitos é sim um fator de sucesso para a agilidade do processo e para o tratamento das mudanças, e isto impacta diretamente em tempo e custo;
- Após o término do projeto, analisar e avaliar criticamente a eficiência e eficácia do processo de rastreabilidade, verificando os pontos positivos e os que necessitam de melhorias. O esforço da equipe, o controle sobre as informações manipuladas, e as lições aprendidas devem ser considerados
Após os conceitos que já foram repassados sobre a técnica de rastreabilidade, é possível notar que a gerência de requisitos contribui muito para o tratamento de riscos do projeto de software.
80% dos riscos em projetos de software são oriundos da evolução dos requisitos.
Tal gerência é um processo chave ao processo de gerência de software, pois a sua correta execução pode mostrar ao gerente de projetos os problemas que o desenvolvimento de software poderá enfrentar futuramente.
Percebeu-se até agora, que a gerência de requisitos, ao contrário de outros processos que podem ser gerenciados dentro de um único grupo de negócios, pode envolver qualquer variável, ambiente, grupo de pessoas, ou processo, que possam contribuir com o seu desenvolvimento.
Este gerenciamento inclui as pessoas envolvidas com a elicitação de requisitos, e também com a definição dos testes pelo qual o sistema irá passar.
Gerentes de desenvolvimento, de qualidade, analistas, engenheiros, clientes, podem e devem participar do processo de gerência de requisitos.
Apesar da importância discutida neste artigo, a engenharia de requisitos na prática ainda é pouco utilizada em muitos ciclos de desenvolvimento.
Isto se deve ao fato de muito dos processos que compõem esta engenharia serem feitos de forma burocratizada. Um desafio para os executores dos processos e tarefas relacionados aos requisitos é prover soluções práticas e técnicas ágeis a tais processos.
Referências
- Alves, S. R. e Alves, L. A. (2009), Engenharia de Requisitos em Métodos Ágeis.
- Cohn, M. (2004) User Stories Applied For Agile SoftwareDevelopment. Addison Wesley, Kent Beck, p. 17-29 .
- d’Amorim, F. R. S. (2008), Engenharia de Requisitos para Métodos Ágeis.
