Carreira

Ξ 1 comentário

Requisitos, nada além do mundo

publicado por Luis Otávio Médici

world
Hoje vamos falar sobre engenharia de requisitos e seus desafios.

A engenharia de requisitos é uma área do conhecimento da engenharia de software que desempenha uma função interdisciplinar de mediação entre os domínios do adquirente e do fornecedor para estabelecer e manter os requisitos que devem ser atendidos pelo sistema, software ou serviço de interesse (Padrão ISO/IEC/IEEE 29148:2011 Systems and software engineering – Life cycle processes -Requirements engineering).

Muitos pesquisadores da engenharia de requisitos trabalharam, e continuam trabalhando, para definir bases conceituais e metodologias para tornar esta mediação entre fornecedor e adquirente um trabalho mais efetivo. Em mais de 30 anos Michael Jackson (ele está vivo e não é cantor), consultor e pesquisador da Open University (Reino Unido) e AT&T Labs (EUA), contribuiu de forma significativa com o avanço desta área. Caso queira conhecer mais sobre seu trabalho e linhas de pesquisa recomendo a visita ao site pessoal. Para desenvolver este trabalho o Jackson estabeleceu uma duradoura parceria com a pesquisadora do AT&T Labs Pamela Zave além de outros acadêmicos.

Para nos ajudar a elicitar requisitos e estabelecer especificações de forma clara e objetiva, Jackson e seus colegas desenvolveram um modelo de referência que define conceitos básicos para aplicação de métodos formais de desenvolvimento de requisitos de usuário e suas reduções para as especificações comportamentais do sistema. Trata-se de um modelo simples e abrangente que nos possibilita pensar o sistema de forma na sua essência, e por isso ele se tornou tão relevante. Vamos a uma figura que representa este modelo de referência:

conceptual_model_ref

Neste modelo, também conhecido como modelo WRSPM, o conjunto W (world) representa o mundo físico cá fora onde, no vocabulário do modelo, acontecem os fenômenos. São exemplos de fenômenos: abrir uma porta, correr, pular, apertar um botão, preencher um formulário, etc. Em outras palavras os fenômenos são fatos que acontecem no mundo real. O conjunto “M” (machine) representa um sistema computacional programável construído para resolver um problema existente no mundo “W” mediante a execução de um programa “P”.

Como o leitor deve ter reparado no diagrama e no texto, estamos chamando de conjuntos os artefatos do modelo WRSPM. Esta denominação vem da aplicação da teoria dos conjuntos na construção deste modelo. A teoria dos conjuntos propõe uma representação gráfica, chamada de diagrama Venn, cujo objetivo é facilitar a compreensão das operações realizadas entre conjuntos. O nome é uma homenagem ao filósofo inglês Jonh Venn (http://en.wikipedia.org/wiki/Venn_diagram).

Para finalizar a descrição do modelo faltou explicar os que são as letras “R” e “S”, desta forma vamos construir uma linha de raciocínio. Para que “R” e “S” surjam é necessário que alguém identifique no mundo “W” uma porção de fenômenos ou fatos que representem um problema que deve ser resolvido. Digamos que a opção seja por resolver este problema utilizando um sistema computacional programável, ou simplesmente máquina “M”. Para que esta máquina “M” execute sua função deve ser elaborado um programa “P”. Da interação entre o mundo (conjunto W) e a máquina (conjunto M) executando o programa “P” temos o sistema “S”. Pensando em termos matemáticos ou lógicos: o conjunto “S” é resultante da intersecção destes conjuntos dos conjuntos “W” e “M” (S = W∩M). Pensando a partir do modelo: o sistema é resultado da interação entre uma máquina e o mundo mediante um programa.

Agora eu pergunto: qual foi a motivação para o desenvolvimento deste sistema? Se voltarmos algumas linhas veremos que a motivação foi a resolução de um problema. Para que tenhamos clareza do problema, com seus fenômenos ou fatos, devemos elaborar os requisitos “R” do sistema. Repare que “R” pertence ao conjunto “W”. Isto nos sinaliza que os requisitos do sistema explicam fenômenos do mundo e devem ser descritos como tal. Por exemplo: ao trabalhar em uma elicitação de requisitos devemos nos empenhar em trazer à tona os fatos ou fenômenos do domínio do problema que é o mundo e não nos termos do domínio do programa que é a máquina. Não estaremos fazendo um bom trabalho de investigação e esclarecimento se realizamos uma elicitação com viés técnico, caindo na tentação de descrever os requisitos nos termos do domínio da máquina e seu programa.

Em resumo, que tal deixarmos o detalhamento técnico para a análise e posterior especificação dos requisitos! Para os requisitos em si o fundamental é o mundo e nada além do mundo.

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

Autor

Engenheiro formado em engenharia elétrica pela Faculdade de Engenharia Industrial (SP) e pós-graduado em administração pela Fundação Getúlio Vargas (SP). Tem com 15 anos de experiência em sistemas embarcados e negócios internacionais, tendo atuado como engenheiro de aplicações, gerente de produtos e engenheiro de sistemas em empresas de telecomunicações, consultoria, representação comercial e distribuidores . Atualmente trabalha na empresa Arcon Serviços Gerenciados de Segurança.

Luis Otávio Médici

Comentários

1 Comment

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade




Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes