O Guia Mais Completo para Gerenciamento de Requisitos e Rastreabilidade

Como escrever documentos de requisitos do sistema (SRS)

Um documento de especificação de requisitos de software (SRS) é um documento essencial para o desenvolvimento de software que fornece uma descrição detalhada das necessidades e requisitos de um projeto específico. Ele descreve os objetivos, escopo, informações básicas, detalhes do projeto, plano de implementação e outras atividades relacionadas. O documento SRS serve como um contrato entre o cliente e o desenvolvedor para garantir que ambas as partes entendam as especificações e expectativas do produto que está sendo desenvolvido. Além disso, ajuda a reduzir os riscos, garantindo que todas as partes interessadas entendam completamente o que se espera delas durante cada fase do projeto.

Um documento SRS bem elaborado deve ser completo, claro e conciso para que possa ser facilmente compreendido por desenvolvedores e clientes. Além disso, ter um SRS instalado garante que quaisquer alterações ou atualizações no produto durante o desenvolvimento possam ser facilmente documentadas e rastreadas. Isso ajuda a minimizar a confusão e garante que o produto final atenda a todos os requisitos especificados no documento. No geral, um SRS é uma ferramenta crítica para projetos de desenvolvimento de software bem-sucedidos, pois fornece uma estrutura clara para o sucesso. Com o uso adequado, pode ajudar as equipes a obter resultados de qualidade com o mínimo de esforço.

Especificação de requisitos de software versus especificação de requisitos de negócios

As pessoas às vezes misturam os conceitos de software e especificações de requisitos de negócios. Na verdade, ambos são bem diferentes.

A principal diferença entre a especificação de requisitos de software e a especificação de requisitos de negócios é que a primeira captura todas as informações relacionadas ao software, enquanto a segunda captura todas as informações relacionadas ao negócio.

Não.	Especificação de Requisitos de Software (SRS)	Especificação de Requisitos de Negócios (BRS)
1.	Especifica os requisitos funcionais e não funcionais presentes no software.	É um documento formal que descreve os vários requisitos fornecidos pelo cliente/partes interessadas.
2.	Ele é derivado da Especificação de Requisitos de Negócios (BRS).	É derivado dos requisitos e interações do cliente.
3.	Ele é criado por um analista de sistema ou um arquiteto de sistema ou um analista de negócios.	Ele é criado por um analista de negócios.
4.	Ele descreve as especificações técnicas e funcionais do software também em alto nível.	Ele descreve as especificações funcionais do software em um nível muito alto.
5.	Ele lida com os recursos que a empresa fornece.	Ele lida com os requisitos de negócios.
6.	Ele descreve como o negócio funciona ao usar o software ou aplicativo.	Define as necessidades do cliente. O documento é utilizado do início ao fim do projeto.
7.	Tabelas e casos de uso estão incluídos.	Tabelas e casos de uso não estão incluídos.

Componentes essenciais de um SRS

As principais seções de uma especificação de requisitos de software são:

Drivers de negócios – Os motivos pelos quais o cliente deseja construir um sistema são descritos nesta seção. Esta seção inclui ainda os problemas que o cliente está enfrentando com o sistema atual e as oportunidades que o novo sistema oferecerá.
Modelo de Negócios – O modelo de negócios que o sistema deve suportar é discutido nesta seção. Inclui ainda vários outros detalhes, como o contexto organizacional e de negócios, as principais funções de negócios e os diagramas de fluxo de processo do sistema.
Requisitos Funcionais e do Sistema – Esta seção geralmente detalha os requisitos organizados em uma estrutura hierárquica. Os requisitos funcionais estão no nível superior e os requisitos detalhados do sistema são listados como subitens.
Casos de uso do sistema – Esta seção consiste em um diagrama de casos de uso da Unified Modeling Language (UML) explicando todas as principais entidades externas que estarão interagindo com o sistema e os diferentes casos de uso que eles terão que executar.
Requerimentos técnicos – Esta seção discute todos os requisitos não funcionais que compõem o ambiente técnico e as limitações técnicas em que o software estará operando.
Qualidades do sistema – Nesta seção, as inúmeras qualidades do sistema são definidas, como confiabilidade, facilidade de manutenção, segurança, escalabilidade, disponibilidade e capacidade de manutenção.
Limitações e suposições – Todas as limitações impostas ao projeto do sistema do ponto de vista do cliente são descritas nesta seção. As várias suposições da equipe de engenharia sobre o que esperar durante o desenvolvimento também são discutidas aqui.
Critérios de Aceitação – Detalhes sobre todas as condições que devem ser atendidas antes que o sistema seja entregue aos clientes finais são discutidos nesta seção.

Estrutura de um SRS

1. Introdução -

A introdução explica o significado de SRS em geral, seu escopo para sua equipe e sua estrutura.

1.1. Propósito

Aqui, explique o objetivo e a estrutura da documentação do software SRS: os tipos de requisitos que serão abordados, bem como o pessoal que o utilizará.

Mantenha esta seção curta: 1-2 parágrafos são suficientes.

1.2. Audiência pretendida

Você pode se aprofundar e explicar como as partes interessadas e as equipes trabalharão com o SRS, além de participar de seu desenvolvimento. Normalmente, são proprietários de produtos, investidores, analistas de negócios, desenvolvedores, às vezes testadores e equipe de operações. Toda a estrutura é determinada pela sua abordagem de desenvolvimento de software e pela configuração organizacional da equipe.

1.3. Uso pretendido

Descreva em quais situações sua equipe usará o SRS. Normalmente, é usado nos seguintes casos:

projetar e fazer brainstorming de novos recursos
planejamento da duração do projeto, sprints, estimativa de custos
avaliando riscos
monitorar e medir o sucesso da equipe
situações conflitantes quando as partes envolvidas têm visões diferentes de um produto bem executado.

1.4. Escopo

Esta parte abrange o escopo do produto, portanto, você precisará fornecer uma visão geral rápida do sistema – seu objetivo principal, função e posição. É comparável a como você explicaria um produto em uma reunião de partes interessadas, exceto que é permitido se aprofundar em detalhes técnicos.

Esta seção deve descrever:

Espera-se que todos os tipos de usuários se envolvam com o sistema
Todas as partes essenciais da arquitetura

1.5 Definições e siglas

Ao longo de seu documento, a equipe frequentemente usa certas palavras. Eliminar qualquer mal-entendido em potencial, permitir que novos desenvolvedores participem e resolver situações conflitantes será mais fácil se você esclarecer o significado dessas palavras.

Os componentes acima mencionados constituem uma definição. As definições fornecem informações sobre a função, tecnologias subjacentes, personas alvo, entidades de negócios (usuários, clientes, intermediários) e partes interessadas. Você pode usar um acrônimo para escrever seu SRS mais rapidamente, se optar por fazê-lo. O documento será legível desde que a tabela de definições o inclua.

2. Descrição geral

Na segunda parte, você descreve os principais recursos do produto, os usuários-alvo e o escopo do sistema para os leitores. Esta descrição concentra-se apenas nos principais recursos e arquitetura de software sem entrar em detalhes sobre complementos e conexões.

2.1 Necessidades do Usuário

Essa parte é uma questão de escolha, portanto, algumas organizações optam por não incluí-la em sua documentação de engenharia do SRS. Acreditamos que é melhor listar os problemas que você deseja resolver com sua funcionalidade agora. Ele será útil mais tarde durante as funções de brainstorming e monitoramento. Você pode voltar a esta seção a qualquer momento durante o processo de desenvolvimento do produto e ver se a equipe de experiência do usuário não se desviou do caminho pretendido.

Necessidades referem-se a questões que os usuários poderão resolver com o sistema. Você pode dividir essas necessidades em subcategorias se lidar com um público altamente segmentado. Tente não entrar em detalhes sobre as necessidades de cada usuário. Você precisa deixar algum espaço para interpretação, apenas no caso de um problema se tornar mais significativo do que você pensava inicialmente.

2.2 Premissas e Dependências

Suposições são as suposições da equipe sobre o produto e suas capacidades que estarão corretas em 99% das situações. É natural supor, por exemplo, que uma plataforma que auxilia os motoristas na navegação noturna será utilizada principalmente no modo noturno.

Qual é o significado das suposições? Eles permitem que você se concentre primeiro nos recursos mais importantes do aplicativo. Essa suposição auxilia no entendimento de que os projetistas devem desenvolver uma interface adequada para visão no escuro para um assistente de direção noturna. Alguns usuários certamente podem abrir o aplicativo durante o dia, mas é um tiro no escuro, então você não precisa incluir elementos relacionados no protótipo imediatamente.

3. Recursos e Requisitos do Sistema

Esta parte cobre os recursos do produto e os critérios de execução em detalhes. Como as duas seções anteriores tratam do produto como um todo, você encontrará uma descrição mais abrangente aqui.

3.1 Requisitos Funcionais

são indicados em uma lista de funções que serão executadas em um sistema. Esses critérios estão preocupados com “o que será criado?” em vez de “como” e “quando”.

Os requisitos funcionais começam descrevendo a funcionalidade necessária com base em quão essencial ela é para o aplicativo. Se você quiser trabalhar nele primeiro, pode começar com o design, mas depois deve ir para o desenvolvimento. Os requisitos funcionais não entram em grandes detalhes sobre as pilhas de tecnologia, pois podem mudar à medida que o projeto avança. Em vez de se concentrar na lógica interna, os requisitos funcionais se concentram na funcionalidade do usuário final.

3.2 Requisitos da Interface Externa

Os requisitos funcionais são uma parte significativa de uma especificação de requisitos do sistema. Para cobrir todos os recursos necessários do sistema, você precisará de 4 a 5 páginas de informações. Algumas equipes os dividem por temas para facilitar a leitura do documento.

Normalmente, os componentes de design do SRS são referidos como separados do back-end e da lógica de negócios. Isso faz sentido, pois designers, e não desenvolvedores, lidam com a maior parte dessa área, mas também porque é onde o processo de desenvolvimento de produtos começará.

Dependendo do projeto, os requisitos de interface externa podem consistir em quatro tipos:

Interface com o usuário
Interface de software
Interface de hardware
Interface de comunicação

Os requisitos de interface externa descrevem os elementos da página que serão visíveis para o cliente final. Eles podem incluir a lista de páginas, elementos de design, principais temas estilísticos, até elementos artísticos e muito mais, se forem essenciais para o produto.

3.3 Requisitos do sistema

Os requisitos de sistema do produto indicam as condições sob as quais ele pode ser usado. Eles geralmente pertencem a especificações e recursos de hardware. Os requisitos de hardware do SRS são geralmente definidos por faixas mínimas e máximas, bem como um limite de desempenho ideal do produto.

Criar requisitos de sistema antes de começar a criar um produto pode parecer difícil, mas é essencial. Os desenvolvedores devem aderir aos requisitos de hardware para que não precisem reiniciar o projeto posteriormente. Aplicativos móveis (com muitas variáveis a serem consideradas) e aplicativos que precisam de alta reatividade (jogos, qualquer produto com VR/AR ou IoT) são particularmente vulneráveis.

3.4 Requisitos Não Funcionais

Para muitas organizações, essa parte de um SRS é a mais difícil. Se os requisitos funcionais tratam da questão do que criar, os padrões não funcionais definem como. Eles estabelecem os critérios de acordo com a eficácia com que o sistema deve operar. Os limites de desempenho, segurança e usabilidade estão incluídos nesta área.

O valor real é o que dificulta a definição de requisitos não funcionais. Definir frases como “simultaneidade” ou “portabilidade” é difícil, pois elas podem ter várias interpretações para todas as partes envolvidas. Como resultado, defendemos a atribuição de uma pontuação a cada requisito não funcional. Você pode rever os requisitos do projeto a qualquer momento para verificar se o sistema atual atende às expectativas iniciais.

Quais erros devem ser evitados ao elaborar uma especificação de requisitos do sistema?

À medida que suas habilidades no desenvolvimento de SRS aumentam, o processo se torna mais rápido. No entanto, quando você está apenas começando, é aconselhável ter uma lista de erros típicos à mão para referência. Para tanto, reflita sobre estes:

Negligenciar a incorporação de um glossário abrangente: Seu SRS contém um jargão com o qual apenas as pessoas do setor estão familiarizadas? Nesse caso, crie uma seção de dicionário simples de entender e inclua definições de quaisquer palavras ou expressões não amplamente conhecidas. Isso ajudará a garantir que todos os usuários possam entender o propósito e a terminologia do documento.
Gerando Desordem Combinando Idéias: Estruture seu documento de maneira ordenada e certifique-se de fornecer informações aos leitores em uma progressão lógica. Para evitar qualquer mal-entendido ou confusão, não confunda os conceitos ao longo do texto.
Ignorância das necessidades e desejos do público-alvo: Para compreender o resultado esperado do software, é importante discernir quem o utilizará, bem como quais resultados são esperados. Por exemplo, digamos que um aplicativo foi criado para a criação de relatórios. Alguns de seus requisitos devem incluir como os usuários podem pressionar determinados botões para obter diferentes documentos. Para entender verdadeiramente o que é exigido desse programa de geração de relatórios e também reconhecer quem o usará, você deve ter uma visão do usuário e de suas expectativas em relação à funcionalidade.
Ser ambíguo: Certifique-se de que suas necessidades sejam inequívocas. Um SRS é formulado para evitar mal-entendidos e, portanto, é vital garantir que o documento não crie confusão. Para cada descrição de recurso ou condição, certifique-se de não incluir funcionalidades que ainda não foram especificadas.

Melhores práticas para escrever documentos SRS

Escrever um documento de Especificação de Requisitos de Sistema (SRS) é um aspecto crucial do desenvolvimento de software, e aderir às melhores práticas pode melhorar significativamente a qualidade e a eficácia do documento. Aqui estão algumas práticas recomendadas para escrever documentos SRS:

Use linguagem clara e concisa:
- Evite jargões técnicos e siglas que possam não ser universalmente compreendidas. Use uma linguagem clara e direta, garantindo que todas as partes interessadas possam compreender facilmente o conteúdo.
Incluir recursos visuais:
- Melhore a compreensão incorporando diagramas, fluxogramas e modelos junto com descrições textuais dos requisitos. Os recursos visuais podem fornecer uma representação mais intuitiva de conceitos complexos e comportamentos do sistema.
Requisitos de Prioridade:
- Defina claramente a prioridade de cada requisito. Use rótulos como “obrigatório”, “deveria ter” e “bom ter” para indicar a importância relativa de diferentes recursos. A priorização ajuda a equipe de desenvolvimento a se concentrar primeiro nas funcionalidades críticas.
Mantenha-o atualizado:
- Mantenha o controle de versão do documento SRS. Atualize regularmente o documento para refletir quaisquer alterações nos requisitos do projeto, no escopo ou no feedback das partes interessadas. Mantenha um registro de alterações claro para rastrear as modificações ao longo do tempo.
Envolva as Partes Interessadas:
- Colaborar estreitamente com todas as partes interessadas relevantes ao longo do processo de desenvolvimento do SRS. Participe de discussões, obtenha feedback e garanta que suas necessidades e expectativas sejam capturadas com precisão no documento. Esse envolvimento promove uma compreensão compartilhada dos objetivos do projeto.
Seja abrangente:
- Não deixe espaço para interpretações ou suposições. Forneça descrições detalhadas e abrangentes de cada requisito, incluindo aspectos funcionais e não funcionais. A ambigüidade nos requisitos pode levar a mal-entendidos e atrasos no projeto.
Use um formato estruturado:
- Organize o documento SRS em seções bem definidas, como Introdução, Requisitos das Partes Interessadas, Arquitetura do Sistema, Requisitos Funcionais, Requisitos Não Funcionais, Restrições, Suposições, Dependências e uma Matriz de Rastreabilidade. Um formato estruturado facilita aos leitores a localização de informações específicas.
Garanta a testabilidade:
- Escreva requisitos de uma forma que facilite o teste e a validação. Cada requisito deve ser verificável, permitindo que os testadores criem casos de teste que validem se o sistema atende aos critérios especificados. Critérios de aceitação claros para cada requisito são essenciais.
Evite ambiguidade:
- Esteja atento para eliminar a ambigüidade nos requisitos. Use uma linguagem precisa, evite termos vagos e garanta que não haja espaço para múltiplas interpretações de um requisito. Ambiguidades podem levar a mal-entendidos e retrabalho do projeto.
Considere a escalabilidade futura:
- Pense na escalabilidade de longo prazo do sistema de software. Antecipe potenciais necessidades futuras e garanta que o documento SRS as acomode. Esta abordagem proativa pode economizar tempo e recursos no futuro.
Revise e valide:
- Conduza revisões completas do documento SRS com as partes interessadas, incluindo o cliente, a equipe de desenvolvimento e especialistas no assunto. Aborde quaisquer discrepâncias, inconsistências ou ambiguidades que surjam durante o processo de revisão. A validação garante que o documento represente com precisão os objetivos do projeto.
Obtenha aprovação formal:
- Após finalizar o documento SRS, obtenha a aprovação formal e a aprovação do cliente ou patrocinador do projeto. Isto formaliza o acordo sobre o escopo e os requisitos do projeto, fornecendo uma base clara para o desenvolvimento.

A incorporação dessas melhores práticas no processo de redação de documentos SRS pode contribuir para o sucesso dos projetos de desenvolvimento de software. Um documento SRS bem elaborado serve como um guia confiável tanto para a equipe de desenvolvimento quanto para as partes interessadas, ajudando a garantir que o sistema de software final esteja alinhado com as expectativas e requisitos.

Conclusão

Escrever um documento eficaz de Especificação de Requisitos de Sistema (SRS) é uma etapa crítica no processo de desenvolvimento de software. Ele serve como base para planejamento, desenvolvimento, teste e validação de projetos bem-sucedidos. Seguindo as etapas descritas neste artigo e aderindo às práticas recomendadas, você pode criar documentos SRS que servem como um guia confiável para a construção de sistemas de software que atendam às necessidades e expectativas das partes interessadas.

Não se esqueça de compartilhar esta postagem!