P. 1
Requisitos Não Funcionais

Requisitos Não Funcionais

5.0

|Views: 36.884|Likes:
Publicado porpccresende
aula de engenharia de software
aula de engenharia de software

More info:

Published by: pccresende on Mar 04, 2008
Direitos Autorais:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less

06/13/2013

pdf

text

original

Requisitos não funcionais

A complexidade de um software é determinada em parte por sua funcionalidade (requisitos funcionais), ou seja, o que o sistema faz, e em parte por requisitos gerais (requisitos não funcionais) que fazem parte do desenvolvimento do software como custo, performance, confiabilidade, manutenibilidade, portabilidade, custos operacionais entre outros

Requisitos Funcionais X Não Funcionais
Os requisitos funcionais são requisitos que expressam funções ou serviços que um software deve ou pode ser capaz de executar ou fornecer. As funções ou serviços são, em geral, processos que utilizam entradas para produzir saídas. Os requisitos não funcionais são requisitos que declaram restrições, ou atributos de qualidade para um software e/ou para o processo de desenvolvimento deste sistema. Segurança, precisão, usabilidade, performance e manutenabilidade são exemplos de requisitos não funcionais.

Requisitos não funcionais
São conhecidos como atributos de qualidade, restrições, objetivos entre outros; Não possuem mapeamento direto nas funcionalidades; Não são fáceis de detectar; Devem ser observados cuidadosamente ao longo do desenvolvimento; Se relacionam diretamente com o produto, suas funções e/ou com o ambiente onde será implantado; Desempenham um papel crítico durante o desenvolvimento de sistemas e erros devido a não elicitação ou a elicitação incorreta destes estão entre os mais caros e difíceis de corrigir, uma vez que um sistema tenha sido implementado

Requisitos não funcionais
A distinção entre o que é um requisito funcional e o que é um não funcional nem sempre é clara. Parte da razão advém para o fato de que estão sempre relacionados a um requisito funcional; Partindo da definição acima pode-se dizer que um requisito funcional expressa algum tipo de transformação que tem lugar no software, enquanto um não funcional expressa como essa transformação irá se comportar ou que qualidades específicas ela deverá possuir.

Um Exemplo
Suponhamos que estejamos no domínio de uma clinica médica: um requisito funcional do sistema sistema seria: “O sistema deve fornecer uma entrada de dados que possibilite a designação de resultados a exames admitidos para um paciente por técnicos, supervisores e chefes”. Este mesmo requisito funcional poderá ter associado a ele o seguinte não funcional: “Alguns exames deverão ter tratamento especial para a entrada de resultados. Para estes exames, valores acima ou abaixo de uma lista pré-determinada, só poderão ser digitados por chefes de seção!”.

Detalhando o Exemplo
O requisito não funcional apresentado não exprime uma função do sistema, e sim, uma restrição a uma função que deverá existir: Entrar com os Resultados de Exames; O que se vê é que essa funcionalidade do sistema deverá ser restrita de forma que, quando utilizada por pessoas que não sejam chefes, deverá restringir os valores a uma lista pré-definida; Esse requisito não funcional diz respeito a segurança da aplicação, já que não permite que pessoas não autorizadas insiram valores críticos no sistema.  É importante entender que este requisito demandará um trabalho bem mais complexo daquele que seria implantado se apenas o funcional tivesse sido especificado e que é vital para manter a integridade e segurança da informação que o sistema irá armazenar.

Classificação de Requisitos Não Funcionais

Proposta do Mamani

Classificação de Requisitos Não Funcionais

Proposta do Sommerville

Usabilidade
Requisitos associados à facilidade de uso da aplicação; Definem o nível de dificuldade que o usuário terá para executar as operações; Estão relacionados com a interação do usuário junto ao sistema Normalmente associados a interface, mas podem estar associado a outros elementos como: interação com o teclado, tempo de treinamento, nível de conhecimento necessário para interação entre outros; Ex1.: Em um software infantil, é necessário que haja um investimento grande em cores e objetos grandes para facilitar a interação das crianças. Ex2.: O usuário Zé das Coves, digita uma grande massa de dados por mês e precisa que todas as operações CRUD, na janela de digitação, sejam acessadas diretamente pelo teclado para que ele não perca tempo indo ao mouse.

Confiabilidade
Associados à freqüência e severidade de falhas da aplicação e habilidade de recuperação das mesmas São requisitos não funcionais de confiabilidade: Tempo médio de falhas; Probabilidade de indisponibilidade; Taxa de ocorrência de falhas; Tempo de reinício após falha; Percentual de eventos causando falhas; Probabilidade de corrupção de dados após falha.

Desempenho
Associados à eficiência, uso de recursos e tempo de resposta da aplicação (Transações processadas/seg, Tempo de resposta do usuário/evento entre outros) Ex1.: Uma consulta aos dados do empregado não pode demorar mais de 10 milésimos; Ex2.: Ao registrar um item sendo vendido, a descrição e preço devem aparecer em 1 segundo; Ex3.: A operação de cálculo de salário de empregados, não deve exceder 20 segundos por empregado;

Segurança
Associados à integridade, privacidade e autenticidade dos dados da aplicação; Ex1.: A base de dados deve ser protegida para acesso apenas de usuários autorizados; Ex2.: Somente chefes de setor podem efetuar os pagamentos de fornecedores; Ex3.: Um log de todas as operações dos usuários; Ex4.: Todas as operações do sistema que envolverem aprovação de despesas, devem ser autorizadas através de re-autenticação com usuário e senha e devem respeitar os limites de competência.

Implantação
Associados ao modo como será implantada a solução Ordem de instalação dos Pacotes Configurações iniciais necessárias Ex1.: O sistema “contador de carneirinhos” precisa que o servidor, responsável pelo gerenciamento da contagem, seja previamente instalado na máquina servidora e os clientes, responsáveis por contar os carneirinhos, instalados nas máquinas dos usuários e configurados, conforme a tabela de configuração n.

Padrões
Associados a padrões ou normas que devem ser seguidos pela aplicação ou pelo seu processo de desenvolvimento Ex1.: O sistema deve atender ao padrão de desenvolvimento da empresa, respeitando locais e nomes para variáveis, funções, parâmetros e utilizar os objetos e funções comuns descritas na mesma Ex2.: O sistema deverá permitir a compra de materiais, atendendo as necessidades descritas pelos usuários, sem desrespeitar a lei 8.666.

Hardware e Software
Associados a restrições de hardware e software usados para desenvolver ou executar a aplicação; Ex1.: O sistema precisará ser executado nas plataformas operacionais: Microsoft Windows 95, Windows, 98, Windows NT, Windows 2000 e XP Ex1.: O sistema precisará de uma máquina, com no mínimo 512Mb de RAM, com o processador de 2.8Mghz ou superior

Conclusão
Uma especificação de requisitos só estará completa se houver tanta preocupação com os requisitos funcionais quanto com os requisitos não funcionais Deve ser feito uma tabela relacionando os requisitos não funcionais, com suas origens funcionais, já que todos os requisitos não funcionais, existem para atender, por completo, um requisito funcional Não existe receita de bolo, para se definir os requisitos não funcionais, é necessário partir dos funcionais levantados e detalhá-los em busca de regras de implementações

Pontos chaves sobre requisitos
. O processo de engenharia de requisitos incluem estudo de viabilidade,o levantamento e a análise de requisitos, a especificação de requisitos, a validação de requisitos e o gerenciamento de requisitos. . A análise de requisitos é um processo iterativo,que envolve a compreensão do domínio, assim como a coleta, a classificação, a estruturação, a priorização e a validação dos requisitos. . Diferentes stakeholders do sistema têm diferentes requisitos. Todos os sistemas complexos devem, portanto, ser analisados a partir de uma série de diferentes pontos de vista. Os pontos de vista podem ser fontes ou 'drenas' de dados; diferentes representações ou entidades do sistema estão fora do sistema e recebem serviços a partir dele.

Pontos chaves sobre requisitos

. Os fatores sociais e organizacionais têm forte influência sobre os requisitos do sistema e podem determinar se o software será realmente utilizado ou não. . A validação dos requisitos é o processo de verificar os requisitos quanto a sua validade, consistência, completeza, seu realismo e sua facilidade de verificação. As revisões de requisitos e a prototipação são as principais técnicas utilizadas para a validação de requisitos. . As modificações organizacionais, técnicas e de negócios inevitavelmente levam a mudanças nos requisitos, em um sistema de software. O gerenciamento de requisitos é o processo de gerenciar e controlar essas mudanças. . O processo de gerenciamento de requisitos inclui o planejamento do gerenciamento, em que são especificados os procedimentos e as políticas para o gerenciamento de requisitos, e o gerenciamento de mudanças, em que as mudanças são analisadas e seu impacto é avaliado. 1

Exercício I
1) Um sistema de software deve ser desenvolvido para automatizar um catálogo de biblioteca. Esse sistema conterá informações sobre todos os livros da biblioteca e será utilizado por seus funcionários, leitores e pessoal que empresta livros da biblioteca. O sistema deverá permitir 'navegar' no catálogo e fazer consultas, além de fornecer recursos que possibilitem aos usuários enviar mensagens ao pessoal da biblioteca, solicitando a reserva de livros que estão emprestados. Identifique os principais pontos de vista que devem ser levados em consideração na especificação desse sistema. 2) Para três dos pontos de vista identificados no sistema de catálogo da biblioteca, sugira os serviços que podem ser fornecidos para cada ponto de vista, os dados que o ponto de vista pode fornecer e os eventos que controlam o fornecimento desses serviços. 3) Para os serviços identificados no Exercício 1-2, especifique quais poderiam ser as restrições não funcionais mais importantes.

Exercício II
1) Quando mudanças de emergência têm de ser feitas em sistemas, o software de sistema pode precisar ser modificado, antes que as mudanças nos requisitos tenham sido aprovadas. Sugira um modelo de um processo para fazer essas modificações, que assegure que o documento de requisitos e a implementação do sistema não se tornem inconsistentes.

You're Reading a Free Preview

Descarregar
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->