Tópicos Especiais em Engenharia de Software

US, RN, RF, RI e BDD

Eduardo Martinenco
Letícia Hoffmann
Luciano Almeida
Raphael Rodrigues

Agenda

User Story
Regras de Negócio
Requisitos Funcionais
Requisitos de Interface
BDD

User Story

User story ou “história de usuário” é uma descrição concisa de uma necessidade do usuário do produto, (ou seja, de um requisito) sob o ponto de vista desse usuário.

A User Story busca descrever a necessidade de uma forma curta, simples e clara.

Ela é apenas uma promessa de uma conversa, um lembrete de que mais detalhes serão necessários e não deve ser considerados suficientes para a realização do trabalho.

User Stories possui três aspectos críticos,
os chamados três Cs:

Cartão

As conversas

A confirmação

Construindo uma User Story:

Ator

Ação

Funcionalidades

Construindo User Story:

Fonte: http://blog.myscrumhalf.com

Construindo User Story:

Fonte: http://blog.myscrumhalf.com

Exemplo US

Fonte: http://pt.slideshare.net/manoelp/exemplos-de-user-stories

Regras de Negócio

Fonte: http://www.vecteezy.com

As regras de negócios são tipos de requisitos de como os negócios, incluindo suas ferramentas de negócios, devem operar. Podem ser leis e regulamentos impostos ao negócio, mas também expressam a arquitetura e o estilo de negócio escolhidos.

Regras de Negócio

É uma linguagem "natural", com estruturação semântica precisa, destinada a ser usada, entendida e mantida por pessoas ligadas ao negócio, não por especialistas em TI ou por sistemas e linguagens de programação.

Regras de Negócio

Uma regra de negócio estabelece as condições em que os fatos são válidos, ou as restrições que devem ser observadas no tratamento dos fatos.

Exemplo

Um CLIENTE só pode fazer um PEDIDO se tiver seu CRÉDITO APROVADO

Note que a regra acima implica na existência de dois fatos: CLIENTE faz PEDIDO e CLIENTE tem CRÉDITO APROVADO

Formas de capturar as regras de negócio:

Baseadas em modelos

Baseadas em documentos

Categorias de regras de negócio:

Regras de limite

Regras de derivação

Regras de limite:

Regras de estímulo e resposta

Regras de limite de operação

Regras de limite de estrutura

Regras de derivação:

Regras de conclusão

Regras de cálculo

Regras de estímulo e resposta

Fonte: http://www.funpar.ufpr.br

Regras de limite de operação

Fonte: http://www.funpar.ufpr.br

Regras de limite de estrutura

Fonte: http://www.funpar.ufpr.br

Regras de conclusão

Fonte: http://www.funpar.ufpr.br

Regras de cálculo

Fonte: http://www.funpar.ufpr.br

Requisitos Funcionais

Requisitos funcionais são as necessidades apontadas pelo cliente, ou seja, o que ele quer que o sistema faça. Estes requisitos são obtidos durante a etapa de levantamento de requisitos junto ao cliente e demais usuários. A partir disto defini-se uma função de um sistema de software ou seu componente. Uma função é descrita como um conjunto de entradas, seu comportamento e as saídas (envolve cálculos, lógicas de trabalho, manipulação e processamento de dados, entre outros).

Dentro dos requisitos funcionais também encontram-se a arquitetura do aplicativo, diferentemente da arquitetura técnica, que pertence aos requisitos não funcionais.

Exemplos:

Gerenciar vendas

Emitir relatórios

Consultar usuários

Muitos autores ainda dividem os requisitos funcionais em três: evidente, escondida e friso.

Evidentes: é quando o usuário final do sistema está ciente do que está sendo executado.
Escondida: é quando uma função está sendo feita, mas é invisível ao usuário.
Friso: quando a execução da funcionalidade não afeta outras funções do software.

Boa parte da qualidade do software está centrada em atender tais requisitos, uma vez que esse é o comportamento esperado pelo cliente.

Exemplo de Requisito Funcional - RF

Fonte: http://ericlemes.com/2009

Exemplo de Requisito Funcional - RF

Fonte: http://ihuru.fe.up.pt

Requisitos de Interface

Requisitos de Interface

Fonte: http://image.uisdc.com/

São as regras que determinam formato/aparência de campos, comportamento dos componentes das janelas e outras informações relevantes à interface gráfica.

Exemplo Requisitos de Interface

Layout Sugerido

Exemplo Requisitos de Interface

Campos

Exemplo Requisitos de Interface

Navegação Web

Fonte: www.gmaxweb.com.br

Exemplo Requisitos de Interface

Navegação Mobile

Fonte: www.gmaxweb.com.br

Prototipagem

O uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos. Trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis.

Fonte: inventbordados.blogspot.com

Fonte: webanduxdesign.tumblr.com

Fonte: materialpatterns.tumblr.com

Behaviour-Driven Development

Fonte: https://plus.google.com/+Qaworks/
Desenvolvimento Orientado por Comportamento
Dan North criou o primeiro framework de BDD, em 2006

O que é?

BDD é técnica de desenvolvimento ágil que visa integrar regras de negócios com linguagem de programação, focando o comportamento do software;

Trata-se de uma evolução do TDD;

É uma abordagem de design de software com foco no domínio do software (Domínio nada mais é que do atender completamente um determinado negócio).

Para que serve?

Utilizando BDD em apenas um repositório, você mantém os testes de aceite automatizados de uma forma simples de ler para o cliente, desenvolvedores, QAs e demais membros da equipe. Nessa abordagem, a documentação e o código de desenvolvimento evoluem sempre juntos.

Camadas BDD

Fonte: http://elemarjr.net

Ferramentas

Sintaxe Gherkin

Fonte: http://pt.slideshare.net/dversaci/behavior-driven-development-bdd-and-agile-testing

BDD Cenário

Fonte: try.behave.pro

Cenário em pt

Fonte: http://elemarjr.net

Testes ágeis com BDD

Comparação entre Caso de teste e BDD cenário

As razões para os testes tradicionais serem superados pelos testes ágeis

Grandes volume de atividade manuais de teste atrasam a entrega;
As equipes só começam a testar quando o sistema tenha sido desenvolvido e integrado;
Um grande bloqueio da entrega no prazo é descobrir no final do ciclo de desenvolvimento que sua aplicação possui grandes problemas de qualidade.

Case

Referência

http://blog.myscrumhalf.com/2011/10/user-stories-o-que-sao-como-usar/
http://arquiteturadeinformacao.com/user-experience/como-criar-uma-user-story/
https://extreme-programming-mds.googlecode.com/files/user_stories.pdf
http://www.knowledge21.com.br/
sobreagilidade/user-stories/o-que-e-user-story/
http://eduardopires.net.br/2012/06/ddd-tdd-bdd/
http://www.bugbang.com.br/entendendo-bdd-com-cucumber-parte-i/
http://dannorth.net/whats-in-a-story/
https://pt.wikipedia.org/wiki/Behavior_Driven_Development
http://henriqueluz.com.br/2012/05/05/as-vantagens-do-bdd-em-times-ageis/
http://www.infoq.com/br/news/2014/07/desenvolvimento-agil-testes
http://raphaelrodrigs.github.io/learnbdd/#/
http://blog.makesys.com.br/definindo-seu-software-o-que-sao-requisitos-funcionais-e-nao-funcionais
http://www.profissionaisti.com.br/2013/02/a-importancia-dos-requisitos-nao-funcionais/
http://www.cin.ufpe.br/~gta/rup-vc/extend.bus_model/guidances/guidelines/business_rules_E6E7173.html
http://www.centus.com.br/base-de-conhecimento/artigos/definindoregrasdenegocio