Requisitos no funcionais

Bruno Braga on February 12th, 2009

Um colega me perguntou ontem sobre o levantamento de requisitos no funcionais em sistemas, ento vou aproveitar que estou devendo posts aqui e falar sobre isso. Conceito Requisitos no-funcionais descrevem qualidades do sistema (como o sistema ) ao invs de suas funcionalidades (o que ele faz). A qualidade afeta diretamente a satisfao do cliente e envolvidos com o sistema. Por isso requisitos no funcionais so importantes. A idia explorar essa questo para ter um cliente mais feliz no final do projeto. A qualidade de um software pode ser avaliada de duas maneiras. A qualidade visvel para o usurio final e a qualidade interna visvel em tempo de desenvolvimento (mas que permite ou no evolues do software). Exemplos Requisitos de qualidade visveis ao usurio Usabilidade: resista a solicitaes como O software deve ser amigvel para o usurio. Isso no suficiente. Explore o assunto e questione: Como podemos testar e garantir que o software amigvel? O que esperado?. Provavelmente o cliente responda: Eu quero que o usurio no precise dar mais de 3 clicks para acessar as informaes e possa acessar a ajuda online de qualquer pgina do sistema. Pronto. Conseguimos extrair um requisito no funcional de usabilidade. Performance: Todo o sistema deve ter a melhor performance possvel tambm no um bom requisito de performance. Em um sistema grande nem sempre todas as partes do software tem que ter a mesma performance. Se explorarmos o assunto com o cliente muitas vezes ele pode dizer: A parte principal do meu software o cadastro e atendimento de solicitaes e vrias atendentes cadastram novas solicitaes o tempo todo. Para ter produtividade o preenchimento e processamento desse cadastro no pode demorar mais do que 30 segundos. Mas os outros cadastros no so to crticos. Isso um requisito no funcional mais adequado e possvel de ser implementado. Os desenvolvedores podem focar no que realmente importante, fazer politicas de cache para esse caso e outras estrategias sem aumentar o custo do software como um todo.

Geralmente em tempo de levantamento de um software o usurio no se lembra de informar os requisitos no funcionais. Ele est preocupado com as funcionalidades do sistema. Por isso o Analista de Requisitos deve explorar e questionar esse assunto. Segue um questionrio que pode ser utilizado para iniciar a conversa sobre esse tema: Questionrio 1. Quantas pessoas vo utilizar o software? Desse nmero, quantas utilizaro simultaneamente? (no precisa ser um valor fechado pode ser um range: entre 100 e 200 pessoas utilizaro e esperado que no mximo 50 utilizem simultaneamente); 2. Dos relatrios previstos, quais podem ser gerados por processamento batch (de madrugada) e quais devem ser online (com dados do momento)? Qual o tempo aceitvel para processar e gerar um relatrio online? 3. Qual o tempo de resposta esperado para as principais funcionalidades do sistema? E para as outras?

4. Qual tipo de acesso a aplicao vai ter? Somente via intranet? Internet? 5. Qual o perfil dos usurios que vo acessar a aplicao? Possuem conhecimento de internet? So usurios avanados? 6. desejvel que a maior parte das funcionalidades da aplicao possam se acessadas via teclado (sem auxilio do mouse)? 7. A aplicao deve ser compatvel com quais verses do browser e/ou sistema operacional? 8. Quais os padres de implementao esperados? Os desenvolvedores podem escrever o cdigo em qualquer idioma? Podem utilizar qualquer banco de dados e qualquer tecnologia? 9. Qual a segurana esperada para o trafego de dados? Toda comunicao entre o servidor e o browser tem que ser criptografada usando SSL? Ser adquirido o certificado SSL? Ou a aplicao no tem dados criticos e confidenciais / vai ser executada em uma rede segura? 10. Qual a disponibilidade a aplicao deve ter? O tempo mdio entre falhas, tempo mximo para acertar os problemas? Nmero mximo de bugs em cada verso? Nesse caso a resposta pode ser que aplicao deve obedecer um acordo de SLA ou que existem regras especificas para esse software de acordo com o negocio. Muitas outras perguntas podem ser criadas para complementar esse questionrio. Mas ele o bsico que precisamos saber para mapear os requisitos no funcionais e criar um software mais alinhado com a espectativa de qualidade esperada pelo cliente.
Java, Outros Add to del.icio.us Digg This Subscribe to RSS feed

18 Responses to Requisitos no funcionais

Mais informaes sobre este tpico podem ser encontradas em:

Conceitos: Gerenciamento de Requisitos Conceitos: Tipos de Requisitos Conceitos: Rastreabilidade .

Conceitos: Design Centrado no Usurio .

Artigo: Applying Requirements Management with Use Cases

Um requisito definido como "uma condio ou uma capacidade com a qual o sistema deve estar de acordo". Existem vrios tipos de requisitos. Um modo de categoriz-los descrito como o modelo FURPS+ [GRA92], usando o acrnimo FURPS para descrever as principais categorias de requisitos com subcategorias como mostrado abaixo.

Funcionalidade Usabilidade Confiabilidade Desempenho Suportabilidade

O "+" em FURPS+ para lembr-lo de incluir requisitos como:

restries de design requisitos de implementao requisitos de interface requisitos fsicos.

(Consulte tambm [IEEE Std 610.12.1990].) Os requisitos funcionais especificam aes que um sistema deve ser capaz de executar, sem levar em considerao restries fsicas. Geralmente, isso melhor descrito em um modelo de casos de uso e em casos de uso. Os requisitos funcionais especificam, portanto, o comportamento de entrada e sada de um sistema. Os requisitos que no so funcionais, como os listados abaixo, s vezes so chamados de requisitos no funcionais. Vrios requisitos no so funcionais e descrevem apenas atributos do sistema ou atributos do ambiente do sistema. Embora alguns deles possam ser capturados em casos de uso, aqueles que no puderem talvez estejam especificados em Especificaes Suplementares. Os requisitos no funcionais so aqueles que dizem respeito a questes como as descritas abaixo. Uma definio completa dos requisitos do software, dos casos de uso e das Especificaes Suplementares pode ser reunida para definir uma Especificao de Requisitos de Software (SRS) para uma "caracterstica" particular ou outros agrupamentos de subsistemas. Funcionalidade Os requisitos funcionais podem incluir:

conjuntos de recursos habilidades segurana

Usabilidade Os requisitos de usabilidade podem incluir subcategorias como:

fatores humanos (consulte Conceitos: Design Centrado no Usurio) esttica consistncia na interface do usurio (consulte Diretrizes: Interface do Usurio) ajuda on-line e contextual assistentes e agentes documentao do usurio materiais de treinamento

Confiabilidade Os requisitos de confiabilidade a serem considerados so:

freqncia e gravidade de falha possibilidade de recuperao possibilidade de previso exatido tempo mdio entre falhas (MTBF)

Desempenho Um requisito de desempenho impe condies aos requisitos funcionais. Por exemplo, para uma determinada ao, ele pode especificar parmetros de desempenho para:

velocidade eficincia disponibilidade exatido taxa de transferncia tempo de resposta tempo de recuperao uso de recurso

Suportabilidade Os requisitos de suporte podem incluir:

possibilidade de teste extensibilidade/li> adaptabilidade manutenibilidade compatibilidade possibilidade de configurao possibilidade de servio

possibilidade de instalao possibilidade de localizao (internacionalizao)

Requisito de Design Um requisito de design, freqentemente chamado de uma restrio de design, especifica ou restringe o design de um sistema. Requisito de Implementao Um requisito de implementao especifica ou restringe o cdigo ou a construo de um sistema. Como exemplos, podemos citar:

padres obrigatrios linguagens de implementao polticas de integridade de banco de dados limites de recursos ambientes operacionais

Requisito de Interface Um requisito de interface especifica:

um item externo com o qual o sistema deve interagir restries de formatos, tempos ou outros fatores usados por tal interao

Requisito Fsico Um requisito fsico especifica uma caracterstica fsica que um sistema deve possuir, por exemplo,

material forma tamanho peso

Esse tipo de requisito pode ser usado para representar requisitos de hardware, como as configuraes fsicas de rede obrigatrias.
A especificao de requisitos a tarefa mais importante na fase de anlise de um sistema. Requisitos mal especificados produzem dor de cabea, retrabalho e atrasos no projeto. Aqui vamos ver os principais conceitos relativos aos tipos de requisitos de um sistema. Os requisitos, de modo geral, pordem ser classificados em dois grandes grupos: os requisitos funcionais e os no funcionais.

O requisitos funcionais so aqueles que descrevem o comportamento do sistema, suas aes para cada entrada, ou seja, aquilo que descreve o que tem que ser feito pelo sistema. So o crebro do projeto, j que descrevem as funcionalidades que o sistema deve dispor. Os requisitos no funcionais so aqueles que expressam como deve ser feito (no confundir requisitos no funcionais com design). Em geral se relacionam com padres de qualidade como confiabilidade, performance, robustez, etc. So muito importantes, pois definem se o sistema ser eficiente para a tarefa que se prope a fazer ou no. Um sistema ineficiente certamente no ser usado. Neles tambm so apresentados restries e especificaes de uso para os requisitos funcionais. Alm desses dois, existem ainda os requisitos de interface, que como o nome j diz especifica as funcionalidades inerentes a interface do sistema com usurio. Muitas vezes difcil discernir entre quais requisitos so funcionais e quais no so. Essa ptica vem com o tempo e com a experincia e, por isso, para quem no trabalha diretamente com anlise, sempre bom exercitar. Vejamos o exemplo: Requisito: O sistema deve prover um grid na tela, que permitir a visualizao de imagens. Esse grid poder ser ativado ou desativado atravs do clique em um boto. O grid ter uma rgua, cuja escala poder estar tanto em centmetros como em polegadas, que ajudar no redimensionamento das imagens. Os requisitos no foram especificados da maneira correta no exemplo acima. o que chamamos de aglutinao de requisitos. Temos ento que seprarar requisitos funcionais, no funcionais e de interface. No nosso caso, o maneira correta seria: Funcional: O sistema deve prover um grid para a visualizao de imagens. Este grid poderia ser ativado ou desativado. No funcional: A escala do grid poder estar tanto em centmetros com em polegadas. Interface: Deve haver um boto responsvel por habilitar e desabilitar o grid.

O processo de anlise uma das fases mais complexas do projeto de software. Vamos ainda continuar falando sobre o processo de elicitao de requisitos e de anlise em geral em prximas ocasies. At a prxima! Postado por Bruno Nunes s 5/22/2007 09:45:00 PM Categorias: engenharia de software