Descrição de requisitos com casos de uso e histórias do usuário

É uma boa prática aplicar um conjunto de tarefas da engenharia de requisitos antes de iniciar qualquer trabalho ou projeto técnico de software. A engenharia de requisitos fornece o mecanismo apropriado para entender aquilo que o cliente deseja, analisando as necessidades, avaliando a viabilidade, negociando uma solução razoável, especificando a solução sem ambiguidades, validando a especificação e garantindo a necessidade à medida que são transformadas em um sistema operacional.

A engenharia de requisitos deve ser adaptada às necessidades do processo, do projeto ou do produto e das pessoas que estão realizando o trabalho. Algumas pessoas argumentam que os requisitos ficam mais claros à medida que se constrói o sistema, enquanto outras defendem que detalhar todos os requisitos do sistema antes da construção do projeto é mais eficaz. Como citado anteriormente, vai depender das necessidades, mas ambos os argumentos apresentam pontos fortes e fracos que se forem adotados de forma equivocada no projeto podem levar o trabalho ao fracasso.

A maioria das técnicas de levantamento de requisitos não muda muito entre um ambiente tradicional e um ambiente ágil. A priorização de requisitos é essencial, visto que o foco principal em metodologias ágeis é a implementação das principais funcionalidades do sistema, enquanto que nas metodologias tradicionais é a especificação de todos os requisitos antes do desenvolvimento do sistema.

As metodologias tradicionais são baseadas no projeto onde documentos são criados para guiar o processo de desenvolvimento de software, enquanto as metodologias ágeis são baseadas no código onde utilizam menos documentação e adotam processos mais simplificados.

As metodologias ágeis são apontadas como uma alternativa às abordagens tradicionais para o desenvolvimento de software, mas as metodologias tradicionais mesmo sendo conhecidas como rigorosas, pesadas ou orientadas a planejamento, são as mais utilizadas em situações onde os requisitos do sistema são estáveis e os requisitos futuros são previsíveis. A abordagem ágil tem mostrado bons resultados com seu desenvolvimento baseado em código e sua facilidade em adaptar-se às mudanças de requisitos. Isto tem despertado um grande interesse entre desenvolvedores de software.

Portanto, este artigo tem o objetivo principal abordar requisitos no processo unificado RUP e na metodologia ágil Scrum, com intuito de demonstrar como especificar um caso de uso e estórias de usuário.

Especificação de Casos de uso

O PU surgiu como um processo iterativo popular para o desenvolvimento de software, visando a construção de sistemas orientados a objetos. Uma característica crucial do processo unificado e de outros métodos modernos é a iteratividade, ou seja, o projeto é dividido em miniprojetos curtos, de duração fixa, denominadas iterações. Cada iteração é um sistema executável, testável e integrável. Cada iteração inclui as atividades de requisitos, projeto, implementação e teste. Por essa razão também é conhecido como desenvolvimento iterativo evolutivo, pois acolhe mudanças e as encara como fatores inevitáveis e essenciais ao processo.

O Rational Unified Process (RUP) é um refinamento do PU e é muito adotado nas organizações para apoiar o desenvolvimento de software. A UML é parte deste processo de desenvolvimento e é utilizada para padronizar a documentação dos projetos desenvolvidos. O RUP é uma metodologia iterativa, trabalha em ciclos e cada ciclo trabalha com uma versão nova do produto, cada ciclo é divido em quatro fases consecutivas: Concepção, elaboração, construção e transição. "