domingo, 29 de maio de 2011

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.

quarta-feira, 25 de maio de 2011

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.

domingo, 22 de maio de 2011

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