Categoria: Requisitos

No artigo anterior vimos a estruturação de requisitos em 4 níveis (ou tipos). Hoje mergulharemos um pouco mais no desenho, mostrando atributos que devem caracterizar todos os requisitos. Para isso vamos pegar todos os tipos de requisitos…

… e tratá-los como uma coisa (!) só:

Apresentarei os atributos em sentido anti-horário, começando pelo Tipo. O Tipo aparece aqui apenas para fins ilustrativos. A informação já apareceu no diagrama anterior. Um requisito sempre terá um dos seguintes tipos:

• Um objetivo do Negócio;
• Objetivos ou metas mais específicos, atribuídos a um único processo de negócio;
• Um requisito do Usuário;
• Um requisito Funcional; ou
• Um requisito Não-funcional.

Todo requisito possui uma única Fonte. Trata-se da pessoa que manifestou aquela necessidade. Em alguns casos bastará o registro do nome. Outros podem preferir uma ficha mais completa, com cargo, departamento, formas de contato etc. De qualquer maneira, o Ponto de Vista desta pessoa deve ser registrado em separado. É uma informação que ajuda muito no processo de tomadas de decisão sobre o escopo do projeto, por exemplo. No nível mais simples e genérico, o Ponto de Vista pode ser:

• Estratégico: é o dono do negócio, ou a alta direção. Desnecessário dizer que, na maior parte das vezes, seus requisitos têm um peso consideravelmente maior que os demais.
• Tático: é um gerente, coordenador ou supervisor. Ou seja, todo o escalão que fica entre a alta direção e o pessoal
• Operacional: que é quem realmente executa o trabalho. É interessante alertar que, dependendo do projeto, esses três níveis podem ser usuários do sistema. Esta delimitação aparecerá de maneira mais clara nos Casos de Uso. Além deles há também um 4º ponto de vista, o
• Técnico: que pode representar, por exemplo, o pessoal de TI da empresa. Neste caso, eles são a origem de muitos requisitos não-funcionais. Sobre arquitetura tecnológica, por exemplo.

Não é bom confundir a estrutura com o processo de desenvolvimento dos requisitos, mas aqui cabe uma exceção. É muito importante que, no momento do registro de um requisito, a Fonte indique qual é o Grau de Importância que ela lhe atribui. Neste ponto estamos distantes do processo de priorização, mas esta informação será de muita relevância lá e em várias outras decisões tomadas pela equipe no decorrer de um projeto. Por isso é importante que esta classificação seja simples e objetiva:

• Fundamental: ou seja, o projeto será considerado falho se este requisito não for atendido. Soou um tanto “dramático” mas é assim mesmo que estes requisitos devem ser vistos: cruciais para o sucesso do projeto.
• Importante: o cliente não abre mão da implementação deste requisito, mas saberá aguardar sua satisfação caso o projeto enfrente algum problema ou se surgirem outros requisitos Fundamentais no meio do caminho.
• Opcional (ou Acessório): como o próprio nome indica, a não satisfação deste requisito não comprometerá em nada o projeto. São os tradicionais “badulaques” (ou “perfumaria”) que devem ser relegados para quinto plano (dos infernos) tão logo o projeto tenha seus prazos desafiados. Falando sério: há um lugar muito nobre para requisitos não satisfeitos. Uma seção do documento de visão chamada “Idéias para Versões Futuras”.

Os dois últimos atributos, ao contrário dos anteriores, nascerão ou serão amadurecidos em momentos posteriores ao registro do requisito. O primeiro deles é o auto-relacionamento entre os requisitos (representado pela elipse no canto inferior direito da classe Requisito no diagrama acima). Faz parte da análise de requisitos, além da validação de sua acuracidade, o “confronto” com outros requisitos. Existem 4 tipos de relacionamentos possíveis:

• Dependência: por exemplo, “a satisfação do requisito ‘A’ depende da satisfação do requisito ‘B’”. Esta relação pode ser descoberta bem cedo no ciclo de um projeto, mas é mais comum que ela só seja percebida no momento do desenho da solução.
• Complementariedade (ou Facilitação): “a satisfação do requisito ‘A’ é facilitada pela satisfação anterior do requisito ‘B’”. Na relação de dependência, se o requisito ‘B’ não for satisfeito, torna-se impossível a realização do requisito ‘A’. Aqui apenas indicamos que se o requisito ‘B’ for atendido antes, a satisfação do requisito ‘A’ é facilitada. No entanto, em ambos os casos estamos indicando claramente uma seqüência de desenvolvimento.
• Substituição: pois é, assim registramos uma mudança. Afinal, uma mudança nada mais é do que um requisito “atrasado”. É uma boa prática a decisão de nunca “deletar” um requisito. Assim mantemos todo o histórico de um projeto. Por isso é necessário que registremos toda e qualquer alteração sofrida por um requisito como um novo requisito, que *substitui* o anterior.
• Conflito: sendo direto, “a satisfação do requisito ‘A’ impede a realização do requisito ‘B’”. Ou seja, é obrigatória uma tomada de decisão: qual requisito será excluído do escopo do projeto? É o primeiro ponto em que a informação sobre o Ponto de Vista da Fonte do requisito pode ser útil: qual pesa mais? A exemplo dos demais tipos de relacionamentos, as vezes um Conflito só é detectado em estágios avançados do projeto. No entanto, assim como os riscos e bugs, quanto antes eles forem identificados, melhor. Aliás, ele é um bug!

Por fim temos o Status do requisito. Registramos aqui o seu ciclo de vida. Todos nascem com o estado “Pendente”. Após um primeiro ciclo de validação eles são “Aprovados” ou “Recusados”. Os “Aprovados”, no decorrer do projeto, podem assumir 1 de 3 estados possíveis: “Substituído”, “Excluído” ou “Implementado”. Nos dois primeiros encerrou-se o ciclo. Aos “Implementados” falta um último estado: “Verificado”. Consideramos que todos os requisitos marcados como “Veficados” estão devidamente satisfeitos. Esta seqüência pode ser estendida, para contemplar eventos e resultados de testes, por exemplo.

.:.

Assim encerramos o “básico do básico” sobre estruturação de requisitos. Estranho, mas se trata de um “básico” que raramente percebemos em projetos e até mesmo nas ferramentas utilizadas para o gerenciamento de projetos (ou de requisitos).Sim, a estruturação proposta resulta em um grande volume de informações. Mas, na realidade, o que ela faz é nos dar a exata noção da quantidade de informações que lidamos ao desenvolver e gerenciar requisitos. Tais informações já existem em qualquer projeto. A diferença aqui é que elas não ficam “soltas”. Não há burocracia nem redundância. Os modelos propostos consideraram apenas as informações mínimas necessárias para uma correta e precisa engenharia de requisitos.

Encerrei o artigo anterior prometendo falar sobre análise e rastreabilidade dos requisitos. A análise, apesar de não explicitamente descrita, está na apresentação de todos os atributos dos requisitos. O registro de cada um deles é resultado da análise. Aliás, isso é Análise de Requisitos.

Já a rastreabilidade ficou implícita, escondida nos dois diagramas apresentados. Imaginando os modelos como uma base de dados, não é fácil perceber como podemos “rastrear” os requisitos “na vertical e na horizontal”? Um breve checklist (surrupiado do SEI – Software Engineering Institute):

• Qual meta ou objetivo de negócio é atendido pelo requisito?
• Este requisito é realmente necessário?
• Como eu devo interpretar este requisito?
• Quais decisões de projeto afetam a satisfação deste requisito?
• Qual teste de aceitação será utilizado para validar o requisito?
• Qual o impacto gerado pela mudança deste requisito?
• Todos os requisitos foram atendidos?
• O projeto acabou??

Para encerrar, uma provocação (sem ironia) ao amigo agilista. Saca só o segundo diagrama. Troque “Requisito” por “User Story”. E se usarmos as cores dos post-its para diferenciar os tipos de requisitos? Fica bem legal, não acha?

Não é fácil explicar, mas problemas com “requisitos” seguem respondendo por grande parte das falhas e atrasos em projetos. Um estudo recém publicado pelos Capítulos Brasileiros do PMI mostra que entre os principais problemas enfrentados, 62% refere-se à mudanças em requisitos e 60% tem a ver com a (má) definição destes. Quando olhamos especificamente para projetos do setor de TI, os números sobem para 83% e 81%, respectivamente. Publiquei no Graffiti um artigo comentando o estudo. Aqui vou apresentar uma idéia que pode ajudar a reduzir os problemas com requisitos.

Trata-se de uma idéia “requentada”. Há 5 anos ela foi o núcleo do primeiro trabalho que apresentei em público, no Seminário de Gestão de Projetos promovido pela SUCESU-SP e pelo PMI. Requentada não, amadurecida. Ela é uma das partes principais de meu trabalho para Formação de Analistas de Negócios. Além da experiência, utilizei os trabalhos de Karl Wiegers e de Suzanne e James Robertson para chegar no desenho que apresento abaixo. Neste último livro, publicado em 2005, conheci o Volere e o Requirements Knowledge Model, propostas que reforçaram minha idéia sobre a Estruturação de Requisitos.

Para começar, vale a pena revisar a definição de requisitos e seus tipos. Em levantamentos informais que realizo nos cursos e oficinas descobri que a definição mais comum para requisitos é: “uma necessidade do cliente ou usuário”. Correta, mas não explica bem a amplitude e heterogeneidade dessas “necessidades”. Uma das melhores definições para requisitos foi criada por Ian Summerville e Pete Sawyer em Requirements Engineering – A Good Practice Guide :

Requisitos são… uma especificação do que deve ser construído. São descrições de como o sistema deve se comportar, ou uma propriedade ou atributo do sistema. Podem ser uma restrição ao processo de desenvolvimento.

O diagrama acima ilustra todas essas possibilidades. Começamos pelos Objetivos do Negócio. Normalmente eles são os primeiros requisitos que recebemos. Infelizmente, também são os primeiros que esquecemos no decorrer de um projeto. Mas isso fica para outro artigo. Esses objetivos podem ser “quebrados” em objetivos mais específicos, ou metas, que vinculamos diretamente a Processos de Negócio. Por exemplo: “reduzir em 10% os custos de vendas é uma meta colocada para o processo de vendas”; um requisito que deve ser atendido pelo projeto. O diagrama também mostra que as Regras de Negócio são vinculadas aos Processos de Negócio. O destaque se faz necessário porque é comum a confusão entre requisitos e regras de negócio. E se torna ainda mais relevante quando percebemos que as regras são muito mais voláteis (passíveis de mudanças) do que os requisitos. Exemplificando: “nas operações de vendas o sistema deve permitir a aplicação de um desconto sobre o valor total da transação”. “O desconto máximo de 10% só pode ser aplicado em vendas superiores a R$ 100,00”. A primeira frase é um requisito funcional. A segunda, uma regra de negócio. A chance da segunda mudar é muito maior.

Na seqüência temos os Requisitos do Usuário, solicitações que podemos quebrar em vários Requisitos Funcionais. Esta classificação, originalmente proposta por Karl Wiegers , gera uma certa confusão. Um Requisito de Usuário é de alto nível. Por exemplo: “Emitir uma Nota Fiscal”. Reparem no diagrama acima: um Requisito do Usuário pode se transformar em um Caso de Uso. Pode. Acontece que nem todo requisito é incorporado ao Escopo do Projeto; Foi uma idéia que, por algum motivo qualquer, foi abandonada em determinado momento.

Os Casos de Uso nos ajudam a agrupar logicamente os Requisitos Funcionais. Estes são, portanto, as “menores unidades de solicitações” dos usuários ou clientes. Existe muita confusão neste ponto porque o nível de detalhamento dos requisitos funcionais varia muito, entre organizações e até mesmo entre projetos de uma mesma empresa. Pior: o nível pode variar até mesmo em um mesmo projeto. Não há receitinha mágica aqui. Fábricas normalmente optarão pelo maior nível de detalhamento possível. Equipes mais experientes (ou exigentes) brigarão por espaço para sua “criatividade”, ficando satisfeitas com requisitos definidos em nível mais alto. Em um processo iterativo e incremental, não raro os analistas descobrirão que alguns requisitos funcionais, dada sua superficialidade, se transformarão em requisitos de usuário (e, consequentemente, em novos Casos de Uso), exigindo assim seu maior detalhamento.

Por fim, no lado direito do diagrama, temos os Requisitos Não-Funcionais. Apenas para fins de ilustração aparecem duas especializações: Arquitetura (Tecnológica) e Restrições. Dependendo da organização ou projeto, essa estrutura pode ser modificada de forma a receber outros conjuntos específicos de requisitos não-funcionais. Este grupo e os casos de uso dão forma ao Escopo do Projeto.

.:.

O diagrama acima ilustra o núcleo de uma Base de Conhecimentos para um projeto específico. Gosto de apresentá-la como uma forma de se ver, analisar, desenvolver e gerenciar requisitos. Em projetos de médio e grande porte, ou ainda em empresas que lidam com vários projetos simultâneos, a criação desta base como um banco de dados pode significar um grande avanço em todas as atividades de engenharia de requisitos (desenvolvimento e gerenciamento de requisitos). Na parte 2 deste artigo apresentarei outra parte da base, que trata especificamente dos atributos dos requisitos.Quando discutimos ferramentas para o desenvolvimento e gerenciamento de requisitos, como aconteceu na última oficina, sempre surge a questão sobre o melhor front-end para esta base de conhecimentos. Costumo dizer que nunca vi um front-end melhor do que uma ferramenta CASE, aquela que uso para elaborar os diagramas UML. Há muito tempo vi uma versão do Together que implementava algo parecido. Há mais tempo ainda participei do desenvolvimento de um add-on para o Rational Rose (a implementação foi feita, em VB(!), pelo grande Nelson Ponce de Leon). Simplifica muito o trabalho do analista: um clique com o botão direito do mouse em qualquer elemento UML apresentava a opção Requisitos. Lá podíamos inserir novos ou então ver todos os requisitos vinculados a determinado artefato. A rastreabilidade era total: íamos dos casos de uso e atores até métodos e propriedades de determinada classe. Infelizmente a ferramenta ficou por um tempo esquecida. Felizmente (!) alguns colegas do grupo Analistas de Negócios.br estão trabalhando no desenvolvimento de uma nova versão. Não é difícil perceber que um banco de dados faz muito mais sentido do que documentos Word, planilhas, matrizes imensas (olá Requisite Pro!), post-its ou “papel de pão”. A próxima parte do artigo tentará reforçar isso, falando de análise e rastreabilidade total dos requisitos. Inté.

.:.

Bibliografia:

1. Software Requirements
   Karl Wiegers. Microsoft Press (1999).
2. More About Software Requirements
   Karl Wiegers. Microsoft Press (2006).
3. Requirements-Led Project Management
   Suzanne Robertson e James Robertson. Addison-Wesley (2005).
4. Requirements Engineering – A Good Practices Guide
   Ian Sommerville e Pete Sawyer. Wiley (1997).

2.600km em 3 semanas. Tudo via asfalto (e buracos). Nos últimos 15 dias, dois workshops em Sampa: a 4ª turma do FAN (Formação de Analistas de Negócios) e a 1ª turma do 1º filhote do FAN: Engenharia de Requisitos. O cansaço é grande, mas valeu o esforço. Valeu bem mais do que eu esperava.

A 4ª turma do FAN marcou a despedida de um formato. Quando ele voltar, em fevereiro de 2008, será direcionado para coordenadores de projetos e gerentes de TI. A intenção será mostrar a criticidade e importância dos Analistas de Negócios (AN’s) em projetos e organizações de TI. Será o primeiro de uma nova série sobre Alinhamento Estratégico. A série será composta de maneira ‘bottom-up’: começarei dos AN’s, passarei por processos de desenvolvimento até chegar em arquitetura corporativa. (Estou pensando alto, mas é meu primeiro plano para 2008).

E a prestação de contas (rendiconti) da 4ª turma (07/nov)? Sem querer, ela serviu como experiência para um novo formato. A turma era menor. As interações foram mais freqüentes e ricas. Aliás, minha grande “derrota” foi a terceira turma. Não consegui criar “liga” com a platéia, e o evento terminou com uma hora de antecedência. Na 4ª, repetindo o mesmíssimo roteiro, o resultado foi consideravelmente superior. O problema com a redução do número de participantes é o custo. E, sinceramente, não queria que esses eventos ficassem caros. Estamos, Tempo Real Eventos e eu, analisando possibilidades.

Uma certeza: a “oficina” de Engenharia de Requisitos merecerá uma 2ª turma já em janeiro, dia 18. O FAN, em 2008, aparecerá como dois eventos “levemente acoplados”: Modelagem de Negócios (1ª turma dia 31/jan) e Engenharia de Requisitos. Como no evento de ontem, pelo menos 50% da carga horária será composta de exercícios. Ou seja, “oficina” de verdade.

Não preciso esconder, temia muito pelo evento de ontem. Lotação esgotada, era a primeira aparição pública do “Engenharia de Requisitos”. Na quinta-feira da semana passada, retornando para Vga, deu um “estalo” e resolvi remontar todo o evento (que até então pegava carona nos exercícios que eu havia elaborado para o curso completo de Formação de Analistas de Negócios). Minha preocupação: o negócio e respectivo projeto-exemplo eram relativamente complexos. Eu temia que tal complexidade desviasse o foco de meu principal objetivo: reforçar conceitos, práticas e métodos que formam a Engenharia de Requisitos. Passei sexta e sábado remontando praticamente metade dos 120 slides do evento.

Para minha satisfação, o workshop foi um grande sucesso. O que não significa que foi perfeito. Três participantes reclamaram a não execução integral do roteiro que estava no site do evento. Na revisão, acabei reforçando os exercícios em detrimento de algumas partes exclusivamente teóricas. Mas, na conta final, os participantes gostaram muito. Os exercícios, simulando entrevistas, workshops, sessões de brainstorming e a elaboração de casos de uso, se provaram bem legais. Eficazes no reforço de conceitos e práticas. Em outro post (que só virá depois que eu pagar uma certa dívida com a série sobre EPBE) comentarei um “acidente” que enriqueceu demais a “oficina”. No meio do acidente, perdidos numa imensa nuvem de fatos, idéias e requisitos, um participante concluiu: “Isso acontece em todo projeto!”. Sem perder muito tempo, vimos como é possível “domar” o projeto mesmo naquela fase mais “selvagem”. Mesmo em projetos que requerem muita “selvageria” (aka Criatividade). Mas, como eu disse, é assunto para outro post.

Para a realização do workshop pedi o reforço de 5 “monitores”: pessoas que haviam participado de turmas do FAN e que me ajudariam nos exercícios. A turma foi dividida em 5 grupos. O evento não teria o mesmo resultado não fosse a imensa colaboração de Celso Cândido, Jean Streleski, Nilton Nakate, Rafael Kiss e Reinaldo de Oliveira Castro. Registro aqui meu sincero agradecimento. Devo agradecer também toda a turma que participou. O nível era excelente, o que ficou evidente logo nas primeiras discussões. Eles enriquecem demais os eventos relatando suas experiências, dores e necessidades.

Portanto, nesta reta final para a liberação de todo o material desenvolvido para a Formação de Analistas de Negócios, só tenho uma coisa a lamentar: a não realização do curso de Modelagem de Negócios que estava previsto para o início de novembro. Como eu não seria nada honesto se ‘podasse’ o material, fazendo com que o curso tivesse uma carga horário menor que 35 horas (70 no total, considerando o módulo II sobre Engenharia de Requisitos), tenho que rever a oferta. Realizá-lo aos sábados? Oferecer como treinamento remoto? Sinceramente, ainda não descobri o melhor formato. Mas, tenho certeza, ele sairá ainda no início de 2008.

E ainda não fechei a agenda de 2007 para os eventos gratuitos em escolas, faculdades (públicas ou privadas) e entidades sem fin$. Para minha felicidade, talvez eu finalmente consiga promover um deles em minha terra natal, Minas. Mais precisamente em Lavras (UFLA). Tô torcendo muito por isso. Outra oportunidade é São Carlos. Estou torcendo para o Reinaldo achar uma data. Final de ano é difícil, mas estamos brigando para viabilizar outras viagens do FAN. Mais 2 mil e tantos kilômetros de asfalto farão muito bem para o conteúdo.

Há uns 6 anos me ‘cansei’ do estudo de engenharia de requisitos. Técnicas e métodos mudavam, mas mantinham uma sensação de déjà vu. As mudanças eram cosméticas ou uma questão de nomenclatura. As propostas “ágeis” (aspas não tornam o termo pejorativo) colocaram o Conhecimento Tácito na “coluna esquerda” (leia-se: nomearam-no o mais importante). Essa talvez tenha sido a mudança mais significativa nos últimos 10 anos da disciplina. Mas, basta olhar os métodos e técnicas sem muita paixão para descobrir que tem muito ‘revival’ ali, pouca coisa original.

Foi quando decidi olhar a estranha disciplina “gestão do conhecimento” com um pouco menos de ceticismo. Pouquíssimos trabalhos fazem a relação desta com a engenharia de requisitos, o que acho estranho. Na época encontrei apenas uma excelente tese sobre “Gestão de Conhecimentos Inter-Projetos” , que acabou inspirando meu trabalho sobre “Aprendizado Inter-Projetos“. Surrupiei algumas teorias para orientar também minha nova imersão na disciplina engenharia de requisitos.

O trabalho que me ‘pegou’ foi o clássico “Theory of Organizational Knowledge Creation”, de Hirotaka Takeuchi e Ikujiro Nonaka . Foi ali que conheci os 4 modelos de conversão de conhecimentos (figura acima). Prometo ser breve (na explicação das 4 formas):

• Socialização: pessoas trocando idéias, de forma direta, conversando. É um canal rico, já que nossa comunicação não se limita a palavras, gestos e desenhos. Um sorriso pode ter n significados.
• Externalização: pessoas transferindo seus conhecimentos para o papel (ou disco rígido, não importa). Estamos registrando idéias e experiências, de forma que elas possam ser úteis para outras pessoas.
• Internalização: quando são (úteis), acontece a internalização. Ou seja, as pessoas aprendem ao ler um documento, diagrama ou rabisco.
• Combinação: por fim temos a combinação, a transformação de um conhecimento explícito (texto, por exemplo), em outra forma de conhecimento explícito (diagrama ou código, por exemplo).

Quando trato especificamente de engenharia de requisitos, gosto de dividir o diagrama acima em duas partes: o hemisfério esquerdo trata da coleta, descoberta e invenção de requisitos (estamos aprendendo). O hemisfério direito cuida de como analisamos, modelamos e comunicamos* os requisitos.
* Observação: a comunicação também envolve o quadrante ‘socialização’.

Está aqui uma daquelas idéias que chamo de bullshitagenzinhas das propostas “ágeis”. É inocente ou, melhor dizendo, ingênuo pensar que apenas através da socialização nós aprendemos tudo o que precisamos para executar um projeto. Sei que o princípio, em sua origem, não diz “apenas”. Mas, infelizmente, muitos interpretam assim.

Há tempos é raríssimo um projeto de software que não envolva algum tipo de integração com um sistema existente. E não aprenderemos as entranhas daquele sistema com um usuário sentado ao nosso lado. Ou seja, temos que aprender de uma forma diferente, com a chamada internalização. Estudaremos documentos e, na maioria das vezes, código-fonte mesmo. Em iniciativas SOA, onde a sobrevida aos sistemas legados é um grande objetivo, a internalização se faz obrigatória. Um método de análise recomendado é chamado “meet in the middle”:

Enquanto uma parte da equipe interage com clientes e usuários, aprendendo o negócio e seus requisitos, outra parte analisa os sistemas existentes. Em um momento “mágico” eles “se encontram no meio do caminho”, confrontando requisitos, realidades, verdades, mentiras e restrições.

Cada forma de aprendizado exige um conjunto bastante distinto de habilidades soft e hard. Uma distinção que, infelizmente, o BABoK (ainda) não faz. No próximo post falarei um pouco mais sobre socialização, internalização e as principais técnicas de levantamento e descoberta de requisitos de cada uma delas. Lógico, além das habilidades requeridas para executá-las. Habilidades que devem caracterizar um bom analista de negócios.

Notas:

1. Knowledge Management in Inter-Project Learning
   Daniel Fitzek. ITEM-HSG Universität St.Gallen (2002).
2. Theory of Organizational Knowledge Creation
   Hirotaka Takeuchi e Ikurijo Nonaka.
   Publicado em “Knowledge Management – Classic and Contemporary Works”. MIT Press (2000).

Uma turma da universidade Anhembi Morumbi está realizando uma extensa pesquisa sobre Engenharia de Requisitos, particularmente técnicas de levantamento.

Repasso aqui o convite para que todos os *praticantes* participem da pesquisa. O 1º questionário já está disponível no site que eles desenvolveram especificamente para o projeto.

Parabéns para a turma. Trata-se de uma importante iniciativa. Rarírissima por essas bandas. Espero ter a chance de conhecer os resultados e comentá-los aqui no finito.

Update: Prazo foi prorrogado para 12/Abril.