ANÁLISE DE REQUISITOS

Para que uma implementação seja bem especificada é necessário que em todas as etapas do
processo sejam respondidas e consideradas.

Consiste em observar uma tarefa/atividade/processo durante o seu desenrolar.

Responder as seguintes perguntas:

1. Qual o objetivo daquele trabalho?

2. O que é feito?

3. Por quem?

4. Com que recursos?

5. Como faz?

6. Quando (o que inicia a atividade)?

7. Quem solicita?

8. Quais são as entradas?

9. Quais são as saídas?

Já para o Storyboards que são organizadores gráficos tais como uma série de ilustrações ou imagens
arranjadas em sequência, com o propósito de pré-visualizar um filme, animação ou gráfico animado,
incluindo elementos interativos.

• Visualmente conta e mostra:

- Quem/o que são os atores

- O que acontece com eles

- Quando isso acontece

Os Storyboards são como rascunhos de estórias em quadrinhos, muito utilizados no cinema, quando
o diretor deseja mostrar a todos a sequência detalhada de uma cena. Em desenvolvimento, são os
chamados “protótipos de papel”, com rascunhos do comportamento do sistema passo a passo.

O que não pode faltar em uma Storyboard são:

Requisitos Funcionais (RF):

• RF1 - Processamento de Pagamentos:

- Descrição: O sistema deve permitir que os clientes processem pagamentos de compras online. Os
clientes podem escolher entre cartões de crédito ou PayPal como métodos de pagamento.

- Entrada: Detalhes do pedido, incluindo itens selecionados, informações de cartão de crédito ou

conta do PayPal.
- Processamento: O sistema deve verificar a disponibilidade de estoque dos itens, calcular o total da
compra, processar o pagamento e atualizar o status do pedido. Para pagamentos com cartão de
crédito, é necessário validar os dados do cartão.

- Saída: Confirmação do pedido e recibo de pagamento.

• RF2 - Avaliação de Produtos:

- Descrição: Os usuários registrados podem avaliar os produtos no sistema, atribuindo uma

classificação e deixando comentários. As avaliações podem ser vistas por outros usuários.

- Entrada: Nome de usuário, produto avaliado, classificação (1 a 5 estrelas) e comentário (opcional).

- Processamento: O sistema deve verificar se o usuário está autenticado, aceitar a avaliação e o

comentário, atualizar a média de classificação do produto e disponibilizar as avaliações para outros
usuários visualizarem.

- Saída: A avaliação e o comentário são exibidos na página do produto.

Requisitos Não-Funcionais (RNF):

• RNF1 - Desempenho de Consultas de Banco de Dados:

- Descrição: O sistema deve ser capaz de executar consultas de banco de dados complexas em menos
de 1 segundo, mesmo quando houver um grande volume de dados.

- Critério: Tempo de resposta das consultas de banco de dados.

- Requisito: As consultas devem ser otimizadas, e o sistema deve ser dimensionado para lidar com
cargas de trabalho elevadas.

• RNF2 - Segurança de Dados:

- Descrição: O sistema deve garantir que todos os dados confidenciais dos clientes sejam
armazenados e transmitidos de forma segura. Deve cumprir os padrões de segurança da indústria.

- Critério: Conformidade com regulamentações de segurança da indústria (por exemplo, GDPR,

HIPAA) e ausência de violações de dados.

- Requisito: Implementação de criptografia para dados em repouso e em trânsito, controle de acesso

rigoroso e auditorias de segurança regulares.

Regras de Negócio (RN):

• RN1 - Descontos por Volume de Compra:

- Descrição: Os clientes que comprarem mais de 10 unidades de um produto receberão um desconto
de 5% no valor total da compra.

- Regra: Se a quantidade de um produto no carrinho de compras for maior ou igual a 10 unidades,

aplique automaticamente um desconto de 5% ao valor total da compra.

• RN2 - Limite de Crédito para Clientes Empresariais:

- Descrição: Clientes empresariais têm um limite de crédito mensal de R$ 10.000,00. Eles não podem
fazer pedidos que excedam esse valor a menos que obtenham aprovação do departamento
financeiro.

- Regra: Ao fazer um pedido, verifique se o cliente é uma conta empresarial e se o valor total do
pedido não excede o limite de crédito mensal. Se exceder, solicite aprovação do departamento
financeiro antes de concluir o pedido.

Quais as qualidades de um Requisito?

Correto: É uma declaração de algo que o sistema deve fazer.

Existem diversos tipos (classes de requisitos.

Completo: Descrever todas as informações significativas para o usuário.

Consistente: Não conflitantes com outros requisitos.

Não-ambíguo: Permitem uma e somente uma interpretação.

Verificável: Pode ser testado eficientemente.

Ranqueados por importância e estabilidade: Pode ser ordenado com base na importância que têm
para o cliente e na estabilidade.

Modificável: Mudanças não afetam a estrutura e estilo do conjunto.

Rastreável: A Origem de cada requisito pode ser encontrada.

Compreensível: Compreendidos por usuários e desenvolvedores.

Quais são os Tipos de Requisitos?

Existem diversos tipos (classes de requisitos).

Normalmente existem alguns tipos mais utilizados que são:

• Requisitos de Negócio

• Requisitos de Sistema
 - Funcionais

- Não Funcionais (qualidade e restrições)

◦ Detalhamento de funcionalidade

◦ Confiabilidade

◦ Usabilidade

◦ Eficiência

◦ Manutebilidade

◦ Portabilidade

• Requisitos de Transição

• Requisitos de Informação

• Requisitos Operacionais e Técnicos

• Requisitos de Produção

• Requisitos de Treinamento

• Requisitos Inversos

• Requisitos de Pessoas

• Requisitos Não Técnicos

De acordo com a IEEE830 tem que se considerar em todos os requisitos os seguintes itens:
Usualmente as empresas de tecnologia geram os artefatos sendo eles:

-Requisitos de Negócios

-Requisitos Técnicos

Sendo Requisitos de Negócios contendo todas as Funcionalidades (RFs) Requisitos Funcionais e

(RNFs) Requisitos Não Funcionais, as regras de negócios (RNs), o StoryBoard, os critérios de aceite, e
fluxo a ser testando sendo o fluxo principal e o alternativo com pelo menos três (03) exemplos de
cada um utilizando a técnica do BDD (Behaviour Driven Development), bem como mencionar os
ambientes que deveram ser testados, por exemplo:

-Web

-API

-Banco de Dados

-Aplicações

-Caminhos

Observação: A criticidade do software a ser testado e pontos de atenção.

Sendo o documento de Requisitos Técnicos que deverá conter informações específicas e

discriminadas sobre os aspectos técnicos de um projeto ou sistema.

Alguns elementos que geralmente compõem um requisito técnico são:

-Descrição do requisito

-Especificação detalhada de um componente, funcionalidade, sistema ou processo necessário para

atender aos objetivos do requisito de um projeto de desenvolvimento.

-Os requisitos técnicos descreverem como as características, comportamentos, restrições e padrões

necessários para a implementação com sucesso a solução tecnológica.

-Descritivo de impacto em correlação com a melhoria a ser implementada ou alterada entre

ambientes diferentes.

Exemplo: A implementação será realizada no módulo Relatórios, onde o Relatório XML A550 tem os
mesmos campos do AXXX que é apresentada nos módulos XPTO, a regra não deverá impactar nos
campos do AXXX não tendo impacto nos módulos XPTO.

O objetivo da norma IEEE 830, intitulada "IEEE Std 830-1998 IEEE Recommended Practice for
Software Requirements Specifications," é fornecer diretrizes e práticas recomendadas para a criação
de Especificações de Requisitos de Software (SRS) em projetos de desenvolvimento de software. A
SRS é um documento crucial que descreve de forma detalhada os requisitos do software que está
sendo desenvolvido. Os principais objetivos da norma IEEE 830 são:

1. Clareza e Compreensão: A norma visa garantir que os requisitos do software sejam documentados
de maneira clara e compreensível. Isso ajuda a evitar ambiguidades e interpretações errôneas,
tornando mais fácil para todas as partes envolvidas no projeto entenderem os requisitos.

Exemplo de SRS Deficiente:

Requisito: "O sistema deve ser rápido."

Problema: A definição de "rápido" é vaga e subjetiva, deixando espaço para interpretações

diferentes. O que é considerado "rápido" para uma pessoa pode não ser o mesmo para outra.

Exemplo de SRS com a Norma Implementada:

Requisito: "O sistema deve ser capaz de processar 100 transações por segundo com um tempo de
resposta médio de menos de 1 segundo."

Melhoria: Esse requisito é claro e específico, definindo quantitativamente o desempenho esperado

do sistema.

2. Consistência: A norma estabelece um formato padronizado para a documentação de requisitos,

garantindo que todos os documentos SRS sigam uma estrutura comum. Isso facilita a consistência na
documentação e a comparação entre diferentes projetos.

Exemplo de SRS Deficiente:

Requisito 1: "O sistema deve ser compatível com dispositivos móveis."

Requisito 2: "O sistema deve ser otimizado para desktops."

Problema: Os requisitos são inconsistentes, já que um requer compatibilidade com dispositivos

móveis, enquanto o outro requer otimização para desktops.

Exemplo de SRS com a Norma Implementada:

Requisito 1: "O sistema deve ser compatível com dispositivos móveis e desktops."

Melhoria: Os requisitos são consistentes e abordam ambos os casos.

3. Rastreabilidade: A norma incentiva a rastreabilidade de requisitos, ou seja, a capacidade de

rastrear e verificar como cada requisito se relaciona com outros requisitos e com os objetivos do
sistema. Isso ajuda na gestão de mudanças e na garantia de que todos os requisitos sejam atendidos.

Exemplo de SRS Deficiente:

Requisito: "O sistema deve ter uma funcionalidade de login."

Problema: Não está claro por que a funcionalidade de login é necessária ou como ela se relaciona
com os objetivos gerais do sistema.

Exemplo de SRS com a Norma Implementada:

Requisito: "O sistema deve ter uma funcionalidade de login para autenticar os usuários e garantir a
segurança das informações."

Melhoria: O requisito é rastreável porque explica a finalidade da funcionalidade de login e como ela
se relaciona com a segurança do sistema.

4. Comunicação Eficiente: A norma ajuda a melhorar a comunicação entre as partes interessadas,

incluindo desenvolvedores, clientes, gerentes de projeto e testadores. Ao seguir as diretrizes da IEEE
830, a documentação de requisitos se torna uma ferramenta eficaz para garantir que todos
compartilhem uma compreensão comum do que o software deve fazer.

Exemplo de SRS Deficiente:

Requisito: "O sistema deve ser fácil de usar."

Problema: "Fácil de usar" é subjetivo e não fornece orientação suficiente para os desenvolvedores
entenderem o que é necessário.

Exemplo de SRS com a Norma Implementada:

Requisito: "O sistema deve incluir uma interface de usuário intuitiva, com menus de navegação
claros e botões de ação facilmente identificáveis."

Melhoria: Esse requisito fornece detalhes específicos sobre o que torna o sistema fácil de usar.

5. Base para o Desenvolvimento: A SRS serve como uma base sólida para o desenvolvimento de
software. Ela fornece aos desenvolvedores as informações necessárias para criar o software de
acordo com os requisitos especificados.

Exemplo de SRS Deficiente:

Requisito: "O sistema deve fazer o que os usuários querem."

Problema: Esse requisito é vago e não fornece orientação clara para os desenvolvedores.

Exemplo de SRS com a Norma Implementada:

Requisito: "O sistema deve permitir que os usuários criem perfis de usuário, façam login, visualizem
e editem informações pessoais e compartilhem conteúdo com outros usuários."
Melhoria: Esse requisito fornece uma base sólida para o desenvolvimento, descrevendo as
funcionalidades específicas que o sistema deve ter.

6. Auditoria e Verificação: A norma ajuda na realização de auditorias e verificações dos requisitos do

software. Os documentos SRS podem ser usados como referência para garantir que o software
entregue atenda a todos os requisitos estabelecidos.

Exemplo de SRS Deficiente:

Não há exemplo específico de SRS deficiente para esse item, mas um SRS que não segue as diretrizes
da norma IEEE 830 torna a auditoria e verificação mais difíceis, pois a documentação pode ser
imprecisa, inconsistente e incompleta.

Exemplo de SRS com a Norma Implementada:

Requisito: "A cada duas semanas, uma revisão de requisitos será realizada para verificar a
conformidade do software em desenvolvimento com os requisitos especificados."

Melhoria: Isso estabelece um processo claro para auditoria e verificação regular dos requisitos e do
progresso do desenvolvimento.