Requisitos Funcionais e não Funcionais

5.1.2 REQUISITOS NÃO FUNCIONAIS
? Os relatórios devem ter a opção de visualização em PDF, HTML e XLS.
? O software deve ser multiplataforma.
? Os alertas podem ser enviados via e-mail, SMS, ou ambos
? O banco de dados do estoque deve ser atualizado em tempo real
? Os Relatórios devem ter níveis de acesso.
? Os Relatórios de Custo e Receita devem pedir login do usuário.

Destes os únicos requisitos não funcionais são:
Os Relatórios devem ter níveis de acesso.
O software deve ser multiplataforma.

Repare que se você dizesse:

Os relatórios terão opções de vizualização:

Ae sim seria não funcional, pois você está exprimindo uma restrição e não uma funcionlidade se disser como acima:

repare

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: O Sistema terá opções de visualização.

veja:

http://pt.scribd.com/pccresende/d/2210932-Requisitos-Nao-Funcionais

Espero ter ajudado.

Valeu pela resposta amigo… é que essa parte confunde bastante… Li muito que os requisitos funcionais, quase sempre cabem em uma diagrama de caso de uso…

Como voce disse…
isso seria um não funcional
Os relatórios terão opções de vizualização

como eu colocaria isso em um caso de uso? fica estranho né?

valeu parceiro

Você ja sabe quais são as opções de visualização?
por exemplo pdf, xls…

Se souber não são requisitos não funcionais!

E quanto a dúvida de como isso vai estar no caso de uso, isso deve estar em uma sessão chamada "Requisitos Não Funcionais"
Veja bem você geralmente faz uma descrição textual do caso de uso certo? A mesma deve ter fluxo básico, fluxo alternativo, e uma tabela com eventuais espeficiações de tipos de campos etc…, lógico que este documento varia de caso a caso, onde eu trabalhava tinhamos diagramas de sequência, e diagramas de classe, o resto das coisas eram determinadas nesta descrição textual do caso de Uso, na pós graduação de java, que estou fazendo, ficou bem claro, que o documento tem que ser inteligível entende, por exemplo você tem os diagramas com os atores e os casos de uso certo, e depois vai “explodir” cada UC em fluxo básico, fluxo alternativo, exceptions, e tudo mais, ae você tem uma sessão Requisitos não funcionais, que está diretamente aliada ao UC, certo? la você coloca os requisitos.

Agora, se você acha que la no diagrama de sequência, algum requisito funcional é importante, coloque um “note”, tudo depende do que você quer transmitir entende?
Você é o analista, e tem que ter em mente que está fazendo um documento de analasys ou design, que tem que transmitir a exência do objeto de estudo, neste caso a especificação no plano das idéias do que vai ser o sistema no plano da realidade.
Espero ter de alguma forma ajudado.

ribclauport:

5.1.2 REQUISITOS NÃO FUNCIONAIS
? Os relatórios devem ter a opção de visualização em PDF, HTML e XLS.
? O software deve ser multiplataforma.
? Os alertas podem ser enviados via e-mail, SMS, ou ambos
? O banco de dados do estoque deve ser atualizado em tempo real
? Os Relatórios devem ter níveis de acesso.
? Os Relatórios de Custo e Receita devem pedir login do usuário.

Destes os únicos requisitos não funcionais são:
Os Relatórios devem ter níveis de acesso.
O software deve ser multiplataforma.

Não. O primeiro ainda é um requisito funcional. O segundo é não-funcional.

Outros exemplos de requisitos não-funcionais:

a) A solução deve ter escabilidade para atender 10000 usuários (escalabidade)
b) Cada transação deve ser processada em 5s (performance)
c) Devem existir servidores redundantes para banco de dados (confiabilidade)

Os níveis não estão definidos, sendo assim a funcionalidade não está presente na proposição:

Configura-se desta forma um requisito não funcional, sendo ele político-operacional.

Se a proposição acima estivesse sido configurada como:

Os relatórios terão tres níveis de acesso:
1)diretoria
2)gerência
…

desta forma sim estaria especificando um requisito funcional

Devemos lembrar que um requisito funcional muitas vezes está associado a um requisito não funcional, é o caso acima, pois existe uma “restrição” contida na proposição, não conseguimos “retirar” a informação de “como” esses acessos vão “funcionar”.

Fica claro que se trata de um requisito não funcional politico-operacional

sem mais.

IMHO, controle de acesso é requisito funcional pq deve ser implementado através de telas, campos e códigos. Não importa se está proposto ou não, trata-se de uma funcionalidade que deve ser agregada ao projeto, então é requisito funcional. Quando vc quer um sistema escalável, confiável, seguro, etc não está mais falando de funcionalidade e sim de atributos, daí serem requisitos NÃO-FUNCIONAIS.

Se vc acha diferente, belez…

Onde eu trabalhava, tinha um pessoal que prestava consultoria, e nos seguiamos um documento normatizado pela empresa, tal documento citava:

As principais restrições são:
Confiabilidade, desempenho, usabilidade e segurança (safety e security)

Não tenhos os documentos comigo, porém durante o curso de bacharelado em Sistemas de Informação e recentemente na pós-graduação em tecnologia java, houve bastante discussão a respeito dos requisistos não funcionais, retirei de um documento elaborado por Cézar/quality/processors da unpe o seguinte, o qual foi citado pelo professor na ocasião o trecho:

4 Requisitos não funcionais
4.1 Usabilidade
Esta seção descreve os requisitos não funcionais associados à facilidade de uso da interface com o usuário, documentação de suporte ao uso e documentação do sistema.
[NF001] <Interface simplificada>
O sistema será apresentado com uma interface simples, para facilitar ao máximo o uso do mesmo. A navegação deverá ser intuitiva e, sempre que possível, fornecer ao usuário as opções possíveis, evitando desta forma escolhas que possam apresentar conflitos.
Prioridade: Importante
[NF002] <Agrupamento lógico de relatórios>
Como já foi apresentado, os relatórios e gráficos foram divididos em grupos lógicos de forma a facilitar a navegabilidade do sistema como o entendimento geral do mesmo.
Prioridade: Importante
Caso(s) de uso associado(s): Todos os Casos de Uso descritos na sessão de requisitos funcionais.
[NF003] <Documentação de Suporte para Usuário>
Por ser um extrator de relatórios, o Sistema de Métricas não requer um manual de usuário. Porém é interessante a elaboração de um documento que explique os relatórios e seus objetivos, auxiliando os usuários sempre que necessário obter tais dados. Inicialmente o Sistema de Métricas será apresentado com poucos relatórios, o que talvez não justifique tal documentação. Contudo, em versões futuras o número de relatórios e gráficos tenderá a crescer, tornando a documentação necessária.
Prioridade: Desejável
[NF004] <Manutenção da Documentação Atualizada>
Como em todo desenvolvimento de software de qualidade, é imprescindível que a documentação seja periodicamente atualizada, no surgimento de mudanças. O que facilita o desenvolvimento e manutenção do software, garantindo o entendimento do mesmo por qualquer desenvolvedor que venha a fazer parte da equipe.
Prioridade: Importante
4.2 Confiabilidade
Esta seção descreve os requisitos não funcionais associados à corretude do sistema.
[NF005] <Corretude>
Os dados reportados através dos relatórios e gráficos gerados pelo Sistema de Métricas, deverão ter total veracidade em suas informações.
Prioridade: Essencial
Caso(s) de uso associado(s): Todos os Casos de Uso descritos na sessão de requisitos funcionais.
4.3 Desempenho
Esta seção descreve os requisitos não funcionais associados à eficiência, uso de recursos e tempo de resposta do sistema.
[NF006] <Comunicação com Sistemas Externos>
Devido a comunicação direta que o Sistema de Métricas irá ter com outros softwares, como o MSProject e o TimeSheet, será importante que durante o desenvolvimento exista uma preocupação para conseguir a melhor interface com esses sistemas, pois problemas nesta característica poderá comprometer a performance do sistema.
Prioridade: Importante
Caso(s) de uso associado(s): Todos os Casos de Uso descritos na sessão de requisitos funcionais. Pois todos os relatórios possui seus dados buscados de outros sistemas.
[NF007] <Acesso a Base de Dados>
Deverá ser estudado a melhor implementação de acesso a base de dados, de forma que isto não se torne um gargalo no Sistema de Métricas. Como o sistema é basicamente um extrator de relatórios através de dados buscados em outros sistemas, o acesso a base de dados será muito intenso, sendo importante dispensar grande atenção a comunicação com o banco de dados.
Prioridade: Importante
Caso(s) de uso associado(s): Todos os Casos de Uso descritos na sessão de requisitos funcionais. Todos os relatórios e gráficos irão acessar a base de dados.
4.4 Segurança
Esta seção descreve os requisitos não funcionais associados à integridade, privacidade e autenticidade dos dados do sistema.
[NF008] <Acesso ao Sistema>
O acesso ao sistema será controlado por meio de login/senha e níveis de acesso de acordo com as permissões que os diferentes usuários possuem dentro do sistema.
Prioridade: Essencial
Caso(s) de uso associado(s): Todos os Casos de Uso descritos na sessão de requisitos funcionais. Pois todos os relatórios só serão acessados de acordo com as permissões dos usuários.
4.5 Padrões
Esta seção descreve os requisitos não funcionais associados a padrões ou normas que devem ser seguidos pelo sistema ou pelo seu processo de desenvolvimento.
[NF009] <Padrões e Normas>
O CESAR com o objetivo da implantação de qualidade, está desenvolvendo uma série de padrões e normas a serem seguidos no processo de desenvolvimento de software. Uma metodologia única de desenvolvimento de software está sendo implantada na empresa, e esta deverá ser seguida no decorrer do desenvolvimento do Sistema de Métricas. Além da metodologia existem as ferramentas padrões que deverão ser usadas, padrões de codificação a serem seguidos, entre outras características de qualidade ainda em análise.
Prioridade: Importante
4.6 Hardware e software
Os requisitos de software necessários para o desenvolvimento do projeto serão:
[NF010] <Ambiente de desenvolvimento Java>
Como o sistema será desenvolvido em Java, que é a linguagem de programação padrão adotada pelo CESAR, serão necessárias três licenças do Ambiente de. desenvolvimento JAVA: Jbuilder ou Jdeveloper.
Prioridade: Essencial

Veja, que não é questão de achar ou não achar, maiis devemos então buscar, uma referência de peso, para anular a questão de requisitos de segurança não serem funcionais, desta forma invalidamos o texto acima e todas afirmações que foram ditas por mim nesse post.

Abraço.

Não entendi se vc concorda, discorda, não sabe, mas enfim… :roll:

Acredito que você não deve ter feito o menor esforço para entender, e quando não queremos entender realmente não entendemos, os requisitos de segurança são não funcionais, e toda argumentação foi feita em função de sua afirmação:

Argumentei, e deixei a verdade na condigação de julgado, pois em minha concepção nenhuma verdade é “universal”, mas se o amigo prefere debochar, eu prefiro discutir as coisas.

O fato é que minha afirmação tem fundamento, “eu não acho”, eu penso com base nos argumentos descritos.

Atenciosamente.

Olha, eu me esforcei para entender o que escreveu, mas tah difícil. Evite trocar “MAS” por “MAIS” pq isso muda completamente o sentido da frase.

Se vc quer fundamentação sólida para suas idéias, procure em livros de Engenharia de Software de autores como Presmman e Somerville. Agora se vc ACHA que um cursinho de pós-graduação está o suficiente, mais uma vez, trata-se da sua opinião…

E pra ser sincero, essa baboseira de requisito funcional / não funcional é coisa de empresas que gostam de encher linguiça com documentação. Prefiro muito mais uma abordagem ágil em projetos, ou seja, mostrar software funcionando para o stakeholder. Isso é o que funciona na prática.

PS: Tb sou pós-graduado em Qualidade de Software. Acredite, aprendi 200X mais em situações de projeto do que em cursos sobre como desenvolver e entregar software com qualidade.

.

"cursinho", ehhehehe

Bom, eu estou gostando bastante, estou achando um "cursão", quanto aos livros citados … presm…, foram usados durante o curso de bacharelado, e veja bem, no "cursinho", tenho a oportunidade de ouvir doutores, mestres, pessoas com 20 anos de experiência, desta forma, o "cursinho", impede que eu tenha que me ferrar, para aprender na prática como você.

Inclusive foi no "cursinho", que aprendi que a metodologia "ágil" funciona para projetos que tem requisitos que mudam o tempo todo… sendo assim não é a bala de prata.
E ja trabalhei de forma ágil em projetos.

"Mais, então" e "Mas, então"
–> lógico que foi um erro, mas neste caso específico não mudou o sentido da frase…
Velho, não tem como confundir neste caso, com advérbio de instensidade, foi empregado como conjunção, não se aproveite de alguma situação para retirar credibilidade das pessoas!

Para terminar, ja que é "baboseira", vamos dizer para o amigo do post, retire a "sessão", ops "seção" ou "cessão" , espera… tem que prestar atenção nas palavras pois se não vou mudar o sentido da frase… :roll: :roll:

Fui…