Análise de requisitos de software com exemplo

Requisito de software é uma necessidade funcional ou não funcional a ser implementada no sistema. Funcional significa fornecer um serviço específico ao usuário.

Por exemplo, no contexto de uma aplicação bancária, o requisito funcional será quando o cliente selecionar “Ver Saldo” e deverá ser capaz de consultar o saldo mais recente da sua conta.

O requisito de software também pode ser não funcional, pode ser um requisito de desempenho. Por exemplo, um requisito não funcional é que cada página do sistema esteja visível para os usuários em 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 são geralmente expressos como declarações.

 

Tipos de Requisitos

  1. Requisitos de negócios: São requisitos de alto nível retirados do caso de negócios dos projetos.Por exemplo, um sistema de serviços bancários móveis fornece serviços bancários para o Sudeste Asiático. O requisito comercial decidido para a Índia é o resumo da conta e a transferência de fundos, enquanto para a China o resumo da conta e bill o pagamento é decidido como uma exigência comercial
País Empresa que fornece funcionalidades ou serviços bancários
Índia Resumo da conta e transferência de fundos
China Resumo da conta e Bill Pagamento
  1. Archirequisitos de arquitetura e design: esses requisitos são mais detalhados que os requisitos de negócios. Ele determina o design geral necessário para implementar os requisitos de negócios. Para nossa organização educacional, o archios casos de uso de arquitetura e design seriam login, detalhes do curso, etc. O requisito seria 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 poderá ver um painel de pendentes bills de registrado biller. Ele pode adicionar, modificar e excluir um biller detalhe. O cliente pode configurar SMS, email alertas para diferentes billações. Ele pode ver o histórico de pagamentos anteriores bills.

Os atores que iniciam este caso de uso são clientes bancários ou pessoal de suporte.

  1. Requisitos de sistema e integração: No nível mais baixo, temos requisitos de sistema e integração. É uma descrição detalhada de cada requisito. Pode ser na forma de histórias de usuários que realmente descrevem a linguagem comercial cotidiana. Os requisitos são abundantestails para que os desenvolvedores possam começar a codificar. Aqui, no exemplo de Bill Módulo de pagamento onde será mencionado o requisito para adicionar um Biller
Bill Pagamento Requisitos
Adicionar Billers
  • Nome do provedor de serviços públicos
  • Número do Cliente de Relacionamento
  • Pagamentos automáticos – Sim/Não
  • Pague integralmente Bill - Sim não
  • Limite de pagamento automático – Não pague se Bill está acima do valor especificado

Às vezes, para algum projeto, você pode não receber nenhum requisito ou documento para trabalhar. Mas ainda existem outras fontes de requisitos que você pode considerar para os requisitos ou informações, para que você possa basear seu software ou projeto de teste nesses requisitos. Portanto, as outras fontes de requisitos nas quais você pode confiar são

Outras fontes de requisitos

  • Transferência de conhecimento de colegas ou funcionários que já trabalham naquele projeto
  • Fale sobre o projeto para analista de negócios, gerente de produto, líder de projeto e desenvolvedores
  • Analise a versão anterior do sistema que já está implementada no sistema
  • Analise o documento de requisitos mais antigo do projeto
  • Olhe para os relatórios de bugs anteriores, alguns dos relatórios de bugs são transformados em solicitações de melhorias que podem ser implementadas na versão atual
  • Consulte o guia de instalação, se estiver disponível, para ver quais são as instalações necessárias
  • Analise o domínio ou conhecimento do setor que a equipe está tentando implementar

Qualquer que seja a fonte de requisitos que você obtiver, certifique-se de documentá-los de alguma forma e faça com que sejam revisados ​​por outros membros da equipe experientes e conhecedores.

Como analisar requisitos

Considere um exemplo de sistema de software educacional onde um aluno pode se inscrever em diferentes cursos.

Vamos estudar como analisar os requisitos. Os requisitos devem manter uma qualidade padrão de seus requisitos, diferentes tipos de qualidade de requisitos incluem

  • Atomic
  • Identificado exclusivamente
  • Preencha
  • Consistente e inequívoco
  • Rastreável
  • Priorizado
  • Testável

Analisar Requisitos

Vamos entender isso com um exemplo, existem três colunas na tabela mostrada aqui,

  1. A primeira coluna indica- “qualidade do requisito”
  2. A segunda coluna indica- “requisito ruim com algum problema”
  3. A terceira coluna é igual à segunda coluna, mas – “convertida 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
  • Alunos poderão se matricular em cursos de graduação
  • Alunos poderão se inscrever em cursos de pós-graduação
Identificado exclusivamente 1- Os alunos poderão matricular-se em cursos de graduação1- Os alunos poderão matricular-se em cursos de pós-graduação
  1. Inscrição no curso
  2. Alunos poderão se matricular em cursos de graduação
  3. Alunos poderão se inscrever em cursos de pós-graduação
Preencha 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
Rastreá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 registrado - Prioridade 1 Manter informações do usuário - Prioridade 1 Inscrever-se em cursos - Prioridade 1 Visualizar boletim escolar - Prioridade 1 Registrar aluno-Prioridade 1Manter informações do usuário-Prioridade 2Inscrever-se em cursos-Prioridade 1Ver Boletim-Prioridade3
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


Agora vamos entender cada um desses requisitos no details começando com Atomeu.

Atomic

Atomic

Portanto, todo e qualquer requisito que você tenha deve ser atomic, o que significa que deve estar em um nível muito baixo details não deveria ser possível separá-los em componentes. Aqui veremos os dois exemplos de requisitos, em Atomníveis de requisitos específicos e identificados exclusivamente.

Então, vamos continuar com o exemplo de construção de sistema para o domínio educacional. Aqui, a má exigência é “Os alunos poderão matricular-se em cursos de graduação e pós-graduação”. Este é um requisito ruim porque não é atomic porque trata de duas entidades distintas: cursos de graduação e pós-graduação. Então, obviamente, não é um bom requisito, mas um requisito ruim; portanto, um bom requisito de correspondência seria separá-lo em dois requisitos. Então um fala da matrícula em cursos de graduação enquanto o outro fala da matrícula em cursos de pós-graduação.

Identificado Exclusivamente

Identificado Exclusivamente

Da mesma forma, o próximo requisito de qualidade é verificar se há identificação exclusiva. Aqui temos dois requisitos separados, mas ambos têm o mesmo ID nº 1. Portanto, se estamos nos referindo ao nosso requisito com referência ao ID#, mas não está claro a qual requisito exato estamos nos referindo ao documento ou outra parte do sistema, pois ambos têm o mesmo ID#1. Então separando com id's únicos, então um bom requisito será o retorno conforme seção 1- matrículas em cursos, e tem dois requisitos 1.1 id é matrícula em cursos de graduação enquanto 1.2 id é matrícula em cursos de pós-graduação.

Preencha

Preencha

Além disso, todo e qualquer requisito deve ser preenchido. Por exemplo, aqui o requisito ruim diz que “o usuário professor fará login no sistema fornecendo seu nome de usuário, senha e outras informações relevantes”. Aqui, as outras informações relevantes não são claras, portanto, as outras informações relevantes devem ser explicitadas em boas condições para tornar o requisito completo.

Consistente e inequívoco

Consistente e inequívoco

Em seguida, todo e qualquer requisito deve ser consistente e inequívoco, então aqui, por exemplo, temos os requisitos “Um aluno terá cursos de graduação ou cursos de pós-graduação, mas não ambos” este é um requisito, há algum outro requisito que diz “Alguns cursos terão estar aberto tanto a estudantes de graduação quanto de pós-graduação”.

O problema deste requisito é que desde o primeiro requisito parece que os cursos estão divididos em duas categorias: cursos de graduação e cursos de pós-graduação e o aluno pode optar por um dos dois, mas não por ambos. Mas quando você lê outro requisito ele entra em conflito com o primeiro requisito e diz que alguns cursos serão abertos tanto para pós-graduação quanto para graduação.

Portanto, é óbvio converter este requisito ruim em um requisito bom, que é “Um aluno terá cursos de graduação ou cursos de pós-graduação, mas não ambos”. O que significa que cada curso será marcado como curso de graduação ou curso de pós-graduação

Rastreável

Rastreável

Todo e qualquer requisito deve ser rastreável porque já existem diferentes níveis de requisito, já vimos que no topo tínhamos requisitos de negócio, e depois temos um archirequisitos de arquitetura e design seguidos por requisitos de integração de sistema.

Agora, quando convertemos os requisitos de negócios em archirequisitos de arquitetura e design ou convertemos archiDos requisitos estruturais e de design aos requisitos de integração do sistema, deve haver rastreabilidade. O que significa que devemos ser capazes de pegar todos os requisitos de negócios e mapeá-los para um ou mais requisitos de software correspondentes. archiexigência de arquitetura e design. Então, aqui está um exemplo de requisito incorreto que diz “Manter as informações do aluno – mapeadas para o ID de solicitação do BRD?” o ID do requisito não é fornecido aqui.

Portanto, convertendo-o em um bom requisito, ele diz a mesma coisa, mas é mapeado com o ID do requisito 4.1. Portanto, o mapeamento deve estar presente para cada requisito. Da mesma forma que temos requisitos de mapeamento de alto e baixo nível, o mapeamento também existe entre o sistema e o requisito de integração para o código que implementa esse requisito e também há um mapeamento entre o sistema e o requisito de integração para o caso de teste que testa esse requisito específico .

Portanto, essa rastreabilidade abrange todo o projeto

Priorizado

Priorizado Aluno registrado - Prioridade 1
Manter informações do usuário - prioridade 1
Inscrever-se em cursos - Prioridade 1
Ver Boletim - Prioridade 1
Registrar Aluno-Prioridade 1
Manter informações do usuário - prioridade 2
Inscrever-se em cursos - Prioridade 1
Ver Boletim-Prioridade3

Então, todo e qualquer requisito deve ser priorizado, para que a equipe tenha uma orientação sobre qual requisito pode ser implementado primeiro e qual pode ser feito later sobre. Aqui você pode ver que a prioridade ruim é registrar aluno, manter as informações do usuário e cada requisito deu prioridade-1. Tudo não pode ter a mesma prioridade, então os requisitos podem ser priorizados. Portanto, o exemplo de um bom requisito aqui é registrar o aluno e inscrever os cursos com a prioridade mais alta 1, enquanto manter as informações do usuário vem abaixo na prioridade 2 e, em seguida, temos o boletim escolar na prioridade 3

Testável

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

Todo e qualquer requisito deve ser testável, aqui o requisito ruim é “cada página do sistema será carregada em um período de tempo aceitável”. Agora, há dois problemas com esse requisito: primeiro, cada página significa que pode haver muitas páginas, o que vai atrapalhar os esforços de teste. O outro problema é que diz que a página vai carregar em um prazo aceitável, agora qual é o prazo aceitável? Aceitável para quem. Portanto, temos que converter o argumento não testável em um argumento testável, que informa especificamente sobre qual página estamos falando “páginas de registro de alunos e matrícula em cursos” e também é fornecido o prazo aceitável que é de 5 segundos.

Conclusão

Portanto, é assim que devemos analisar cada requisito no nível apropriado. Por exemplo, se vamos construir um software no que diz respeito aos requisitos de sistema e integração. Temos que examinar os requisitos de sistema e integração fornecidos nas especificações de requisitos de software ou nas histórias de usuários e aplicar a qualidade de cada requisito. Em seguida, verifique se cada requisito está atomic, identificado exclusivamente e completo e assim por diante.