O que é Requisito Funcional

Compartilhe!

O que é um Requisito Funcional? Vamos primeiro ao que é Requisito. Requisito é uma exigência, solicitação, desejo, necessidade.

Quando falamos de um Requisito Funcional estamos nos referindo à requisição de uma função que um software deverá atender/realizar. Ou seja, exigência, solicitação, desejo, necessidade, que um software deverá materializar.

Um Requisito Funcional é um Requisito de Software.

O que é Requisito Funcional - Relacionamento entre Requisitos

É comum os profissionais de engenharia de software associarem a ideia de um requisito funcional a uma tela, uma rotina, que no fim serão as funcionalidades de fato de um sistema.

Mas é necessário entender que uma funcionalidade não necessariamente realizará apenas um Requisito Funcional. 

Uma funcionalidade pode realizar vários Requisitos Funcionais – significa que em uma funcionalidade um ou mais Requisitos Funcionais podem ser atendidos, não necessariamente apenas um. Se pensarmos em multiplicidade, uma funcionalidade pode realizar um ou muitos Requisitos Funcionais (1.. *).

O que é Requisito Funcional - Relacionamento com Funcionalidade

Para entender melhor isso vamos a um exemplo mais básico. Imaginemos um sistema que possui uma tela para “Manutenção de Clientes”, que mantém os dados cadastrais de um cliente no sistema.

Estamos falando de uma única funcionalidade. Nesta tela é possível incluir/alterar/consultar/excluir clientes dos tipos pessoa física e pessoa jurídica.

Mas quantos requisitos são realizados (atendidos) por esta funcionalidade? Oito requisitos.

Vejamos a lista a seguir:

Requisitos Funcionais (Identificador e Nome)
RF001 – Incluir cliente pessoa física
RF002 – Alterar cliente pessoa física
RF003 – Consultar cliente pessoa física
RF004 – Excluir cliente pessoa física
RF005 – Incluir cliente pessoa jurídica
RF006 – Alterar cliente pessoa jurídica
RF007 – Consultar cliente pessoa jurídica
RF008 – Excluir cliente pessoa jurídica

O que é um Requisito Funcional, agora sabemos. E o que não é?

O que não é um Requisito Funcional?

 É comum quando se fala de Requisito Funcional associar a isto funcionalidade, caso de uso, regra de negócio ou até mesmo requisito não funcional. São coisas muito diferentes.

 Uma funcionalidade pode realizar um ou mais Requisitos Funcionais. Requisito funcional não é uma funcionalidade, é uma necessidade funcional (uma função) que o software deve atender. Uma funcionalidade será executada por um ator (um ator sistêmico [pelo próprio sistema] ou um ator humano [usuário final]). É onde Requisitos Funcionais serão viabilizados.

 Um Caso de Uso é uma especificação do comportamento de uma funcionalidade. Nele se tem detalhes sobre como a funcionalidade “funcionará”, com restrições, premissas e diretrizes pertinentes à funcionalidade.

 Regra de negócio refere-se a premissas ou restrições de negócio que o sistema deverá atender, regras que poderão ou não estar associadas a um requisito funcional, mas que sempre serão realizadas por uma ou mais funcionalidades do sistema. Na visão da modelagem conceitual, Regras de negócio são o “como”, requisitos funcionais são o “o que”.

Requisitos Não Funcionais são premissas ou restrições que o sistema deverá atender, mas que não são realizados através de funcionalidades. Podem ou não estar associados a Requisitos Funcionais, mas não tem, necessariamente, relação com o negócio, na visão do usuário.

Importância dos Requisitos Funcionais

Funcionalidades somente existem para realizar Requisitos Funcionais. Logo, sem requisitos funcionais não há funcionalidades e sem funcionalidades não há sistema.

Este raciocínio por si só demonstra a importância absoluta e inquestionável dos requisitos funcionais no escopo de um sistema.

E por ser algo importante como é, todo cuidado é pouco para que estes requisitos possuam a maior qualidade possível, pois apenas a existência deles no escopo não garante um bom sistema, eles precisam ter qualidade em termos de sintaxe e semântica.

Precisam ser bem feitos. Mas o que devemos entender como qualidade de um requisito?

Atributos de um bom Requisito Funcional

Um Requisito Funcional de qualidade precisa atender alguns atributos específicos.

Na literatura, principalmente estrangeira, existem várias recomendações de atributos que um requisito deve atender para ter qualidade. Mas vou me ater apenas aos que realmente considero relevantes na prática, que fazem diferença no dia a dia.

A seguir a lista dos atributos que considero relevantes.

Atributo Referente a
Unidade O RF deve propor uma única coisa apenas. Não deve atender a mais de uma exigência. O RF “Incluir cliente” não é unitário, pois se refere a incluir clientes de tipos diferentes (pessoa física e jurídica), assumindo assim várias responsabilidades, quando deveria assumir apenas uma.
Completude O RF deve ser autocontido, deve ter “início/meio/fim”, ser completo. O RF “Pagar fatura” não é completo, só conta “parte da estória”. Para ser completo deveria ser algo como “Pagar fatura com cartão de crédito para cliente pessoa física”.
Consistência O RF não deve contradizer outro RF do mesmo escopo do projeto. É como termos dois RFs se propondo a fazer uma mesma coisa, mas cada RF se propondo a fazer esta coisa de uma forma diferente.
Atomicidade Um RF para ser atômico precisa também ter unidade, pois atomicidade remete a assumir apenas uma responsabilidade. Mas também deve ser algo indivisível, não podendo ser decomposto. Muitos RFs possuem conjunção, dependem de outros para se realizarem. Onde temos dois RFs “Realizar compra de produto” e “Realizar pagamento com cartão de crédito” na realidade, se pensarmos em atomicidade, temos um único RF que é “Realizar compra de produto com pagamento em cartão de crédito”.
Não-Ambiguidade Um RF não pode ser ambíguo, não pode propor algo que não fica claro o que é. O RF “Emitir relatório” não quer dizer nada. Relatório de que, para que? “Emitir relatório de saldo” já é melhor, mas ainda é ruim. Saldo de que? Seria não ambíguo se não deixasse dúvidas, algo como “Emitir relatório de saldo da conta corrente do cliente pessoa física”.
Verificável Não adianta ter um RF se ele não é palpável, possível de associar com um artefato de construção, de testes. Um RF tem que ser testável, tem que ser possível atestar que o RF foi atendido, foi construído, foi homologado. Para isso tem que ser também rastreável.
Rastreável Deve ser possível achar o RF no sistema pronto, funcional e executável. Como saber se um RF foi atendido? Para isso é necessário ter rastreabilidade, e isso só é possível ligando as pontas (associar o RF à interface gráfica, que será associada a um caso de uso, que será associado a funcionalidades, que serão implementadas etc.).
Prioridade Um RF Essencial é algo muito diferente de um RF Desejável, possuem valores para o negócio completamente diferentes. O RF deve possuir sua prioridade, isso interfere diretamente no projeto do software.

Um detalhe fundamental é o uso do tempo verbal no nome do RF. Um RF, em tempo de especificação, refere-se a algo que será feito, uma ação a ser realizada pelo sistema. Por isso o nome precisa estar no tempo verbal infinitivo. Um RF que fala sobre “expurgo de registros de clientes inativos” não pode ter este nome, deve se chamar “Expurgar registros de clientes inativos”.

É uma necessidade, mas que precisa ser verbalizada como uma ação a ser realizada.

Estrutura de um Requisito Funcional

Não há um padrão estabelecido sobre a estrutura de um RF.

Mas a maioria das empresas utiliza um formato semelhante, contendo campos específicos. O modelo a seguir contempla os campos mais relevantes, com posterior descrição de cada um.

O modelo citado é aplicável em especificações produzidas em Editores de Texto como o Microsoft Word, por exemplo.

É recomendado que se utilize, sempre que possível, alguma ferramenta Case que dê suporte a Engenharia de Requisitos, para melhorar a produtividade na modelagem e a gestão dos requisitos.

Identificador
Nome
Módulo
Data de criação Autor
Data da última alteração Autor
Versão Prioridade
Descrição

Explicando cada campo

Campo Descrição
Identificador Sufixo seguido de um identificador único. O sufixo geralmente utilizado é RF (Requisito Funcional) e o identificador único geralmente é composto de quatro dígitos.

Nome
Nome curto do RF, mas que possibilite entender bem o que RF faz apenas pelo nome.
Módulo Módulo ao qual o RF pertence. Se for um sistema pequeno que não possua nenhum módulo, somente o próprio sistema, deve ser preenchido com N/A (não se aplica).
Data de criação Data da criação do RF, ou a data em que ele foi especificado.
Autor Profissional que especificou o RF pela primeira vez, quem o criou.
Data da última alteração Data em que houve a última alteração no RF.
Autor Profissional que alterou a especificação do RF pela última vez.
Versão Número da versão do RF. Geralmente utiliza-se algo simples, como 1, 2. A versão inicial sempre é a 1, e a cada alteração incrementa-se a versão (na criação versão 1, na primeira alteração versão 2 e por aí vai).
Prioridade Se o RF é Essencial, Importante ou Desejável.
Descrição Descrição detalhada (a mais detalhada possível) do RF.

/* O uso de identificador é fundamental para uma melhor organização do projeto. Localizar requisitos pelo nome não funciona, devido ao volume dos requisitos e ambiguidades nos nomes. E também, é importante ter algum recurso de numeração automática, pois controlar os números dos identificadores manualmente é inviável. */

Exemplo de um Requisito Funcional especificado

Identificador RF0003
Nome Emitir carta de cobrança para clientes inadimplentes conforme critérios pré-estabelecidos
Módulo Cobrança
Data de criação 31/01/2016 Autor Hípias de Elis
Data da última alteração N/A Autor N/A
Versão 1 Prioridade Essencial
Descrição Para todo cliente que esteja inadimplente deverá ser possível a emissão de carta de cobrança através do sistema. O resultado da emissão será a carta impressa, que será posteriormente despachada por correios ou outro agente de entrega.

Os critérios para definir se um cliente é ou não inadimplente devem estar cadastrados no sistema utilizando regras de negócio específicas. Nem todo cliente com pagamento em atraso será considerado inadimplente, pois deverá ser levado em consideração o score de crédito do cliente, sua renda mensal, patrimônio etc. Obs.: verificar os Requisitos Funcionais e regras de negócio específicas para manutenção dos critérios citados.

Não haverá diferença na emissão da carta de cobrança para clientes pessoa física (particular) ou jurídica (empresarial), logo, o processo será o mesmo para ambos.

Obrigado pela leitura, espero que possa ter sido útil.

Se você quiser tornar-se um Expert em Engenharia de Requisitos e sair na frente no mercado, conheça nosso curso on-line super diferenciado!

Curso Engenharia de Requisitos- 50% de Desconto

Se você gostou do conteúdo deste post, deixe seus comentários, para ajudar outras pessoas a encontrarem este material! 🙂

Grande abraço!

Requisito Funcional

  • Pingback: Requisitos de Software | Até o Momento – Muito conteúdo de qualidade sobre Engenharia de Software()

  • Armando Mancilla

    Excelente artigo!

    • Plínio Ventura

      Obrigado Armando! Esperamos que o conteúdo possa ter sido útil a você.

      Abraço!

  • Pingback: Funcionalidades do Sistema - Até o Momento()

  • Pingback: Relacionamento entre Classes - Composição - Até o Momento()

  • Wesley Oliveira

    Muito bom! Deu pra entender mais aqui do que nas aulas da faculdade propriamente ditas

    • Plínio Ventura

      Oi Wesley!

      Que bom que o conteúdo foi útil para você, é exatamente este o meu propósito com os posts do blog.

      Caso queira aprender mais sobre Engenharia de Requisitos, vou lançar em duas semanas um curso on-line muito bacana sobre o assunto, muito diferenciado. Você pode colocar seu nome na lista de pré-lançamento, e ser avisado quando o curso for lançado: http://www.indtech.com.br/lpCursoEngenhariaRequisitosListaPreLancamento.aspx.

      E neste primeiro lançamento, teremos vários benefícios aos primeiros alunos, inclusive, 50% de desconto na matrícula.

      Grande abraço!

  • Pingback: Diferença de Requisito Funcional e Regra de Negócio - Até o Momento()

  • Alexandre Viana

    Bom dia Plínio,
    Gosto muito dos seus post e aprendo muito a cada dia, mais quero saber de uma coisa existe um documento padrão para escrever um documento de caso de uso?

    • Plínio Ventura

      Oi Alexandre, bom dia!

      Obrigado, que bom o conteúdo é útil a você. Está se referindo a algum documento para se descrever os cenários de um Caso de Uso? Ou está se referindo aos diagramas de Caso de Uso?

      Abraço!

      • Alexandre Viana

        Descrever os cenários de um caso de Uso

        • Plínio Ventura

          Alexandre,

          Se você utilizar alguma ferramenta Case, no corpo do Caso de Uso (o elemento elipse ou “bolinha” que identifica o Caso de Uso) você possui a estrutura para tal especificação.

          Se você utilizar editores de texto para tal, com o Microsoft Word, por exemplo, não existe um template padrão seguindo a literatura. O motivo disso é que a UML define padrões apenas para o diagrama de Caso de Uso, e não para o seu conteúdo/cenários.

          Neste link – https://www.google.com.br/?ion=1&espv=2#q=documento%20de%20caso%20de%20uso – você pode navegar por alguns exemplos de documentos pertinentes.

          Mas é essencial que, independente do template, você tenha “espaço” para descrever: o fluxo principal, cada um dos fluxos alternativos, cada um dos fluxos de exceção (os cenários), requisitos funcionais, não funcionais e regras de negócio citados (referências), área para descrição do objetivo do caso de uso (para explicar o propósito dele) e descrição dos atores que usarão o caso de uso.

          Qualquer dúvida adicional estou à disposição!

  • Ricardo Krauze Cavalcanti

    Muito bom! Gostei da forma que foi explicado!

    • Plínio Ventura

      Oi Ricardo, que bom o conteúdo lhe foi útil.

      Qualquer dúvida estamos aí. Abraço!

  • Lourenci

    Ótimo artigo.

    Uma dúvida que fiquei: no caso de dependência e/ou interações entre RFs, isso deve ser especificado?

    Exemplo:

    RF01: Cadastrar marca de carro.
    Descrição: O administrador irá cadastrar a marca do carro.

    RF02: Cadastrar modelo de carro.
    Descrição: O administrador irá preencher o cadastro do modelo do carro e selecionar a marca do carro. A marca para seleção está disponível após cadastro do RF01.

    É correto especificar o requisito dessa forma?

    Obrigado e parabéns pelo blog.

    • Plínio Ventura

      Oi Lourenci, como vai? Obrigado, que bom que o conteúdo foi útil para você.

      Dois pontos:

      – Atomicidade dos Requisitos: o RF01 não está atômico. Se observar, na realidade você terá (considerando o “padrão de mercado”) quatro funções num único requisito. O ideal é que você tenha um Requisito Funcional para cada função (RF01 – Incluir Marca de Carro, RF02 – Alterar Marca de Carro, RF03 – Consultar Marca de Carro, RF04 – Excluir Marca de Carro). O mesmo se aplicaria ao Modelo do carro.

      – Relacionamento: Está correto. Ignorando o item acima, existe uma dependência do RF02 para o RF01, de fato. Pois apenas pode haver o cadastro do Modelo após o cadastro da Marca. Então, você tem uma relação de dependência partindo do RF02 para o RF01.
      E isso tem sim que ser especificado, senão você irá ferir a semântica do seu modelo de requisitos, o que comprometerá a qualidade da sua especificação, gerando prejuízos para o projeto.

      Qualquer dúvida estou à disposição.

      Abraço!

  • Pingback: Entendendo o Diagrama de Atividades da UML()

  • Danilo Braz

    Excelente artigo, parabéns e obrigado!

    • Plínio Ventura

      Obrigado, Danilo! Espero que o conteúdo tenha sido útil!

  • Kaio Cesar

    Execelente artigo! Muito bom, irmão.

    • Plínio Ventura

      Que bom que o conteúdo foi útil, Kaio!

      Qualquer dúvida estamos à disposição!

  • Leonardo Araujo

    Olá Plinio, bom dia!
    Excelente explicação, obrigado por compartilhar conosco.
    Gostaria de tirar uma dúvida com você, se for possível! Preciso elaborar um documento que trata um processo de matrícula, no fluxo exitem apenas alguns termos de aceite…pergunta…neste caso, posso considerar os termos de aceite como “requisitos funcionais”???
    Obrigado novamente, Leonardo.

    • Plínio Ventura

      Oi Leonardo! Que bom que o conteúdo tem sido útil.

      Pelo que entendi, neste caso seriam Regras de Negócio, e não Requisitos Funcionais. Se quiser pode detalhar mais, que avalio.

      Abraço!

      • Leonardo Araujo

        Olá Plinio, bom dia!
        Obrigado pelo retorno. Então, trata-se uma rotina de matricula que vou incluir em um site…a matricula em si tem varias paginas de “termos de acordo” e ao final delas o aluno conclui e finalizamos a matricula. A unica rotina que ele vai interagir é a de matricula mesmo…o que pegou pra mim, foi que ele tem um rotina mais pelos menos umas 3 paginas que “termos” para dar o “de acordo”, isso que ficou meio obscuro…

        • Plínio Ventura

          Entendi melhor, Leonardo. Se isso for conteúdo mantido pelo usuário e não gerar impacto no funcionamento do sistema, então acho que é algo transparente para sua especificação. Mas beleza, qualquer coisa estamos aí!

          Abraço!

  • Daniel Glezer

    Sinto falta de referências documentais seja no BABOK, PMBOK e SWEBOK que definam claramente o que é uma especificação funcional e uma especificação técnica. A grosso modo, front-end ou elementos visuais e comportamentos de regras de negócio são funcionais. Literalmente, tudo que é back-end ou elementos voltados a bancos, tabelas, comunicação e etc. é especificação técnica. Existe alguma referência “em pedra” para estes conceitos? Exemplos para exercitar: 1) tamanho e tipo de variavel de campo é técnico ou funcional? 2) identidade visual do posicionamento de campos é técnico ou funcional? 3) fluxo de processo desejado citando métodos síncronos e assíncronos é técnico ou funcional? obrigado;

    • Plínio Ventura

      Olá Daniel, tudo bem?

      “Escrito na Pedra”, que eu conheça, realmente não existe. Talvez seja um assunto, no contexto da sua questão, inviável de se “separar definitivamente”.

      Mas penso que a ausência de tal separação algumas vezes causa mais prejuízo que benefício, pois como comunicação é tudo em projetos de quaisquer natureza, não é raro as responsabilidades ficarem mal definidas (tanto para os técnicos do time, quanto até mesmo para clientes e gestores). Os efeitos disso imagino que já sabe. Vira um “empurra empurra” de responsabilidades.

      Mas eu sugiro uma coisa para separar isso, ao menos por “aproximação”. Quando falamos de Modelagem de Software, temos Modelagem Conceitual, do Comportamento, da Estrutura, da Arquitetura etc. Pense que: Modelagem Conceitual/Funcional e Comportamental = Negócio + Front End, Modelagem Estrutural e Arquitetural = Back End.

      Na Modelagem Conceitual/Funcional tratamos processos de negócio e requisitos de software (Requisitos Funcionais, Não Funcionais e Regras de Negócio).

      Na Modelagem Comportamental tratamos as funcionalidades e o comportamento destas (Casos de Uso, Estórias de Usuário, Protótipos).

      Na Modelagem Estrutural tratamos a “estrutura de fato” do sistema (Banco de Dados [físico e lógico], Classes, Algoritmos etc.).

      Na Modelagem Arquitetural tratamos as Camadas, padrões aplicados, integrações, construção dos Requisitos Não Funcionais etc.

      Minha resposta é um “super resumo”, mas espero que ajude. Caso queira falar mais, estou à disposição!

      Grande abraço!

      • Daniel Glezer

        Super pertinente e enriquecedora a sua resposta e, ainda por cima, muitos projetos fracassam por falha de comunicação, muito “achismo”, preconceitos e até interpretação de termos como estes que conversamos, forma de escrita, etc.

        O que acredito que seja interessante seja empresas adorarem, a fim de suprir lacunas, dicionários de dados área recomendando o uso deste ou aquele termo/expressão, como uma referencia consultiva, e que sempre seja atualizado, modelos funcionais e técnicos, conforme o tipo de produto abordado em sua empresa, etc. Enfim, tudo que pelo menos minimize as falhas mais grotescas de longos textos que poderiam ser mais objetivos e claros tornando requisitos mais blindados, e não dar brecha para serem mal interpretados, ou até se tornarem tão confusos.

        Grato pela oportunidade enriquecedora, friso mais uma vez!

        • Plínio Ventura

          Daniel,

          Eu quem agradeço sua participação. Realmente, ainda há muito o que amadurecermos na nossa área, e talvez não necessariamente na “tecnologia”, mas sim, na gestão, no processo, na cultura, e semelhantes.

          Grande abraço!

  • George Bentes

    Ótimo artigo, claro e específico. Gostei bastante, deu para compreender bem melhor os requisitos funcionais, parabéns!

    • Plínio Ventura

      Oi George! Obrigado pela visita, que bom que o conteúdo tem sido útil a você.

      Precisando estamos aí, grande abraço!

  • Pingback: O que é Scrum()

  • Pingback: O que é Requisito Inverso()

  • Plínio Ventura

    Oi Leonardo!

    Este comentário, por alguma razão desconhecida, ficou “perdido” no sistema de comentários. Mas mesmo passado tanto tempo, segue resposta.

    Não entendi sua dúvida. Na realidade não existem dois documentos, existe apenas um, e este deve ser publicado tanto aos usuários quanto aos desenvolvedores.

    Qualquer comentário adicional fique à vontade.

    Abraço!

  • Silvana Gramostini

    Bom dia Plinio muito bom o conteúdo abordado gostaria de saber como faço para citar este artigo em meu trabalho.
    Att Silvana

    • Plínio Ventura

      Olá Silvana! Que bom que gostou do conteúdo.

      Para que eu possa lhe responder de maneira objetiva, o que exatamente é o seu trabalho?

      Abraço!

      • Silvana Gramostini

        Plinio Ventura meu trabalho é a inclusão das pessoas com deficiência, sobretudo pessoas com visão monocular. a visão monocular é uma deficiência que não é visível a menos que a pessoa com essa deficiência tenha eviscerado um dos olhos e esse é um dos motivos aos quais a deficiencia é discriminada. O fato é que independente do que causou a deficiência, a visão monocular é limitante. Existe um roll de profissões que pessoas com visão monocular são impedidas de exercer por exemplo Ao se tratar das vedações no mercado de trabalho público e privado, tais cidadãos são proibidos de exercer inúmeras carreiras profissionais: Marinha, Exército, Aeronáutica, Polícia Rodoviária
        Federal, Polícia Rodoviária Estadual, Polícia Ferroviária Federal, Polícia Federal, Polícia Militar, Polícia Civil, Polícia Judiciária do Senado Federal, Força Nacional, Câmara Federal, Assembleias Legislativas e Câmaras Municipais, Segurança Judiciário deTribunais e particulares, Guarda Municipal, Corpo de Bombeiros, oftalmologista (além de outras profissões médico/científicas) em função do uso de aparelhos profissionais que exigem a visão binocular (nos dois olhos), motorista profissional nas categorias “C”, “D”e “E” e profissões conexas (700% a mais de acidentes de trânsito, permitindo-se apenas a aquisição da Carteira Nacional de Habilitação (CNH) “A” e “B” – Resolução nº. 267 /2008 – Anexo II – CONTRAN), vedação ao trabalho em plataformas petrolíferas, operador de guindaste, Operador de empilhadeira e máquinas de grande porte, indústrias químicas,laboratórios, comissário de bordo, barbeiro, esteticista, barman, garçom, pedreiro,costureiro, mecânico, trabalhador da agulha, cirurgião); aqueles que envolvem a operação do veículo (por exemplo piloto da linha aérea, maquinista); e
        algum trabalho que exige a vigilância visual prolongado (por exemplo controlador de tráfego aéreo).” ou seja, atividades que exigem estereopsia, visão nos dois olhos ou visão clara de profundidade. E por isso foi sancionada a lei estadual 14.481/11 e a sumulas 377 do STJ e a sumula de numero 45 da AGU, bem como o parecer do ministério do trabalho de numero 444/11 que reconhece a visão monocular como deficiência porém os direitos de tais pessoas NÃO ESTÃO SENDO RESPEITADOS. Em 17 estados do brasil vigoram leis estaduais reconhecendo a visão monocular como deficiência inclusive alguns municipios Paulistas como por exemplo a cidade de Santos. Outro fator importante a ser considerado é que pessoas com visão monocular não tiram as vagas dos demais deficiêntes do mercado de trabalho como reza o CONADE que segrega pessoas com visão monocular achando que estas são pessoas impostores. Alias impostor é o orgão que se diz inclusivo quando na verdade é um segregador. Cabe lembrar aqui que cada deficiência tem suas limitações e caracteristica intrinsecas por isso nunca compare uma deficiência com outra, e não é porque a pessoa perdeu a visão um dos olhos que ela não vai ter limitações no seu dia a dia. Pelo contrario existe sim limitação e o risco iminente da pessoa com visão monocular se torna no futuro UM CEGO TOTAL. Agora será que a pessoa com visão monocular precisa ficar totalmente cega para ter seus direitos reconhecidos? Deixo aqui para o senhor uma sugestão: A criação de um projeto de lei que reconheça a visão monocular como deficiência no municipio de Valinhos. E quero lembra-lo que estamos nos organizando no Brasil todo para lutarmos por uma lei federal que nos reconheça como deficiêntes visuais. afinal a visão monocular é um tipo de deficiência que não é vista mas é discriminada, pelo mercado de trabalho, e pela sociedade que NÃO ENTENDE O QUE É TER VISÃO MONOCULAR e as limitações que a visão monocular causa na vida de quem tem essa deficiência. Veja também as limitações para o monocular dirigir. Desafios aumentados terão os indivíduos monoculares para dirigir. Tais dificuldades relacionam-se especificamente à percepção de profundidade e à visão periférica. “Por todo o país, indivíduos danificados monocularmente têm sete vezes mais acidentes do que a população geral com que foi comparado.” Recomenda que para monoculares seja negado licenças da classe 1, (licença de dirigir comercialmente no transporte de pessoas), e isso seja advertido pelos doutores a respeito do risco aumentado de acidentes. Os DAE (dispositivo automático de entrada) óticos tais como espelhos com campos largos e espelhos em ambos os lados do veículo são recomendados para o motorista monocular. Tais limitações podem incluir: equipamento adaptável especial (por exemplo espelhos, transmissão automática), dirigir somente na luz do dia, limitações da
        velocidade, dentro de determinadas distâncias, limitação do tempo, e/ou de não dirigir em estradas. A pessoa pode ser requerida a ter sua licença de motorista renovada mais frequentemente do que de outra maneira. Estão ai informações importantes para serem analisadas. Tenho uma proposta de lei para ser implantada no municipio. Veja que a causa é nobre e justa e NÃO FERE A CONSTITUIÇÃO.

        • Plínio Ventura

          Silvana, boa tarde!

          Interessante, realmente parece um causa nobre, e neste tipo de causa todo engajamento honesto é pertinente. Muito legal!

          Sobre a citação dos posts aqui do blog, fique à vontade. Espero que o conteúdo possa somar ao seu trabalho.

          Abraço!
          Plínio Ventura

  • Pingback: Engenharia de Software - Perguntas e Respostas()

  • Rafaela Zanezi

    Olá, li sua matéria sobre Requisito Funcional e também sobre Regra de Negócio, e tenho uma dúvida: Em que parte da documentação do meu sistema eu poderia definir coisas como tamanho máximo de campos, caracteres aceitos, valores por defeito, obrigatoriedade do campo, ou seja, validações em geral?

    • Plínio Ventura

      Olá Rafaela!

      Este tipo de informação está ligado ao artefato que “materialiará a funcionalidade”. Sendo menos rigoroso nos termos, rs, é na interface gráfica (tela), por exemplo.

      O local onde estas especificações estarão descritas depende do que você usa na sua modelagem. Veja neste URL um exemplo:
      http://www.indtech.com.br/especificacao-interface-duvida-regras-interface-alunos-requisitos.png

      É necessário que você tenha um local para incluir isso. No caso da imagem em anexo há o uso de uma Ferramenta Case, e no modelo se faz o uso de um elemento chamado “Screen”, onde se ilustra a funcionalidade, e “por trás da tela” há um campo texto onde as especificações são incluídas.

      Se você tiver o desenho da tela em algum artefato, pode fazer um documento word com um índice por tela, e em cada tópico, colocar as especificações. Se não tiver o desenho, penso que pode ter o mesmo documento.

      Qualquer dúvida ou comentário adicional, fique à vontade!

      Abraço!