Logomarca IETEC

Buscar no TecHoje

Preencha o campo abaixo para realizar sua busca

TI

Gerenciamento de requisitos

Paulo Sotello Júnior

Publicitário, pós-graduado em Gestão de Projetos pelo IETEC.

Aos Requisitos estão associados os principais problemas do desenvolvimento de software. Requisitos que não refletem as reais necessidades dos usuários, por serem incompletos ou inconsistentes.

As principais dificuldade relatadas são as mudanças em requisitos já acordados e a grande dificuldade para prosseguirem o entendimento comum entre os usuários e os desenvolvedores, provocando re-trabalho, atrasos no cronograma, custos ultrapassados e a insatisfação dos clientes e usuários de softwares.

Muitos desses erros poderiam ser evitados se as organizações dispusessem de um processo de engenharia de requisitos definido, controlado, medido e aprimorado. No entanto percebesse que para muitos profissionais da área de informática esses conceitos não são muito claros., o que certamente dificulta a ação dos gerentes no sentido de aprimorar os seus processos de desenvolvimento.

Conceito de Requisitos e Engenharia de Requisitos

Antes de abordar o processo de engenharia de requisitos, é importante conceituar requisito, termo freqüentemente citado, debatido e utilizado na redação de contratos, sem que as partes possuam uma compreensão única de seu significado.

Os requisitos de um sistema constituem uma especificação das características e propriedades do sistema ou uma descrição do que o sistema deve fazer, de como ele deve se comportar, bem como suas restrições de operação.

É importante ressaltar que os requisitos descrevem o que o sistema deve fazer. Quando o requisito é expresso em termos do comportamento do sistema, esse comportamento deve ser passível de ser percebido por um observador externo ao sistema.

Os requisitos de um sistema podem ser organizados em diferentes níveis de abstração: Requisitos de negócios, requisitos de usuários e requisitos funcionais.

·Os requisitos de negócio correspondem aos objetivos do negócio – ou do usuário – que devem ser satisfeitos pelo sistema. Normalmente são descritos através de um documento denominado visão ou escopo do sistema.

·Requisitos de Usuários descrevem as atividades que os usuários deverão ser capazes de executar com a utilização do sistema

·Requisitos funcionais são os que descrevem as funcionalidades que o sistema deve possuir para que o usuário possa executar suas atividades.

Embora o que se pensa dos requisitos:
- Nem sempre são óbvios;
- Chegam por várias fonts;
- Nem sempre são facilmente expressos em palavras;
- Estão relacionados entre si e entre outros produtos do processo de engenharia de software;
- Possuem propriedades e valores únicos;
- MUDAM!!

Alem deste, uma especificação de requisitos deve conter:

A) Requisitos não funcionais: padrões, regulamentos e contratos com os quais o sistema deve ter conformidade; descrição de interfaces externas e requisitos de desempenho.

B) Restrições: limita a possibilidade de escolha do desenvolvedor no projeto e na implementação do produto.

C) Atributos de qualidade: ampliam a descrição das funcionalidades dos sistema através da descrição de características de qualidade do produto. Que sejam importantes para o cliente e para o desenvolvedor.

Antes de iniciar a especificação de requisitos é importante que a organização tenha definido um template do documento que deverá ser elaborado, visando um entendimento comum do que deve ser produzido. O IEEE Guide for developing systems requeriments specifications é um exemplo de template detalhado que pode ser utilizado com este propósito.

Processo de engenharia de requisitos

Para elaborar e manter uma especificação de requisitos é necessário que os desenvolvedores executem um conjunto estruturado de atividades destinas a elicitar, documentar, analisar e validar requisitos. Este conjunto de atividades, iterativas por natureza, recebe o nome de Processo de Engenharia de Requisitos.

Quanta a organização não dispõe deste processo formalmente definido e amplamente divulgado, os desenvolvedores elaboram a especificações de requisitos de forma empírica, executando atividades não padronizadas e definidas individualmente.
Se isto ocorre, a qualidade da especificação dependerá exclusivamente da experiência e formação das pessoas, havendo assim uma elevada probabilidade de ocorrerem conflitos e re-trabalho.

As atividade que compõe o processo de Engenharia de Requisitos e um conjunto de boas práticas que apóiam a sua execução serão a seguir apresentadas:

A) Elicitar - Elicitar requisitos é o nome usualmente atribuído á atividade voltada para descobrir (identificar, deduzir, extrair, evocar, obter) os requisitos de um sistema, através de entrevistas com os interessados pelo sistema, da análise do domínio do problema ou de estudos de mercado.

Na elicitação de requisitos constituem boas práticas a redação de uma declaração de visão e escopo do sistema; a definição dos procedimentos para desenvolvimento dos requisitos, a identificação das classes de usuários e dos diferentes grupos de interesse no sistema, a identificação dos casos de uso, a analise dos fluxos de trabalho dos usuários, a definição dos atributos de qualidade do sistema e o desenvolvimento de mecanismos que possibilitem o re-uso de requisitos

B) Analisar - Na análise os requisitos elicitados são compreendidos e detalhadamente analisados por todos os interessados no sistema. Nesta atividade surgem muitos conflitos, sendo comum haver necessidade de haver negociação para que os requisitos sejam aceitos por todos.

As boas práticas de análise referem-se a elaboração de um diagrama de contexto do sistema; criação de protótipos, análise de viabilidade, priorização dos requisitos e a criação de um dicionário de dados.

C) Documentar - Uma vez compreendidos, analisados e aceitos, os requisitos devem ser documentas com um nível de detalhamento adequado, produzindo a a especificação de requisitos de softwares.
Pode ser utilizada a linguagem natural ou diagramas, como os propostos pela UML.

D) Validar - Após terem sido documentados, é necessário que os requisitos seja cuidadosamente validados, principalmente quanto a consistência e a completude. Esta atividade visa identificar problemas nos requisitos, antes do inicio da construção. A importância dessa atividade é caracterizada pelo fato de que a correção de um erro nesta fase, possui um custo muito inferior do que a correção nas fases mais adiantadas do processo de desenvolvimento.

Para o Gerente de projetos, responsável por atender as expectativas dos diferentes interessados no sistema, recomenda-se como boas práticas, a seleção de um modelo de ciclo de vida apropriado, considerando que modelos incrementais e iterativos – como o Unified Process e Extreme Programming tem apresentado melhores resultados, Elaboração de Planos de projetos baseados nos requisitos de sistema, renegociação de compromissos tão logo se perceba que eles não possam ser cumpridos, gerenciamento de rsicos associados a requisitos e a criação de condições para que os requisitos possam ser rastreados ao longo do projeto.

Conclusão

È importante que gerentes de projeto reconheçam que não é possível desenvolver sistema de qualidade, cumprir prazos e custos e atender ás expectativa dos usuários sem ter um processo de desenvolvimento de requisitos definido, compreendido e utilizado por todos os desenvolvedores.

Indique este artigo a um amigo

Indique o artigo