Na aula anterior, vimos quem são os nossos requisitos funcionais e não funcionais. Agora, vamos ver juntos como diferenciar e fazer um levantamento correto delas.

Obs. A vídeo aula é opcional, mas recomendamos que acompanhe pra um entendimento mais aprofundado.

Como coletar os requisitos?

Na realidade, vamos responder com uma outra pergunta: por onde não coletar os requisitos. Ou seja, jamais utilize a imaginação pra coletar requisitos, use sempre os dados levantados através das pesquisas e conversas com os stakeholders envolvidos sobre as RFs, RNFs e RNs. A partir dali, seu papel como desenvolvedor é de “traduzir” os desejos em funcionalidades concretas para o software.

O que é um processo de Engenharia de Requisitos?

Pressman descreve um processo de engenharia de requisitos composto por cinco etapas:

1. Elicitação de Requisitos: Nesta etapa, os requisitos são coletados de diferentes fontes, como stakeholders, usuários e clientes.
2. Análise e Negociação de Requisitos: Os requisitos coletados são analisados para identificar ambiguidades, inconsistências e conflitos. As partes interessadas negociam para chegar a um conjunto final de requisitos acordado.
3. Especificação de Requisitos: Os requisitos acordados são documentados em um documento de especificação de requisitos.
4. Validação de Requisitos: Os requisitos são validados para garantir que atendem às necessidades dos stakeholders e que são completos, consistentes e realistas.
5. Gerenciamento de Requisitos: Os requisitos são gerenciados ao longo do ciclo de vida do projeto para garantir que sejam atualizados e mantidos.

Agora, como eu organizo meus requisitos?

O Lucas Barzan, profissional da área, deu um exemplo prático que vamos reproduzir como um exemplo de organização dos requisitos levantados. Vamos conferir aqui abaixo:

Funcionalidades Macro do Backend

Legenda:
RF: Requisitos Funcionais
RNF: Requisitos Não Funcionais
RN: Regras de Negócio

Funcionalidades

– Cadastro e atualização de Clientes
– Cadastro e atualização de Ordens de Serviço (OS)
– Entradas e Saídas no Caixa
– Usuário
– Cadastro e atualização de Ordens de Serviço (OS)

RF

– O usuário deve poder listar todas as OS’s, filtrando por:
Número (string) (opcional);

– O usuário deve poder mostrar uma OS, incluindo todas as transações relacionadas a esta OS (para saber o que foi pago antecipadamente pelo cliente)

– O usuário deve poder cadastrar uma OS normal enviando:
ID do Cliente (uuid) (obrigatório)
Tipo (int) (obrigatório)
Nome do produto (string) (obrigatório)

…

– O usuário deve poder atualizar os dados da OS

– O usuário deve poder cancelar uma OS

– O usuário deve poder deletar uma OS, confirmando suas credenciais

RNF

– Deve ser criada uma tabela de Ordens de Serviço
– Deve ser criado um campo de ID do tipo UUID
– Deve ser criado um campo Tipo que pode ser:
0: Normal
1: Retorno
– Deve ser criada uma relação com um Cliente específico (One-to-Many/Many-to-One: um Cliente pode ter várias OS’s).

RN

– Os campos de valor não podem ser negativos
– Cada OS deve possuir um “número” único.
– O usuário deve confirmar seu login e senha para cancelar uma OS
– O usuário não deve poder alterar o tipo de uma OS

…

[Demais funcionalidades macro]

Pode haver momentos em que o desenvolvedor acabe “quebrando a cabeça” pra organizar os requisitos e é comum isso acontecer e nem toda a funcionalidade macro pode haver um RNF. O importante é a compreensão do levantamento, da organização pra enfim realizar a codificação.

Por fim, quais são as ferramentas e técnicas para Engenharia de Requisitos?

Existem diversas ferramentas e técnicas disponíveis para auxiliar na engenharia de requisitos, como:

• Diagrama de Casos de Uso: Uma ferramenta para modelar os requisitos funcionais de um sistema – e que vamos utilizar na sala de aula!
• Prototipagem: Uma técnica para criar modelos interativos do sistema para auxiliar na coleta e validação de requisitos.
• Análise de Usabilidade: Uma técnica para avaliar a usabilidade do sistema e identificar áreas que precisam ser melhoradas.

Páginas: 1 2