Processos de Obtenção de Requisitos – Parte (2/8) – Questionário

Os questionários podem ser um excelente método para obtenção de requisitos como forma complementar a uma entrevista.
Pode ser tentador utilizar o tempo dedicado a uma entrevista para o planejamento e envio de inúmeros questionários a serem respondidos, mas não existe nenhum substituto para o contato pessoal, construção do entendimento e interação em formato livre da técnica de entrevista.
A técnica do questionário tem os problemas:

• Questões relevantes podem não ser levadas adiante;
• As suposições utilizadas no planejamento das questões influenciam nas respostas;
• É difícil explorar novos domínios e não existe interação para explorar domínios que precisam ser explorados;
• Respostas não claras ou ambíguas do usuário podem levar a conclusões e definições incorretas.

No entanto essa técnica pode ser aplicada com bons resultados após a entrevista inicial para validar ou complementar suposições, para informações/questões com um número limitado de escolhas/respostas, para num número muito grande de usuários (usuários principais poderão passar por entrevistas e outros usuários responderem questionários) e para levantamentos estatísticos.
Quanto maior o entendimento de um universo, maior a possibilidade de um questionário ser bem utilizado, mas em momento nenhum deverá ser utilizado em substituição à entrevista.

Fonte:
LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements. 1. edição, Reading MA, Addison-Wesley Professional. 1999.

Gerenciamento de Comunicações em Projetos - Matriz de Comunicação

Uma parte importante em um projeto, que freqüentemente acaba não sendo muito privilegiada, é o gerenciamento das comunicações.
Dentro da Engenharia de Requisitos a comunicação formal se torna bastante importante na gestão das mudanças nos requisitos (solicitações de mudanças).
O gerenciamento das comunicações do projeto é o setor que emprega os processos necessários para garantir a geração, coleta, distribuição, armazenamento, recuperação e destinação final das informações aos envolvidos no projeto. Devem ser especificados métodos que permitam a transmissão da informação de maneira clara e sem ruídos (alterações).
A matriz de comunicação é uma ferramenta que especifica quais documentos serão comunicados, para quais stakeholders (envolvidos no projeto), em que freqüência (quando) e por qual meio (como). Ela deve estar presente dentro do plano de gerenciamento das comunicações do projeto (documento de planejamento das comunicações). Ela pode ser criada em qualquer software básico de escritório.

Exemplo de Matriz de Comunicação

Uma matriz de comunicação tem as informações (poderão ser alteradas/adaptadas conforme necessidades específicas):

1.    Tipo - tipo da comunicação. Ex: reunião de status mensal, reunião com usuário, prestação de contas semanal, relatório de status do projeto, etc.
2.    Objetivo - descrição da comunicação. Ex: informar status atual aos participantes do projeto, informativos financeiros de gastos/receitas, etc.
3.    Meio - meio da distribuição da informação. Ex: e-mail, telefone, comunicador instantâneo, vídeo-conferência, reunião presencial, etc.
4.    Periodicidade - freqüência, motivo ou datas específicas que deve ocorrer à comunicação. Ex: semanal, mensal, em qualquer “estouro” de prazo, em qualquer “estouro” em custos, etc.
5.    Destinatário(s)- envolvido(s) que deve(m) receber a comunicação. Ex: usuários, stakeholders, analistas de sistemas, programadores, gerente do projeto, diretor técnico, patrocinador, fornecedor, etc.
6.    Responsabilidade- responsável pela informação. Ex: gerente do projeto, analista de sistemas responsável, etc.
7.    Documento(s) - documento(s) gerado(s). Ex: ata de reunião, relatório de status do projeto, planilha de custos do projeto, etc.

Negligenciar a comunicação em um projeto poderá trazer diversas conseqüências negativas.  Membros da equipe terão diferentes conhecimentos sobre projeto, patrocinadores não estarão informados sobre o andamento, membros participantes poderão não receber informações vitais e necessárias, entre outras conseqüências, que poderão trazer impactos em cronograma, prazos e custos.

Fonte:
Project Management Institute Inc. Guia PMBOK. 3. edição. Project Management Institute Inc. 2004.

Processos de Obtenção de Requisitos – Parte (1/8) – Entrevista

A obtenção de requisitos é o processo de reunir informações sobre os sistemas existentes e sobre o sistema proposto. Para isso são usadas como fontes de informações documentações atuais, conhecimento de usuários do sistema e outros participantes do projeto e especificação de sistemas atuais utilizados e de outros sistemas similares.

Uma técnica simples, importante e que pode ser utilizada em qualquer situação é a entrevista.

Uma entrevista pode ser aberta ou fechada:

• Entrevista Aberta, não existe um roteiro a ser seguido, o entrevistador explora vários assuntos e busca uma compreensão mais ampla das necessidades;
• Entrevista Fechada, o entrevistado responde a um conjunto de perguntas específicas e pré formuladas.

Na prática costuma ser realizada uma mistura desses dois tipos, procurando utilizar o melhor dos dois mundos, tendo algumas perguntas para serem usadas como ponto de partida e perguntas chave que serão importantes para o projeto e prosseguindo de forma mais livre (mas mantendo foco) para entender melhor as necessidades do entrevistado.

A entrevista é bastante útil para o entendimento geral do sistema atual e para entender as dificuldades enfrentadas e novas necessidades dos usuários. Mas ela pode ser menos eficiente para obtenção de requisitos ligados as estruturas organizacionais, pois nem sempre numa organização a estrutura real de tomada de decisões coincide com a estrutura oficial e esse tema geralmente é um assunto “tabu”.

Para uma entrevista produtiva o Analista de Requisitos ou Analista de Sistemas precisa de uma prévia preparação (estruturação da entrevista). Algumas dicas são:

• Preparação de uma lista de perguntas iniciais e perguntas importantes. Nessas perguntas, num primeiro momento, é importante uma maior liberdade e evitar a indução de respostas, em fases mais adiantadas poderão ser utilizadas perguntas com respostas mais fechadas;
• Revisão das perguntas momentos antes da entrevista e eventualmente consultas (se forem necessárias e breves) poderão ser feitas durante a entrevista;
• Antes da entrevista é útil fazer uma pesquisa sobre a empresa e sobre o entrevistado, isso evitará desperdício de tempo, mas informações importantes devem ser verificadas durante a entrevista;
• Repostas poderão ser anotadas numa agenda durante a entrevista ou gravadas eletronicamente (muitas pessoas se sentem desconfortáveis com informações sendo gravadas, então...). O ideal é manter um equilíbrio de tempo entre anotações e perguntas, tentando não “quebrar” o raciocínio e a entrega de informações do entrevistado.

Modelo de uma entrevista estruturada:

Parte 1 – Estabelecendo o perfil do cliente/usuário

Previamente poderão ser pesquisadas informações como nome do entrevistado, cargo, nome da organização, ramo de atividade, entre outras informações relevantes.

No inicio da entrevista algumas perguntas são:

Quais são as suas responsabilidades?

Quais são os produtos do seu trabalho?

Para quem você gera esses produtos?

Como é medido o seu sucesso?

Quais são os problemas que interferem para o sucesso de seu trabalho?

O que, se existe, facilita ou dificulta o seu trabalho?

Parte 2 - Avaliando o Problema

Para quais problemas faltam boas soluções?

Quais são? (Dica: Continue perguntando, “Mais algum?”).

Para cada problema, pergunte:

• Por que esse problema existe?
• Agora, como resolvê-lo?
• Como você poderia resolvê-lo?

Parte 3 - Entendendo o Ambiente do Usuário

Quem são os usuários?

Qual é a sua formação?

Qual é a sua experiência em computação?

Os usuários são experientes nesse tipo de aplicação?

Quais plataformas são usadas?

Quais são os planos para a futura plataforma?

Outras aplicações usadas são relevantes para essa aplicação? Se sim, fale um pouco sobre elas.

Quais são as suas expectativas para a usabilidade do produto?

Quais são as suas expectativas para o tempo de treinamento?

Que tipo de auxílio ao usuário você precisa (ex: cópia impressa ou documentos on-line).

Parte 4 - Recapturando para Entender

Você me disse que:

(Liste os problemas que o cliente descreveu com suas próprias palavras).

• ·
• ·          
• ·          
• ·          

Eles representam adequadamente os problemas que você está tendo com a solução existente?

Quais outros problemas, caso exista, você está enfrentando?

Parte 5 - Suposições do Analista sobre o Problema do Cliente

(Valide ou invalide suposições).

(Se não foi discutido) Quais problemas, se houver, estão associados: (Liste quaisquer necessidades ou problemas adicionais que você acha que está preocupando o cliente ou o usuário).

• ·          
• ·          
• ·          

Para cada problema sugerido, pergunte:

Esse é um problema real?

·         Quais são as razões deste problema?

·         Como você gostaria de resolvê-lo?

·         Qual é o peso da solução desse problema, comparado aos outros que você mencionou?

Parte 6 - Avaliando a sua Solução (se aplicável)

(Resuma as principais capacidades da solução que você propôs).

O que aconteceria se você conseguisse:

• ·          
• ·          
• ·          

Como você classificaria cada uma dessas capacidades, por ordem de sua importância?

Parte 7 - Avaliando a Oportunidade

Quem na sua organização precisa dessa aplicação?

Quantos usuários desse tipo usariam a aplicação?

O que você considera que seja uma solução bem sucedida?

Parte 8 - Avaliando Necessidades de Segurança, Desempenho e Suportabilidade (pode não ser aplicável a todos os usuários)

Quais são suas expectativas sobre a segurança?

Quais são suas expectativas sobre o desempenho?

Você irá dar suporte ao produto ou serão outras pessoas que farão isso?

Você tem necessidades especiais de suporte?

O que você pensa sobre a manutenção e serviços de rede?

Quais são os requisitos de segurança?

Quais são os requisitos de instalação e configuração?

Existem requisitos especiais de licenciamento?

Como o software será distribuído?

Existem requisitos de etiquetagem ou de empacotamento?

Parte 9 - Outros Requisitos

Existe algum requisito legal, de regulação, ambiental ou de padronização que deva ser atendido?

Você acha que existem outros requisitos que devemos conhecer?

Parte 10 - Fechamento

Existe alguma outra questão que eu deveria ter feito?

Se depois, eu tiver alguma dúvida, posso ligar para você? Enviar e-mail?  Você concorda em participar de uma revisão de requisitos?

Parte 11 - Resumo do Analista

Depois da entrevista, e enquanto as informações estiverem frescas em sua mente, resuma as três necessidades ou problemas de maior prioridade identificados pelo usuário/cliente.

1.

2.

3.

Os resultados das entrevistas deverão ser compilados. É esperado que se encontrem necessidades e problemas comuns entre os entrevistados. Esse será o inicio de um “repositório” de requisitos que dará origem aos futuros documentos de requisitos.

Embora seja importante, a entrevista não deve ser o único método de obtenção de requisitos, mas utilizada em conjunto com outros métodos.

Breve: Processos de Obtenção de Requisitos – Parte (2/8) – Questionário

Fontes:

SOMMERVILLE, Ian. Engenharia de Software. 8. edição. São Paulo. Pearson Education do Brasil. 2007.

LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements. 1. edição, Reading MA, Addison-Wesley Professional. 1999.

Custo de erros em projetos de desenvolvimento de software

Cada projeto é único (mesmo projetos semelhantes terão diferenças significativas) e é impossível fazer estimativas ou ter fórmulas genéricas para estimar o custo de erros que poderão acontecer.

Na monografia de Marco Aurélio Cordeiro para o curso de Pós Graduação em Informática Aplicada da Pontifica Universidade Católica do Paraná (Curitiba, 2002) ele cita um estudo realizado nos anos 70 pelas empresas GTE, TRW e IBM, onde um custo relativo de um erro localizado durante a análise de requisitos é 0.1, já um erro localizado na fase de implementação é 1 (10 vezes mais), na fase de testes seu custo relativo sobe para 2 (20 vezes mais), terminando com um custo relativo de 20 (200 vezes mais) na fase final de manutenção. O gráfico abaixo retrata essa situação.

 

Vale ressaltar que esse é um estudo realizado numa outra realidade de desenvolvimento de software muito diferente da atual (anos 70), mas que já mostra que há muito tempo o custo para correção de erros é uma preocupação nas organizações.

Já na monografia de Paulo Henrique Ramos apresentada no curso de Mestrado em Ciência da Computação na Universidade Federal de Pernambuco (Recife, 2011) ele cita um estudo onde o custo de uma falha localizada na fase de testes pode ser 30 vezes o custo inicial, se ele fosse localizado na fase inicial (análise de requisitos).

Roger S. Pressman no livro Engenharia de Software (6. edição, 2006) declara que o custo de defeitos na fase de projeto é cerca de três a seis vezes mais alto do que na definição de requisitos e o custo é ainda maior em fases finais como na fase de testes.

Seja qual for a metodologia usada ou o estudo utilizado, a conclusão é sempre que o custo de correção de um defeito é sempre muito inferior quando identificado no inicio de um projeto e muito superior quando identificado na finalização do projeto.

A importante fase Análise de Requisitos exige maior qualidade, pois suas falhas poderão comprometer todo o projeto.

Gerenciamento de Mudanças

O gerenciamento de mudanças de requisitos deve ser aplicado a todas as mudanças propostas (requeridas) sobre os requisitos. Obrigatoriamente é um processo formal, para que todas as requisições de mudanças sejam tratadas consistentemente e as mudanças no documento de requisitos sejam feitas de maneira controlada (SOMMERVILLE, 2007).

A natureza dos projetos com sua elaboração progressiva e aumento do seu entendimento durante sua evolução/execução leva a mudanças. Essas mudanças não devem ser evitadas (com o risco do projeto fracassar), é preciso lidar com elas.

Para os fornecedores/desenvolvedores de software o universo ideal é onde os projetos de sistemas a serem desenvolvidos tenham um orçamento aberto onde seja remunerada a hora técnica de cada colaborador envolvido pelo tempo que o projeto durar (onde cada mudança solicitada gera alterações no prazo e ou no custo). Nessa situação ideal mudanças nos requisitos e no escopo são situações bem aceitas, pois são igualmente remuneradas.

Por outro lado, a situação mais crítica é num orçamento fechado e não aberto a alterações, onde será necessário lidar com as mudanças de requisitos permanecendo dentro de um cronograma estipulado e sem ultrapassar os custos negociados.

Acima um exemplo de um processo de mudança em um requisito, iniciado com a identificação de um problema, passando por uma análise do problema, uma análise das mudanças e seus custos para o projeto (nessa fase ocorreria a aprovação da mudança solicitada) e terminando com a implementação e documentação das mudanças.

1. Análise do problema e especificação da mudança: problema identificado ou mudança requerida tem sua viabilidade analisada e eventuais dúvidas são tiradas junto ao seu solicitante.
2. Analise da mudança e estimativa de custos: é feita análise dos efeitos da mudança junto a outros requisitos (podem ocorrer conflitos entre requisitos) e são estimados os custos dessa mudança no projeto. Completadas essas análises ocorrerá a decisão se a alteração prosseguirá ou que negociações serão necessárias para sua aprovação.
3. Implementação da mudança: atualização do(s) documento(s) de requisito(s).

As mudanças em um projeto serão inevitáveis. A situação mais equilibrada é onde as solicitações de mudanças sejam analisadas e seus impactos avaliados. Essas mudanças terão que ser autorizadas por diferentes níveis hierárquicos, proporcional aos impactos avaliados ao projeto. Impactos classificados como grandes (relevantes nos custos e ou no cronograma) poderão levar o fornecedor a renegociações junto ao cliente.

Referência:

SOMMERVILLE, Ian. Engenharia de Software. 8. edição. São Paulo. Pearson Education do Brasil. 2007.

Importância da Análise de Requisitos (1)

"Cerca de 80% dos problemas de desenvolvimento de software originam-se nos requisitos (levantamento, entendimento, gerenciamento, etc)."  Foina, 2006.

"Conforme o Standish Group, somente um em cada cinco projetos de ERP cumpre o escopo prometido no prazo e no orçamento planejado inicialmente."  Foina, 2006.

FOINA, Paulo Rogério. Tecnologia de Informação. 2. edição. São Paulo. Editora Atlas. 2006.

Documento de Lições Aprendidas em Projetos

Um importante documento em um projeto que muitas vezes é visto com pouca importância ou apenas como mais uma formalidade a ser cumprida é o Documento de Lições Aprendidas. Esse documento visa que os erros passados não sejam mais cometidos e que acertos possam ser mais facilmente repetidos.

Muita da experiência (boas e ruins) adquirida em um projeto acaba permanecendo apenas na memória de seus participantes e a documentação dessas “memórias” é importante para melhoria contínua de projetos atuais e futuros de uma organização.

A construção dessa documentação não exige um software específico ou complexo, mas poderá ser construído em software básico de escritório como um processador de textos ou uma planilha eletrônica.

No geral eu utilizo as seguintes informações a serem preenchidas (colunas de uma planilha):

1) Área – área, setor ou departamento dentro do projeto. Ex: Custos, Aquisições, etc.

2) Assunto – uma breve descrição da lição a ser documentada. Ex: Arrecadação financeira, Controle dos riscos, Atrasos, Problema com fornecedor, etc.

3) Descrição – uma descrição mais detalhada e explicativa da lição a ser documentada.

4) Pessoa – nome (em alguns casos pode ser necessário também um código) do integrante do projeto que está documentando a lição.

5) Efeito – Positivo ou negativo para o projeto.

6) Resposta/Ação – Atitudes que podem ser tomadas para evitar (ou minimizar) um efeito negativo ou favorecer um efeito positivo.

Vale lembrar que o caráter desse documento é de livre acesso (mesmo que com algumas restrições) por pessoas de diferentes projetos dentro da organização. Informações confidenciais devem integrar outros documentos mais restritos.

Fatores como prazos, falta de interesse ou conhecimento e preocupação em iniciar novos projetos muitas vezes fazem com que esse importante documento deixe de ser feito.

Causas de Fracasso de Projetos de Desenvolvimento de Software

Periodicamente é realizada no Brasil a Pesquisa Archibald & Prado (ocorreram nos anos de 2005, 2006, 2008 e 2010) onde organizações de diversos portes e ramos de atividade respondem um questionário a respeito de projetos realizados.

Na pesquisa realizada entre setembro e dezembro de 2010 participaram 345 organizações brasileiras e num dos tópicos analisaram as 3 principais razões do fracasso no desenvolvimento de software. O gráfico abaixo mostra as causas apontadas:

O conceito de fracasso utilizado na pesquisa foi: "projeto foi paralisado ou o produto/serviço entregue não está sendo utilizado por não atender às expectativas dos usuários ou o atraso foi tal que implicou em perdas para o negócio. O usuário/cliente ficou profundamente insatisfeito."

Frequentes mudanças de escopo (76%)

Freqüentes alterações de prioridade (34%)

Alterações em necessidades do cliente e identificação de novas necessidades é um fato comum dentro dos projetos de desenvolvimento e um processo formal de Gerenciamento de Mudanças se faz necessário para manter os controles de prazo e custo.

Ocorre que uma mudança muito grande (sendo ou não uma alteração no escopo) e não esperada fará com que qualquer margem de segurança ou plano de contingência percam a sua eficiência ou se tornem inúteis.

Tal ocorrência força a uma renegociação entre cliente e fornecedor, mas nem sempre cliente pode alterar seu investimento no projeto ou conceder mudanças no prazo de entrega e nem sempre o fonecedor pode assumir maiores custos com o projeto alterando assim sua receita (em casos graves podendo chegar até a uma receita negativa).

Comprometimento insuficiente ou inadequado das áreas usuárias envolvidas (38%)
Comprometimento insuficiente ou inadequado da alta administração (7%)

Diversos motivos podem levar a um "boicote" por parte de usuários chave. Usuários frequentemente são resistentes a grandes mudanças, mas eventualmente podem estar envolvidos demais com as atividades cotidianas e sem tempo disponível para dedicação ao projeto.

Usuários podem se desinteressar do projeto ao perceberem que gestores de cargos mais altos não estão comprometidos. Sem apoio desses gestores outras atividades receberão maiores atenções.

Em qualquer causa identificada, é importante que sejam procuradas soluções e buscado um maior envolvimento dos usuários. Em casos graves tem que existir uma requisição para que usuários participantes do projeto sejam substituídos. Uma permanência com esse problema levará a problemas no cronograma e consequentemente a estouro no prazo final do projeto.

Precariedade de método, ferramentas e técnicas para o gerenciamento dos projetos (38%)
Insuficiente capacidade gerencial dos Gerentes de Projetos (7%)

Processos formais de gerenciamento de projetos, como por exemplo o Guia PMBOK do Project Management Institute, são importantes para descrever de forma organizada o trabalho a ser realizado por diferentes áreas e especialidades durante o projeto possibilitando o intercâmbio eficiente de informações entre os profissionais envolvidos.

Quanto maior e mais complexo o projeto, maior a necessidade de diferentes profissionais e equipes conseguirem atuar em conjunto com eficiência.

Tamanho da carteira de projetos muito além da capacidade de atendimento do setor (31%)
Habilidade técnica da equipe, em T.I., insuficiente ou inadequada para os desafios (7%)

A demanda cada vez mais crescente das empresas por tecnologia também exige cada vez profissionais mais qualificados. O problema central é que maior qualificação exige maior investimento, mas acompanhando notíciais, percebo que nem governo e nem indústria privada querem arcar com esses custos, deixados para investimento maior dos profissionais interessados e quem possam pagar esses custos.

É importante uma parceria maior entre universidades e indústrias privadas, a fim de qualificar profissionais com necessidades reais do mercado.

Falta de recursos humanos, financeiros e materiais (24%)
Estudo de Viabilidade incompleto ou incorreto (21%)
Prazos inexeqüíveis (17%)
Riscos não adequadamente gerenciados (14%)


Um planejamento adequado feito com processos adequados minimiza problemas com prazos e custos. Da mesma forma uma Análise de Riscos poderá prever contingências e provisões para muitos problemas que podem ocorrer durante o projeto. Mas alterações muito expressivas durante a execução de um projeto poderão fazer fracassar qualquer planejamento.

Ocorre que pressões por soluções rápidas pode forçar que um projeto seja aprovado com uma expectativa de conclusão não viável. Nem sempre argumentos de profissionais responsáveis poderão persuadir uma reavaliação de projetos com essa característica.

Conforme um professor meu dizia, com tantos riscos, problemas e possibilidades de fracasso que ocorrem e projetos bem organizados acabam fracassando, existe uma solução concreta?
A solução concreta não existe, mas fazer de forma adequada favorece uma maior chance de êxito e fazer de forma incorreta chances mais certas para o fracasso.

Requisitos Futuros

Projetos de desenvolvimento ou aquisição de um software normalmente passam por reformulações até que um consenso seja atingido (ou espera-se que seja atingido) entre cliente e fornecedor. E mesmo após consenso atingido, alterações são sempre esperadas (o tema gerenciamento de mudanças fica para uma outra ocasião).

Diversos motivos contribuem para a existência dessas reformulações, podendo ser citados:

• restrições no prazo ou no custo

As expectativas do cliente nem sempre podem ser atingidas dentro de prazo e custo desejado. Nesse caso pode ocorrer a necessidade de alteração no escopo do projeto, no prazo ou no custo final.

• mudanças nas necessidades do cliente

As necessidades do cliente podem mudar por fatores como alteração nas leis, mudança na visão estratégica da empresa, novos produtos ou mercados, crise econômica, entre outros. Quanto mais longo o projeto maior a possibilidade de surgirem mudanças significativas (que possam afetar as variáveis PRAZO x CUSTO).

• restrições tecnológicas

Capacidade de processamento de máquinas, custo de tecnologias a serem adquiridas, restrições para importações, restrições do fornecedor, etc são motivos que podem gerar reformulações e adequações.

Durante o processo de elucidação de requisitos surgem requisitos que são apropriados para a utilização em uma próxima versão ou projeto futuro. Esses requisitos futuros devem ser registrados em um documento que poderá ou não ser entregue ao cliente, mas que poderá servir de referência para oferecimento de novos produtos ou serviços ou para utilização em outros projetos.

Importância da classificação de requisitos

A classificação dos requisitos é de extrema importância para a definição de prioridades, para a separação por níveis de importância, riscos, custos, etc e para validação por diferentes pessoas envolvidas.

Um requisito não atendido pode, em casos mais graves, inviabilizar todo um projeto ou causar aumentos expressivos em prazos e custos.

Uma classificação clássica e bastante utilizada é a divisão dos requisitos como funcionais e não funcionais:

Requisitos funcionais são especificações sobre as funcionalidades que o sistema deve fornecer, características que ele deve ter e como deve se comportar em determinadas situações. Pode estabelecer características que não devem ser feitas.

Ex: um usuário pode informar que o software deverá pedir um ou dois vendedores em cada venda (é obrigatória a seleção de pelo menos um vendedor). A comissão para esses vendedores deve ser automaticamente calculada baseada numa tabela prévia e na situação de dois vendedores informados, a comissão deverá ser dividida entre os dois com os valores proporcionais.

O exemplo acima descreve uma regra de negócio do cliente envolvendo uma situação de venda. Encaixa-se como um requisito funcional por descrever uma característica que o sistema deverá ter em uma determinada situação.

Requisitos não funcionais são requisitos que não estão relacionados a funcionalidades específicas do sistema, mas a funções mais genéricas sobre o sistema como um todo. Esta categoria de requisitos inclui restrições de tempo de resposta, definições do processo de desenvolvimento do sistema, características da interface do sistema, ambiente do sistema, etc. Por definição não se aplicam às características individuais do sistema.
Os requisitos não funcionais surgem por diferentes razões, como necessidades do cliente, restrições de orçamento, políticas e características organizacionais, restrições técnicas do fornecedor, regulamentos de segurança, leis, entre outros.

Ex 1: um cliente poderá pedir que o software deva funcionar nos sistemas operacionais Windows e Linux e deverá utilizar um banco de dados gratuito.

No exemplo o cliente pediu características gerais que envolverão decisões sobre as ferramentas de desenvolvimento do sistema e o banco de dados a ser utilizado. São características que afetarão todo o software e não situações específicas.

Ex 2: o cliente quer que os relatórios diários do sistema comecem a imprimir em no máximo 3 segundos.

Essa necessidade envolve o tempo de resposta de uma parte do software (relatórios diários) e não de alguma funcionalidade específica.

O não atendimento de requisitos não funcionais pode inviabilizar projetos ou pode envolver custos bastante diferenciados de desenvolvimento. Ferramentas de desenvolvimento e softwares de banco de dados podem não funcionar em diferentes sistemas operacionais e empresas desenvolvedoras podem não ser especializadas em diferentes sistemas operacionais. Essas características podem resultar em orçamentos bastante diferenciados entre os fornecedores.

Estudo de um caso real:

Eu respondi a um questionário por e-mail para avaliação para participação em uma concorrência de compra de um software comercial. A empresa X (potencial cliente) apresentou uma séria de perguntas e necessidades à empresa Y (potencial fornecedor). O software em questão seria um básico sistema de controle de estoque/financeiro.

As necessidades do cliente eram comuns para a situação e não envolveriam custos diferenciados de um orçamento padrão. Ocorreu que uma das perguntas não se encaixava no contexto das outras, era sobre modelos de impressora compatíveis com um celular IPhone.

Perguntei diretamente ao potencial cliente sobre a pergunta em específico e descobri, embora não mencionado explicitamente, que o software deveria funcionar em celulares IPhone e não em computadores comuns. Ocorram contatos com o potencial cliente, a fim de refinar e entender as reais necessidades.

A conclusão foi que seria inviável para a empresa Y a realização do projeto dentro das expectativas do cliente em termos de prazo e custo final. Também foram levantadas, junto ao possível cliente, questões sérias se o ambiente operacional de um celular seria eficiente para a utilização do software desejado.

Requisito

O que é requisito?

O termo requisito é utilizado com diferentes significados, por diferentes autores. Pode ser uma definição abstrata de um serviço que um sistema deve fornecer, uma restrição, ou uma definição formal e detalhada de um serviço do sistema. Requisitos refletem as necessidades dos clientes de um sistema para resolver os problemas identificados (SOMMERVILLE, 2007).

Os autores Leffingwell e Widrig (1999) apresentam diferentes definições para requisito:

• Numa definição bastante simples, um requisito é uma característica que o sistema deve apresentar;
• Pode ser definido como uma característica do sistema que o usuário precisa a fim de resolver um problema e atingir seu objetivo;
• Numa definição mais complexa, requisito é uma capacidade que deve ser possuída por um sistema ou por componentes de um sistema para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos.

Pela minha definição: requisito é a formalização de uma necessidade ou de um desejo de um cliente.

SOMMERVILLE, Ian. Engenharia de Software. 8. edição. São Paulo. Pearson Education do Brasil. 2007.

LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements. 1. edição, Reading MA, Addison-Wesley Professional. 1999.

O inicio

Sou um profissional de TI com quase 20 anos de experiência em projetos de desenvolvimento de software comercial.

Abro esse espaço com a pretensão de transmitir conhecimento, seja por meio de dicas, artigos, comentários e tudo o mais que a vivência em meio a outros profissionais de TI e a usuários me trouxe.

Que eu possa acrescentar uma pequena gota, no grande oceano de informações da Internet.

Fernando Firpo