Análise de requisitos de software com exemplo
Carlos Moore
⚡ Resumo Inteligente
A análise de requisitos de software divide as necessidades das partes interessadas em declarações funcionais e não funcionais, classifica-as nos níveis de negócios, arquitetura e sistema e, em seguida, verifica cada uma em relação aos atributos de qualidade para garantir um produto testável. tracEspecificação viável e priorizada.
Um requisito de software é uma necessidade funcional ou não funcional que deve ser implementada no sistema. Funcional significa fornecer um serviço específico ao usuário.
Por exemplo, no contexto de um aplicativo bancário, o requisito funcional é que, quando um cliente seleciona "Ver saldo", ele deve ser capaz de visualizar o saldo mais recente de sua conta.
Um requisito de software também pode ser não funcional, como um requisito de desempenho. Por exemplo, um requisito não funcional pode estipular que todas as páginas do sistema devem carregar para os usuários em até 5 segundos.
Então, basicamente requisito de software é um
- Funcional ou
- Não funcional
necessidade que deve ser implementado no sistema. Os requisitos de software geralmente são expressos como declarações.
Tipos de Requisitos
Requisitos de negóciosEsses são requisitos de alto nível extraídos do estudo de viabilidade do projeto. Por exemplo, um sistema de serviços bancários móveis oferece serviços bancários no Sudeste Asiático. O requisito de negócio definido para a Índia é o extrato da conta e a transferência de fundos, enquanto para a China é o extrato da conta e o pagamento de contas.
| País | Empresa que fornece funcionalidades ou serviços bancários |
|---|---|
| India | Resumo da conta e transferência de fundos |
| China | Resumo da conta e Bill Pagamento |
Archirequisitos de arquitetura e designEsses requisitos são mais detalhados do que os requisitos de negócio e orientam a arquitetura da solução. Eles determinam o projeto geral necessário para implementar o requisito de negócio. Para uma organização educacional, os casos de uso típicos de arquitetura e design incluem login, detalhes do curso e matrícula. O requisito seria como mostrado abaixo.
| Caso de uso bancário | Exigência |
|---|---|
| Bill Pagamento | Este caso de uso descreve como um cliente pode fazer login no net banking e usar o Bill Facilidade de Pagamento. O cliente pode visualizar um painel com as faturas em aberto dos fornecedores cadastrados. O cliente pode adicionar, modificar e excluir os dados de um fornecedor. O cliente pode configurar alertas por SMS e e-mail para diferentes ações de cobrança. O cliente pode visualizar o histórico de faturas pagas. Os usuários que iniciam este caso de uso são clientes do banco ou funcionários do suporte. |
Requisitos de sistema e integraçãoNo nível mais básico, temos os requisitos de sistema e de integração. Eles fornecem uma descrição detalhada de cada requisito e podem ser representados como histórias de usuário escritas em linguagem empresarial cotidiana. Os requisitos contêm detalhes suficientes para que os desenvolvedores possam começar a codificar. Bill O exemplo do módulo de pagamento abaixo demonstra a necessidade de adicionar um emissor de fatura.
| Bill Pagamento | Requisitos |
|---|---|
| Adicione Billers | Nome da concessionária de serviços públicos, número de relacionamento com o cliente, número de telefone, pagamentos automáticos – Sim/Não, pagar o valor total. Bill – Sim/Não, Limite de Pagamento Automático – Não pagar se Bill está acima do valor especificado |
Às vezes, você pode não receber nenhum requisito ou documento para trabalhar em um projeto. Mesmo assim, existem outras fontes de informação sobre os requisitos que você pode utilizar para fundamentar o projeto do seu software ou dos seus testes. Essas outras fontes de requisitos estão listadas abaixo.
Outras fontes de requisitos
- Transferência de conhecimento de colegas ou funcionários que já trabalham naquele projeto
- Discuta o projeto com o analista de negócios, o gerente de produto, o líder do projeto e os desenvolvedores.
- Analise a versão anterior do sistema já implementada.
- Analisar documentos de requisitos antigos do projeto
- RevVeja os relatórios de erros anteriores; alguns relatórios de erros são convertidos em solicitações de melhoria que podem ser implementadas na versão atual.
- Consulte o guia de instalação, se disponível, para verificar quais instalações são necessárias.
- Analise o conhecimento do domínio ou da indústria que a equipe está tentando implementar.
Independentemente da fonte de requisitos que você utilizar, documente-os em um formato compartilhado e peça que sejam revisados por membros experientes da equipe.
Como analisar requisitos
Considere o exemplo de um sistema de software educacional onde um aluno pode se inscrever em diferentes cursos.
Vamos estudar como analisar os requisitos. Cada requisito deve manter um conjunto de atributos de qualidade padrão, que incluem o seguinte:
- Atomic
- Identificado exclusivamente
- Automação
- Consistente e inequívoco
- Traccomestível
- Priorizado
- Testável
A tabela a seguir ilustra cada atributo com três colunas:
- A primeira coluna indica- “qualidade do requisito”
- A segunda coluna indica- “requisito ruim com algum problema”
- A terceira coluna mostra o mesmo requisito "convertido em um bom requisito".
| Qualidade do Requisito | Exemplo de requisito ruim | Exemplo de bom requisito |
|---|---|---|
| Atomic | Alunos poderão se inscrever em cursos de graduação e pós-graduação | Os alunos poderão se matricular em cursos de graduação. Os alunos poderão se matricular em cursos de pós-graduação. |
| Identificado exclusivamente | 1- Os alunos poderão se matricular em cursos de graduação. 1- Os alunos poderão se matricular em cursos de pós-graduação. | Matrícula em disciplinas. Os alunos poderão se matricular em disciplinas de graduação. Os alunos poderão se matricular em disciplinas de pós-graduação. |
| Automação | Um usuário professor fará login no sistema fornecendo seu nome de usuário, senha e outras informações relevantes | Um usuário professor fará login no sistema fornecendo seu nome de usuário, senha e código do departamento |
| Consistente e inequívoco | Um aluno terá cursos de graduação ou cursos de pós-graduação, mas não ambos. Alguns cursos serão abertos tanto para graduação quanto para pós-graduação | Um aluno terá graduação ou pós-graduação, mas não ambos |
| Traccomestível | Manter as informações dos alunos mapeadas para o BRD req.ID? | Manter as informações do aluno mapeadas para o BRD req ID 4.1 |
| Priorizado | Aluno matriculado - Prioridade 1. Manter informações do usuário - Prioridade 1. Matricular-se em disciplinas - Prioridade 1. Visualizar boletim - Prioridade 1 | Cadastrar aluno - Prioridade 1. Manter informações do usuário - Prioridade 2. Matricular-se em disciplinas - Prioridade 1. Visualizar boletim - Prioridade 3. |
| Testável | Cada página do sistema será carregada em um prazo aceitável | As páginas de registro de aluno e inscrição em cursos do sistema serão carregadas em 5 segundos |
Vamos entender cada um desses atributos com mais detalhes, começando por Atomeu.
Atomic
Todo requisito deve ser atômico, ou seja, deve estar no nível mais baixo de detalhe e não pode ser dividido em componentes menores. Os exemplos a seguir comparam requisitos atômicos e não atômicos.
Continuando com o exemplo do sistema no domínio da educação: aqui, o requisito inadequado é "Os alunos poderão se matricular em cursos de graduação e pós-graduação". Este é um requisito inadequado porque não é atômico — mistura duas entidades diferentes, cursos de graduação e pós-graduação. O requisito adequado correspondente o separa em dois requisitos. Um requisito abrange a matrícula em cursos de graduação e o outro abrange a matrícula em cursos de pós-graduação.
Identificado Exclusivamente
O próximo atributo de qualidade é a identificação única. No exemplo ruim, dois requisitos distintos compartilham o mesmo ID#1. Se uma equipe referencia um requisito pelo seu ID, fica difícil saber a qual dos dois se refere. O requisito correto os reagrupa na Seção 1 — Matrícula em Cursos, com os sub-requisitos 1.1 (matrícula em cursos de graduação) e 1.2 (matrícula em cursos de pós-graduação).
Automação
Cada requisito deve ser completo. Por exemplo, neste caso, o requisito inadequado afirma que "um professor fará login no sistema fornecendo seu nome de usuário, senha e outras informações relevantes". A expressão "outras informações relevantes" é vaga. Um requisito completo lista os campos exatos, como o código do departamento, que o professor deve fornecer.
Consistente e inequívoco
Todos os requisitos devem ser consistentes e inequívocos. No exemplo inadequado, um requisito afirma: "O aluno cursará disciplinas de graduação ou de pós-graduação, mas não ambas", enquanto outro afirma: "Algumas disciplinas serão abertas tanto para alunos de graduação quanto de pós-graduação".
O primeiro requisito implica que os cursos sejam divididos em duas categorias exclusivas, mas o segundo requisito o contradiz ao abrir alguns cursos para ambos os grupos.
O requisito de qualidade resolve o conflito ao afirmar claramente que cada disciplina é classificada como de graduação ou pós-graduação, e que o aluno só pode se matricular em disciplinas de uma única categoria.
Traccomestível
Todos os requisitos devem ser tracIsso é possível porque os requisitos existem em vários níveis: negócios, arquitetura e design, e sistema e integração.
Ao converter um requisito de negócio em requisitos arquitetônicos e de design, ou requisitos arquitetônicos e de design em requisitos de sistema e integração, tracA funcionalidade deve ser preservada. Cada requisito de negócio deve corresponder a um ou mais requisitos de arquitetura e design. No exemplo inadequado "Manter informações do aluno – mapeado para o ID do requisito BRD?", o ID do requisito está ausente.
O requisito correto registra a mesma declaração, mas mapeia explicitamente para o requisito BRD ID 4.1. Todo requisito deve conter um tracmapa de capacidadepingOs requisitos de sistema e de integração também devem ser mapeados para o código que os implementa e para os casos de teste que os verificam.
TracA capacidade, portanto, permeia todo o projeto, de ponta a ponta.
Priorizado
Cada requisito deve ser priorizado para que a equipe saiba o que implementar primeiro e o que pode esperar. No exemplo ruim, Cadastrar Aluno, Manter Informações do Usuário, Matricular-se em Cursos e Visualizar Boletim estão todos definidos com Prioridade 1. Nem tudo pode ter Prioridade 1, portanto, os requisitos devem ser classificados de forma realista. O exemplo bom atribui a Prioridade 1 a Cadastrar Aluno e Matricular-se em Cursos, a Prioridade 2 a Manter Informações do Usuário e a Prioridade 3 a Visualizar Boletim.
Testável
Todo requisito deve ser testável. O mau exemplo, "cada página do sistema carregará em um tempo aceitável", não é testável por dois motivos. Primeiro, "cada página" pode significar dezenas de páginas, o que aumenta exponencialmente o esforço de teste. Segundo, "tempo aceitável" não está definido — aceitável para quem e em relação a qual parâmetro? O requisito correto resolve ambos os problemas nomeando as páginas específicas ("páginas de cadastro de alunos e de matrícula em cursos") e definindo uma meta mensurável de 5 segundos.
