ANALISE DA IMPLANTAÇÃO DO PROCESSO DE CLASSIFICAÇÃO DE
REQUISITOS EM UMA ORGANIZAÇÃO
Eduardo Bertolucci1, Luiz Carmargo2,
Resumo
Este artigo descreve o processo de implantação da classificação de requisitos em uma
organização da área de tecnologia na qual desenvolve softwares comerciais.
O enfoque do artigo compreende, na necessidade de alterar a metodologia do processo de
documentação de requisitos, criando uma documentação teórica com definições de como
escrever os requisitos e criando um ambiente padrão para armazenar e rastrear a evolução dos
requisitos, mantendo suas versões, e também manter a rastreabilidade. Uma grande necessidade
da adoção desta metodologia se baseia nas práticas de mercado do governo em relação à
medição de seus pedidos de alteração nos sistemas que eram calculadas por horas e agora em
novos contratos passa a ser por pontos por função. As situações praticamente estão citadas em
ordem cronológica mostrando as etapas em que ocorreram as novas formas de escrita de
requisitos e como o padrão foi definido de forma unificada para todas as equipes da
organização.
Palavras-chave: Software, Requisitos, Processo, Analista, Rastreabilidade.
Abstract
This article describes the process of implementing the classification requirements in an
organization in the area of technology in which develops commercial software.
The focus of the article understands the need to change the methodology of the requirements
documentation process, creating a theoretical documentation with definitions of how to write
requirements and creating a standard environment to store and track the evolution of
requirements, keeping their versions, and also maintain traceability. A great need of adopting
this methodology is based on the practices of the government market in relation to the
measurement of their requests for changes in the systems that were calculated for hours and now
in new contracts shall be by function points. The situations are virtually cited in chronological
order showing the steps that have occurred in the new forms of writing requirements and how the
pattern was defined in a unified way for all teams within the organization.
Key word: Software, Requirements, Process, Analyst, Traceability.
1 Pós-graduação em Engenharia de Software pela UNISOCIESC. e-mail: ([email protected])
2 Professor na UNISOCIESC. e-mail: ([email protected])
1
INTRODUÇÃO
Este artigo tem o objetivo de descrever a implantação do processo de classificação requisitos
em uma organização bem como o que impulsionou essa mudança de metodologia e também sua
documentação teórica.
O artigo está organizado como se segue. Na Seção 2, deparamos com a indispensabilidade da
adesão do processo de análise de requisitos, contendo um breve histórico dos editais de
recomendação do governo para a adoção a métrica de mercado conhecida como pontos de função
sendo agora necessária para novos contratos onde existe a chamada manutenção evolutiva.
Na seção 3, relatado o processo de implantação de análise de requisitos desde como eram
especificados os requisitos no qual os analistas de sistema desenvolviam documentos em formato
texto chamados de matriz de aprovação e matriz de regras, desta maneira surgiu à necessidade
buscar nesse insumo requisitos funcionais para calculo dos pontos de função, trabalho que
consumia tempo devido à junção todos os tipos de regras estarem descritos em formato textual.
Após o esforço de coletar os requisitos funcionais nestes documentos, é descrito em outros
subtítulos os novos tipos de documentos elaborados, também adotamos a linguagem UML como
padrão para ser escrito com base em práticas de mercado e facilidade de aprendizagem e maior
quantidade de material de referencia para se criar o processo de análise de requisitos mais conciso
e cravejado na organização.
Na seção 4 é apurado um histórico da implantação do processo com informações fornecidas
pelos próprios usuários, articulando vantagens da padronização da escrita estruturada de
requisitos, e também a curva de aprendizagem para novos colaborados com tal competência para
criar especificações de requisitos. Em seguida, na Seção 5, encontram-se as conclusões.
2
INDISPENSABILIDADE DA ADESÃO DO PROCESSO DE ANALISE DE
REQUISITOS
Segundo Maria da Glória Guimarães dos Santos, chefe da Secretaria de Logística e
Tecnologia da Informação o edital publicado no ano de 2010 obriga todos os órgãos do Governo
a utilizarem Pontos de Função como métrica padrão para contratação de desenvolvimento de
software. Levantamento referente a janeiro de 2012 aponta no Brasil 319 certificados em Pontos
de Função, número que comprova a escassez no atendimento às empresas privadas e empresas
públicas que adotaram a técnica.
O aumento da demanda de desenvolvimento e manutenção de software tem levado às
organizações públicas a terceirizarem cada vez mais os serviços de software. Com isso, surge
fortemente a necessidade de estabelecer critérios que garantam o melhor uso do orçamento
público.
Com o objetivo de estabelecer métricas de qualidade para empresas de TI, o Ministério do
Planejamento, por meio da Secretaria de Logística e Tecnologia da Informação – SLTI publicou
em 02 de janeiro de 2011 a Instrução Normativa 04 (IN04/2010) que, dentre outras ações, obriga
o uso de métricas nos contratos de serviços de software. Comprar software, exige um modelo
complexo de contratação, pois envolve o consumo de um bem que sofre modificações ao longo
do tempo.
A técnica de APF é uma métrica muito utilizada no mercado, que vem para contribuir para a
composição desse modelo. O segredo é investir na capacitação tanto de quem compra como para
quem vende software, para que todos tenham condições de precificar melhor.
2.1 Recomendações para Contratos de Software com Pontos de Função do Governo
Brasileiro
Segundo a Instrução Normativa 04 (IN04) publicada pelo MPOG/SLTI recomenda o uso de
métricas em contratos de software. A contratação de serviços de fábrica de software deve utilizar
métricas no planejamento da aquisição e no gerenciamento do contrato, com restrições ao uso da
métrica de esforço homem-hora.
O TCU tem recomendado em Acórdãos o uso da métrica Pontos de Função (PF) em
contratos de prestação de serviços de desenvolvimento e manutenção de software. A Métrica (PF)
tem sido usada como base para contratos de software em muitas organizações.
PF mede o tamanho funcional do projeto de software, independentemente da tecnologia e
metodologia utilizadas. PF torna possível a estimativa de tamanho de projetos de software nas
fases iniciais do ciclo de vida. O Manual de Práticas de Contagem (CPM) possui regras objetivas
para contagem de Pontos de Função. PF considera a visão do usuário. PF é independente da
forma da modelagem dos Requisitos
Recomendações TCU
• Acórdão 1.782/2007 - Plenário - Determinação
• Acórdão nº 1.910/2007 - Plenário - Recomendação
• Acórdão 2.024/2007 - Plenário
• Acórdão 1.274/2010 - Plenário - Determinação
• Acórdão 1.647/2010 - Recomendação
3
FUNDAMENTAR O PROCESSO DE IMPLANTAÇÃO E SEU AVANÇO
Até o final do primeiro semestre do ano de 2012 eram desenvolvidos dois documentos, o
primeiro era chamado “MA - Matriz de Aprovação” onde estavam juntos regras, requisitos,
protótipos e detalhes técnicos de SQL e tabelas. Já o segundo documento era chamado de “MAR
- Matriz de Regras”, onde possui detalhes técnicos como consultas SQL, instruções para criação
de campos, protótipos e instruções de uso.
Os dois documentos eram obrigatórios para o inicio da codificação da solução técnica sendo
submetidos em aprovação, para posteriormente serem implementadas no produto.
Na empresa os analistas produziam documentos que serviam de insumo para as equipes de
desenvolvimento programar as soluções no código.
3.1 Documento de requisitos
•
MA - Matriz de aprovação: Contém os requisitos a serem adequados e os requisitos
adicionais do projeto com o layout das telas de cada requisito. Este documento contem
todas as adequações e novas funcionalidades detalhadas para esclarecimentos com o
cliente a fim de evitar, dessa maneira, qualquer entendimento errôneo ocorrido durante as
reuniões de validação de requisitos.
•
MAR - Matriz de regras: Realizar o detalhamento das regras inseridas na matriz de
aprovação, para encaminhamento ao desenvolvimento da solução.
Pontos positivos
• Junção de requisitos de negócio e técnicos.
• Rapidez no desenvolvimento devido ao grande número de informações técnicas.
• Ordem cronológica de alterações no sistema.
Pontos negativos
• Falta de rastreabilidade.
• Muitos documentos para ler.
• Falta de uma fonte de pesquisa eficiente.
• Grande misto de requisitos, regras, detalhes técnicos.
As demandas eram calculadas por horas, porém com novas regras impostas pelo governo os
novos contratos renovados declamavam o calculo por pontos por função.
Essa nova forma de medição deu origem a um novo documento chamado “PPF - Pontos por
Função”, no qual os analistas de sistemas possuidores daquela especificação eram responsáveis
por elaborá-lo.
3.2 Documento de contagens de pontos de função
•
PPF – Pontos de Função: Documento contendo os métodos de contagem, contagem
indicativa, contagem estimada, contagem detalhada, fronteira, funções de dados, funções
de transação, entrada externa, consulta externa, saída externa, arquivo lógico referenciado,
registro lógico referenciado, dado elementar referenciado
Porém o insumo necessário para produção deste documento era bastante heterogêneo,
trazendo informações relevantes e irrelevantes para a contagem que se baseava na coleta de
funcionalidades que seriam entregue ao cliente.
O processo para contar pontos for função era basicamente ler o documento "Matriz de
aprovação" no qual possuía toda a documentação da funcionalidade a ser entregue para o cliente,
porém identificando todas as funcionalidades, no caso requisitos funcionais do documento. Com
base nestes requisitos eram calculados os pontos por função, assim finalizando o documento e
repassando para a equipe de orçamento.
3.3 Novos documentos para especificação
Neste ponto surgiu à necessidade de elaborar um novo tipo de documento de requisitos com
separação de negócio e solução técnica, desta forma, foi repensado o processo de especificação
de requisitos. Mediante consultoria e adoção da UML com linguagem prática de mercado, foram
elaborados novos modelos de documentos, são eles:
•
PRS: Proposta de Solução: O documento possui a seguinte estrutura:
a. Necessidades: Descrever as necessidades que serão consideradas na presente
proposta. Fazer referência ao número da(s) SALT(s) que estão no escopo dessa
proposta.
b. Glossário: Detalhamento de termos utilizados na proposta que precisem ser
explicados para melhor entendimento do documento.
c. Esta seção não é obrigatória.
d. Situação atual: Descrever o cenário atual, sem a solução proposta.
e. Situação pretendida: Descrever a situação pretendida com a solução proposta em
nível de negócio. Este tópico abrange a descrição de regras de negócio e requisitos
funcionais de maneira implícita. Se necessário, também podem ser apresentados
protótipos e, de forma implícita, requisitos não funcionais e mensagens de usuário.
•
ERS: Especificação de Requisitos: O documento possui a seguinte estrutura:
a. Introdução: Contem a descrição do alinhamento sobre a demanda e quais ações
especificadas para atender a manutenção solicitada.
b. Alteração: Explicação das alterações a serem realizadas.
c. Requisitos funcionais e requisitos não funcionais: Identificador, nome e texto
explicativo de cada um dos requisitos funcionais e não funcionais e status de novo
ou alterado.
d. Caso de uso: Lista com casos de uso referidos, com nome do ator, pré-condição,
descrição de sua aplicação no sistema, cenário principal, cenário alternativo e
cenário de exceção.
e. Regras de negócio: Identificador, nome e texto explicativo, podendo conter
referência a mensagens ou outra regra de negócio quando esta for regra
agrupadora ou conter sub-regras e status de novo ou alterado.
f. Mensagens: Identificador, nome e texto a ser apresentado ou registrado com o
tipo informação, aviso ou erro.
g. Protótipos: Lista de protótipos referenciados na especificação.
h. Regras de tela: Identificador e nome e texto explicativo.
i. Filtros: Texto explicativo o funcionamento do filtro.
Foram criados comitês, conhecido como comitê de requisitos, onde um integrante de cada
equipa de cada unidade se reúnem com a intenção de discutir, elencar e melhorar o processo de
análise de requisitos, trazendo dificuldades reportadas por colaboradores da equipe e sugestões de
melhoria. Um consultor externo apoia as reuniões que ocorrem semanalmente. Como ferramenta
para escrita de requisitos foi adotado como ferramenta de mercado o Enterprise Architec,
praticamente uma recomendação do governo.
Os tipos de requisitos definidos pelo comitê e disseminados entre os analistas de sistemas nas
equipes são:
• Elemento SALT;
• Item de Alteração;
• Requisitos Funcionais;
• Requisitos Não Funcionais;
• Regras de Negócio;
• Regras de Tela;
•
•
Caso de Uso;
Protótipo.
A seguir são descritos cada um dos tipos de requisitos citados acima:
Elemento SALT
SALT é como chamamos um atendimento, a exemplo disso é como se fosse a abertura de um
chamado ou um protocolo de atendimento em outra empresa. O elemento SALT deve conter o
número correspondente da solicitação em formato sequencial único e descrição do entendimento
da solicitação.
Item de Alteração
O texto do Item de Alteração deve orientar explicitamente quais partes dos elementos
relacionados serão modificadas. Por exemplo, se o elemento for um Caso de Uso alterado, o texto
deve indicar qual Cenário foi alterado e detalhar ainda o que foi alterado no respectivo Cenário.
Em outro exemplo, se o Caso de Uso for novo, o texto deve explicitar esta situação, informando
que a leitura completa do Caso de Uso é necessária.
O Item de Alteração deve explicitar também todas as exclusões de elementos existentes no
legado que forem necessárias para a implementação da solução proposta.
Um Item de Alteração deve relacionar todos os elementos (novos ou alterados) necessários
para o entendimento da solução proposta: requisitos, casos de uso, regras, mensagens e
protótipos.
Requisitos funcionais
Um requisito funcional define uma função ou serviço que um sistema deve ou pode ser capaz
de executar ou fornecer. Os requisitos funcionais identificam o que deve ser atendido pelo
sistema a fim de satisfazer as necessidades dos usuários/clientes.
Requisitos não funcionais
Um requisito não funcional representa uma restrição ou atributo de qualidade, podendo ser
classificado nas seguintes categorias:
• Segurança: Requisitos associados à integridade dos dados, privacidade e como o sistema
trata de informação confidencial.
• Desempenho: Requisitos que podem estar associados ao tempo esperado de respostas para
as funcionalidades do sistema e uso de recursos, tais como: memória, processador, espaço
em disco, entre outros.
• Usabilidade: Requisitos associados à facilidade de uso do sistema.
• Confiabilidade Requisitos associados a medidas quantitativas da confiabilidade do
sistema, tais como tempo médio entre falhas, recuperação de falhas e quantidade de erros
por milhares de linhas de código.
• Portabilidade: Requisitos associados a restrições de plataformas de hardware e de
software, nas quais o sistema será implantado, e sobre o grau de facilidade para
transportar o sistema para outras plataformas.
•
Padrões: Requisitos associados a padrões e normas utilizados no desenvolvimento do
sistema.
Regras de negócio
Uma regra de negócio é uma afirmação que define ou restringe o negócio. O objetivo destas
regras é definir a estrutura ou o comportamento do negócio. Elas complementam o entendimento
sobre os requisitos e detalham o “como” do ponto de vista do negócio.
As regras de negócio podem ser cálculos, deduções, validações ou restrições que devem ser
consideradas na execução dos processos existentes em uma organização. Elas podem ser leis e
regulamentos impostos ao negócio.
Regras de tela
Uma regra de tela deve orientar a interpretação do comportamento de uma tela do sistema.
Exemplos de informações que podem ser tratadas:
• Informações sobre um Campo da tela. Exemplos:
o Definição, máscara, tamanho, cor e fonte de um determinado Campo.
o Um campo pode ter um tamanho de preenchimento, mas deve ser visualizado
somente X caracteres.
•
Comportamento ou restrições de componentes existentes na tela: botões, listas (grids),
filtros (input, selects), elementos de seleção (combo boxes, radio buttons, checkboxes),
etc. Exemplos:
o Quais informações devem ser mostradas numa lista (grid).
o Um botão ou Campo deve ficar desabilitado quando um determinado Campo não
estiver preenchido ou determinada situação for identificada.
o Um determinado texto deve aparecer em negrito e na cor vermelha sempre que
uma informação for de um determinado tipo ou estiver numa determinada
situação.
o Um determinado campo deve ser exibido desmarcado por padrão (default) sempre
que um novo cadastro for selecionado pelo usuário.
o Uma determinada aba ou seção da tela deve ser mostrada somente quando uma
determinada situação for satisfeita.
o Explicações de como os comportamentos dos filtros utilizados na tela devem ser
interpretados.
Filtros
Os filtros são componentes visuais utilizados basicamente em consultas. Um Filtro é um
componente visual que permite a digitação direta de uma informação ou a busca desta
informação por meio de uma Tela de Consulta. O comportamento genérico de um Filtro é
descrito no elemento “Filtro Padrão”.
Mensagens
As mensagens discutidas no contexto deste documento são aquelas voltadas para apoiar
usuários do sistema. Eventualmente, você pode utilizar outros tipos de mensagem para apoiar a
equipe técnica de suporte ao sistema.
Casos de Uso
Após a identificação dos requisitos e das regras, deve ser analisado o comportamento que o
sistema deve apresentar. O termo usuário pode significar um usuário humano, um equipamento
ou mesmo outro sistema de software. Um caso de uso representa uma interação que tem
significado para o usuário final e que deve terminar (sair do sistema) com um estado completo,
sendo concluída ou retornando ao estado inicial.
4
RESULTADOS OBTIDOS COM A IMPLANTAÇÃO DE ANALISE DE REQUISITOS
Este processo de implantação de requisitos está em fase de amadurecimento, sendo que nos
seus primórdios muitas pesquisas em bibliográficas e praticamente compilações formadas em
reuniões dos comitês que ao serem rodadas nas equipes pelos colabores em algumas equipes
produziram inúmeros resultados.
Bastante contraditório, pois o quando se desenvolvia apenas dois insumos com todos os
dados necessários para programar era descomplicado. Com esse novo formado de modelagem,
detectamos uma curva de aprendizagem lenta devido à maturidade de implantação do processo.
Bem escassa são fontes de comparação do antes e depois apropriado ao tipo das solicitações
que são documentas e todas as especificações serem feitas já com caráter real, sendo enviadas
para os clientes e encaminhadas para as próximas etapas até gerar uma entrega ao cliente. Na
sequencial foram elencadas vantagens sobre o investimento na estruturação dos requisitos e
comentário sobre a curva de aprendizagem.
O tempo de desenvolvimento das especificações de requisitos que antes era de 30 horas
levando em consideração dois requisitos funcionais, teve um aumento de 100%, passando para 60
horas no início da padronização. Isso se deve a curva de aprendizagem em relação à forma de
escrever os requisitos funcionais, estruturação de módulos do sistema, documentação por
demanda de todo o legado que antes era escrito em formato de matriz de regras. Antes de iniciar
uma nova especificação se tornou necessário documentar o legado a fim de alterar seus
requisitos.
Concluímos que o processo de implantação da padronização de requisitos teve um grande
impacto no trabalho dos analistas, bem como os analistas de sistemas, que tiveram que usar uma
nova ferramenta para documentação do produto e nova metodologia para descreves as
funcionalidades do produto, porém tivemos vantagens como:
a.
b.
c.
d.
e.
f.
g.
Menor retrabalho.
Repositório único.
Histórico de alteração de requisitos.
Padronização na escrita de requisitos.
Rastreabilidade dos requisitos.
Mitigação de impactos no sistema devido à alteração de requisitos.
Geração de um documento contendo todos os requisitos.
4
CONCLUSÃO
O processo de padronização da escrita de requisitos foi fundamental para unificar a
linguagem entre cliente e empresa. Atividade que exigiu tempo, ferramentas e alinhamento de
conhecimento das pessoas envolvidas.
Com isso, foi adotada ferramenta de análise que permite a centralização e visibilidade de
todo material produzido para documentar o produto em nível de funcionalidades e negócio.
Em casos onde não existia documentação do legado, os envolvidos fazem engenharia reversa
afim de, depois rastrear as alterações nos requisitos através de parâmetros utilizados para
identificar requisitos implementados, alterados e novos.
Neste artigo foi exposto o que impulsionou a forma de como elaborar as especificações de
software e concluímos que o processo está em fase de amadurecimento e a documentação teórica
elaborada neste período tornou-se um padrão para a empresa.
REFERÊNCIAS
UML tools for software development and modelling - Enterprise Architect UML modeling tool
- Enterprise Architect 9.3 - Disponível em: <http://www.sparxsystems.com.au>. Acesso em: 06
nov. 2013.
Claudia Hazan, Uso de Métricas em Contratos de Fábrica de Software - Roteiro de Métricas
do SISP 2.0 - Disponível em: <http://portal.dataprev.gov.br/wp-content/uploads/2012/09/7-Usode-metricas-em-contratos-de-fabrica-de-software-Roteiro-de-Metricas-do-SISP-2.0-ClaudiaHazan-SISP.pdf>. Acesso em: 06 nov. 2013.
Softplan/Poligraph - Sistemas Integrados de Gestão - Orientações para montagem do
documento "Manutenção Evolutiva - Requisitos". - Disponível em:
<https://colabore.softplan.com.br/pages/viewpage.action?pageId=89558903>. Acesso em: 06
nov. 2013.
Dataprev - Empresa de Tecnologia e Informações de Previdência Social - Disponível em: <>.
Acesso em: 06 nov. 2013.
APF Métricas Treinamentos & Consultoria - APF no Governo - Disponível em: <
http://apfmetricas.org/index.php/component/content/article/19-sample-data-articles/ifpug/50upgraders>. Acesso em: 06 nov. 2013.
Ian Sommerville. Engenharia de Software, 9ª Edição. Pearson Education, 2011. Cap. 4 (Seção
4.1)