Como escrever requisitos de software

de forma simples e garantir o mínimo de erros no sistema/app??

Já recebeu uma demanda para desenvolvimento de um projeto ou funcionalidade de um produto e ficou se perguntando sobre mais detalhes do qual o cliente esta indeciso ou não sabe ao certo o que quer? E de quebra veio junto aquele prazo para ontem? E aí, como você pode agilizar para desenvolver?

Por mais que tenhamos experiência em desenvolvimento, escrever os requisitos se torna uma tarefa um tanto instigante. Quando trabalhava como DBA descobri a necessidade de especificar os requisitos para ganhar tempo quanto a modelagem do banco e desenvolvimento do sistema, sim … era uma especie de analista de dados e de sistemas. A proposta chegava em uma folha de papel, “se vira, faça uma casa”, tive dificuldade em desenvolver por conta da falta de clareza dos requisitos, sendo que eu não tinha experiência alguma em documentar, então tive que melhorar essas habilidades.

Seja em qualquer projeto bons requisitos proporcionam o desenvolvimento de um sistema mais claro, coeso e mais próximo de alcançar a satisfação do cliente dentro do orçamento e prazo acordados.

1. Antes de mais nada, o que é “Requisito de Software”?

A norma IEEE-90, define como sendo:

1- Uma capacidade que um usuário necessita para resolver um problema ou atingir um objetivo;
2. Uma capacidade que deve ser atendida ou possuída por um sistema ou componente de um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto;
3. O conjunto de todos os requisitos que formam a base para o desenvolvimento subseqüente de um software ou componentes de um software;

Em outras palavras, quando falamos de requisito, tange a solicitação do cliente, como: necessidades, exigências e desejos.

Por conseguinte seria a necessidades de um usuário/cliente, exigências do negócio, desejos da empresa, solicitação da empresa, realizados por um sistema ou produto, dessa forma, a aplicação deve atender estas premissas: necessidades, exigências, desejos e solicitações, utilizando como ferramenta conducente para prover um sistema, aplicativo/solução de um produto.

2- Qual o processo de Engenharia de Requisitos?

Para um bom desenvolvimento é importante identificar os requisitos, pois a partir desta fase podem surgir muitos erros, que se não corrigidos a tempo impactaram em tempo do custo de desenvolvimento e valor.

“No desenvolvimento de software, a qualidade do produto está diretamente relacionada à qualidade do processo de desenvolvimento.”

O processo é iniciado com a elicitação dos dados, que são coletados mediante entrevistas, documentos, reuniões, workshops, prototipagem e etc..

Elicitação e análise de Requisitos

Inicialmente identificamos o(s) problema(s)(uma breve descrição)a resolver e os envolvidos no sistema, também conhecidos como stakeholders. Os stakeholders são os donos do negócio e muitas vezes com quem está a informação preciosa, entreviste também pessoas que direta ou indiretamente influenciam no produto(sistema/app), ou seja, quem vai utilizar e a partir daí colete as informações preliminares para os requisitos.

Vale ressaltar que os requisitos são fundamentais tanto para estimativa de preço quanto para modelagem, projeto, implementação, testes e também manutenibilidade. Dessa forma, os requisitos tornam-se intrínsecos ao ciclo de vida do software, ou seja, como se fosse a água para a vida dos seres vivos.

Especificação de Requisitos

Na especificação pode conter requisitos funcionais e não-funcional e até mesmo um diagrama de caso de uso ou prototipação de parte do produto. São descritos o passo a passo de cada funcionalidade bem como suas devidas restrições.

Validação de Requisitos

Após a escrita de necessidades do cliente/usuário é importante que você valide esses dados, seja através de uma reunião fazendo com que os responsáveis assinem o documento para que ele possa ter validade, ou dando ciência da responsabilidade dos requisitos levantados por e-mail. Essa etapa também serve para correções e podem ser descobertos/inclusos outras funcionalidade.

Documento de Requisitos

Imagine o desenvolvimento de um sistema que você ou outra pessoa fizeram há alguns anos atrás, detalhe sem documentar. Você é capaz de lembrar todas as regras e funcionalidades? Bom, eu não me recordo de tudo! O documento serve para apresentar uma visão geral e funcional do produto, mas o que deve contém?

• Introdução
• Visão geral do produto
• Termos técnicos específicos para um determinado contexto
• Abreviações e acrônimos
• Envolvidos e Usuários
• Requisitos (Funcionais, Não-Funcionais e Regras de Negócio)
• Caso de Uso
• Anexos (protótipos, arquitetura e documentos auxiliares)

3- Quais os tipos de Requisitos?

Os requisitos possuem peculiaridades A Engenharia de Requisitos ocupa-se principalmente dos requisitos do sistema. Além desses, existem também os requisitos de projeto e os requisitos de processo. Os Requisitos podem ser subclassificados em requisitos funcionais, requisitos de qualidade ou não funcional e restrições ou regra de negócio.

Funcionais: Nada mais é, como o próprio nome por si já diz, referem a funcionalidades do sistema, são as funções que o sistema/aplicativo devem possuir para atender o negócio e suas regras.

Não-Funcionais (Qualidade): Tangem a exigência técnica de um ambiente, como sendo: aspectos de segurança do sistema, desempenho, prevenção de falhas e etc.

Regra de Negócios (Restrições): são premissas e/ou restrições aplicadas a uma operação comercial de uma empresa por exemplo, de forma que atenda ao negócio e funcione da maneira esperada, ou seja, conforme as regras estabelecidas.

• Requisito Funcional RF01 — Validar campo de e-mail;
• Regra de Negócio RN02 — Ao clicar no campo de senha, animar coruja;
• Requisito Não-Funcional RNF03 — Requisitos de portabilidade: o sistema deverá rodar em qualquer plataforma.

Caso de Uso: Uma outra forma de especificar requisitos é através de caso que uso, onde contém o nome da funcionalidade e pode ser conter sua respectiva descrição. No caso de uso você define o ator de maneira a relacionar com as funcionalidades, a partir dessa fase fica melhor descrito os requisitos para então iniciar o modelagem do banco, desenvolvimento e outras etapas.

4- A prototipagem

Como já informado nos itens anteriores, certamente o que ajuda a muitos desenvolvedores, são as ferramentas de prototipagem que nos permite ter uma previa do que vamos construir e também serve como ferramenta conducente para validação do produto com o cliente.

O protótipo nada mais é do que um modelos funcional construído com base nos requisitos elicitados simulando o sistema/app a ser desenvolvido. Ele é a forma mais rápida e econômica de se definir e até mesmo validar um produto, com ele é possível dirimir muitas dúvidas.

Podemos prototipar em uma folha de papel, imagem gráfica dentre outras. Quanto as categorias de protótipos temos:

Storyboard: Mais utilizado para desenvolvimento de jogos, apresentam cenários considerando sequencias de cenas, personagens, sons entre outros, proporcionando aos designers a simular de situações do projeto.

Baixa Fidelidade: Nessa etapa são rabiscadas as primeiras necessidades do requisito, onde não há necessidade de se preocupar com o resultado final já que está é a fase inicial e ocorre durante a concepção do sistema. É feito um esboço em papel e forma superficial e rápida apenas para pleitear a ideia do projeto, podendo utilizar até post-its.

Média Fidelidade: Nesta etapa são construídos os Wireframes, que são nada mais do que os aspectos mais definidos em comparação ao de baixa fidelidade, pode utilizar papel e lápis para sua construção ou softwares e que montem a estrutura mais linear.

Alta Fidelidade: Esta é a etapa em que são feitos os mockups ou protótipo funcional chegando mais próximo do produto final, onde permite o usuário ter uma visão mais clara, por ter mais iteratividade com os componentes e formas de navegação, sendo possível não só simular o fluxo de trabalho mas também validar o produto.

Mas então quando usa-los? quando tenho uma ideia bem vaga do que desejo desenvolver utilizo o protótipo de baixa fidelidade pois é mais fácil alterar logo no início. Me sinto mais confortável em desenhar um Wireframe no papel ou por vezes com os softwares para prototipagem: Pencil Project, Mockup, Axure, Gliffy, MockingBot entre outros.

Quando as etapas e regras já são de conhecimento prévio, prefiro escrever os requisitos e costumo inserir anexo dos protótipos. Por onde começar primeiro? Definindo o problema, você pode iniciar por onde sentir mais afinidade, não existe uma ordem especifica, porém é imprescindível a validação dos requisitos.

5- Sintomas de uma Especificação de Requisitos inadequada

Omissão do cenário do problema como um todo pelos stakeholders, por achar que não precisa ser informado. Prejudica e muito, tente coletar o máximo de informações sobre o problema a ser resolvido;

Problemas de comunicação devido a diferentes níveis de experiência e conhecimento, entre a equipe e cliente;

Pressão do cliente para desenvolvimento de um sistema rapidamente e disponibilizá-lo em produção. Sabe aquela demanda do chefe/cliente que vem pra ontem? Muitas vezes não se tem como fugir, mas deixe claro que pode prejudicar o projeto se não forem seguidas as etapas básicas, como coletar, testar e validar os requisitos.

6- Consequências de não documentação

• Baixa qualidade;
• Retrabalho;
• Escopo indefinido, acredite seu filho pode virar um Frank Einstein de tanto armengue;
• Problemas de usabilidade;
• Insatisfação do cliente;
• Ciclo de manutenção maior;
• Vulnerável a falhas e invasões.

7- Considerações Finais

Bom, procurei reunir as informações mais importantes e minímas para elucidar a importância de escrever e validar os requisitos antes do desenvolvimento de software.

O que mais escuto de colegas quanto a análise de requisitos é “Vei, isso é um trabalho do cão, vou levar mais tempo fazendo isso, pra mim não dá, como você consegue fazer isso?”.

Apenas uma dica, proponha-se em fazer as bases de uma casa antes de entrar nela para que não desabe. Velhos hábitos não se mudam radicalmente mas podem ser moldados em doses homeopáticas ;)

8- Referências

Especificações Técnicas de Software, ADILSON DA SILVA LIMA, (2012): http://www.editorasaraiva.com.br/produto/tecnico/informatica/especificacoes-tecnicas-de-software/

 

Fonte: https://pt.linkedin.com/pulse/como-escrever-requisitos-de-software-forma-simples-e-garantir-santos