[Artigos]  [Básico] - Requisitos inversos Publicado por rboaro : Quarta, Agosto 07, 2013 - 11:01 GMT-3 (415 leituras)  2 Comentários    Enviar para um amigo    Versão para impressão Alô, leitores! Há algum tempo, publiquei um artigo sobre a importância dos requisitos não-funcionais no desenvolvimento de um software e também comentei brevemente sobre os requisitos funcionais. Além destas duas categorias de requisitos, existe também uma vertente conhecida como requisitos inversos. Já ouviram falar? Requisitos inversos? O que são? Já sabemos que, grosso modo, os requisitos funcionais se referem aos requisitos levantados junto ao cliente, e os requisitos não funcionais envolvem as características técnicas do software, certo? Pois bem, os requisitos inversos, por sua vez, são simplesmente relacionados com as condições que não devem ocorrer no software. Isso mesmo! Na prática, os requisitos inversos são o oposto dos requisitos funcionais. Além dessa definição, os requisitos inversos também dizem respeito ao que o software não deve realizar dentro de seus limites de escopo, tecnicamente chamados de “fronteira”. Fronteira? Fronteira do SoftwareSim. Nesse contexto, fronteira é o termo utilizado para designar o que o software pode realizar dentro da sua dimensão. Por exemplo, suponha que a sua empresa esteja desenvolvendo um software para gestão de vendas, e que os dados dessas vendas também deverão estar na nuvem para que os vendedores da empresa possam acessá-los em seus tablets. Porém, o sistema utilizado nos tablets já está desenvolvido e, portanto, podemos dizer que ele não faz parte da fronteira do seu sistema. A forma como os vendedores acessam os dados das vendas, emitem relatórios e geram novos pedidos não contempla o escopo da aplicação que você está desenvolvendo. Entendo. Você poderia citar alguns exemplos de requisitos inversos? Claro! Mas antes dos exemplos, é interessante comentar sobre as nomenclaturas normalmente utilizadas em documentações de software para indicar o tipo de requisito: RF – Requisito Funcional (ou RN – Regra de Negócio) RNF – Requisito Não-Funcional RI – Requisito Inverso Geralmente, essas nomenclaturas são acompanhadas de um número sequencial para identificar cada requisito do software. Lógico, nada impede que cada empresa defina seus próprios padrões de nomenclatura conforme a necessidade, portanto, as nomenclaturas acima não são uma regra. Partindo dessas definições, poderíamos ter os seguintes requisitos inversos: [RI-10] O sistema não deve ser acessado pela internet [RI-16] O backup não pode ser executado durante a sincronização de dados [RI-25] O sistema não deve permitir vendas com datas retroativas [RI-32] Exceções do WebService não devem ser gravadas no log de erros principal [RI-39] O sistema não deve processar escrita fiscal, apenas a exportação dos dados Observe que todas as frases acima contém a palavra “não”. Essa é uma caraterística comum dos requisitos inversos, uma vez que tratam de situações que devem ser evitadas pelo software. Embora alguns requisitos inversos sejam relativamente óbvios (como o RI-16, sobre o backup), é importante documentá-los para evitar a falta de cobertura nas especificações, ou servir como base de conhecimento para analistas, desenvolvedores e projetistas da empresa. Vale lembrar que não é recomendado abusar na especificação de requisitos inversos. A maioria dos requisitos devidamente atribuídos como funcionais já vão de encontro com as condições que não devem ocorrer no software. Portanto, especificar os requisitos inversos, neste caso, causaria uma redundância de informações. Para exemplificar a afirmação acima, observe os requisitos funcional e inverso abaixo: [RF-48] O CNPJ é campo obrigatório e deve ser validado [RI-16] O CNPJ não pode ser nulo O requisito funcional, por informar que o campo CNPJ é obrigatório, logicamente já induz o ideia de que o campo não pode ser nulo. Além disso, corre-se o risco do requisito funcional não condizer com o requisito inverso, resultando em um conflito de especificação. É preciso ficar atento à essas similaridades para não causar equívocos ou criar documentos muito extensos. Fico por aqui, leitores! Um abraço e até a próxima semana! Link Original do Artigo: http://www.subrotina.com.br/requisitos-inversos/

Comentários

Ordem:  Os mais antigos primeiro Os mais recentes primeiro Melhores primeiro

Comentários pertencem aos seus respectivos autores. Não somos responsáveis pelo seus conteúdos.

por: Batera (andreinfo@hotmail.com) : Ago 27, 2013 - 05:43 (Informações sobre o membro | Enviar uma mensagem) http://www.subrotina.com.br

Olá, carbox. Agradeço pelo elogio e por deixar o comentário! Realmente, para alguns clientes, o programador é um ser paranormal e o software é uma previsão do futuro, rsrs. E concordo com você: se houvesse uma forma de "injetar" os requisitos inversos dentro da cabeça do usuário, tudo seria bem mais fácil, rsrs. Abraço!

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema

Copyright© 2001-2016 – Active Delphi – Todos os direitos reservados