Engenharia de Software - Parte III - Requisitos

É a capacidade do sistema ou descrição de algo que o sistema é capaz de realizar, para resolver um problema ou atingir um objetivo do usuário. São descritos em diferentes níveis de abstração.

  • Requisito não funcional: relacionado com o meio, confiabilidade, implícito, funcionalidades secundárias do sistema.
  • Requisitos funcionais: descreve funcionalidades que o sistema deverá ter.
3. Cite alguns problemas encontrados no processo de identificação de requisitos
Problemas na identificação de requisitos:
  • Falta de clareza;
  • Comunicação falha;
  • Erros de análise;
  • Descrição do requisito, ambiguidades;

Análise de Requisitos
  • Entender os requisitos específicos que precisam ser satisfeitos para construir software de alta qualidade.
  • Como se faz: requisitos de dados, funcionais e comportamentais são identificadas pela elicitação do cliente. O comportamento do software precisa ser representado.

Recomendações para descrição de requisitos
  • Utilizar termos que definem o grau de obrigatoriedade do requisito. Ex.: Deve, poderá, requer...
  • Evitar uso de jargões;
  • Descrição clara;
  • Evitar duplicidade de informações;
4. O que é engenharia de requisitos?
Engenharia de Requisitos
  • Conjunto de técnicas empregadas para levantar, detalhar, documentar, validar e gerenciar os requisitos de um produto.
  • É o passo essencial para o desenvolvimento de um bom produto.
  • O principal artefato da engenharia de requisitos é o Modelo de Problema.

5. O que deve ser descrito no modelo do problema?
Modelo de Problema
  • Funcionalidades: o que o produto deverá fazer?
  • Interfaces externas: como o produto interage com as pessoas, hardware e outros sistemas?
  • Desempenho: qual tempo de resposta?
  • Outros atributos: quais as considerações sobre confiabilidade, segurança, portabilidade?
  • Restrições impostas pela aplicação: existem padrões ou limites a serem obedecidos?

A equipe (todos) do projeto é responsável por desenvolver o modelo de problema porque apenas o desenvolvedor e cliente não são suficientes, os clientes não entendem o processo de software e o desenvolvedor não entende a área de aplicação.

Como garantir que especificamos um sistema que atenda as necessidade e satisfaça às expectativas dos clientes? Não existe resposta infalível mas um processo de engenharia de requisitos bem feito é a melhor solução atual.
Engenharia de Requisitos é um trabalho que exige boa e intensa comunicação entre o engenheiro e o cliente, é composto pelas seguintes fases:
  • Estudo da viabilidade: verifica se vale a pena ou não gastar tempo e esforço com o sistema proposto, verificar se o sistema contribui para os objetivos da organização, verifica se o sistema pode ser implementado usando a tecnologia atual e dentro do orçamento, se o sistema pode ser integrado a outros.
  • Elicitação: perguntar ao cliente quais os objetivos do sistema, o que precisa ser conseguido, como o sistema se encaixa nas necessidades de negócio e como o sistema vai ser usado no dia a dia. Identificar os fatos relacionados aos requisitos. Criar cenários de uso (Use Case). Identificar o ambiente técnico onde o sistema vai ser colocado. Avalia viabilidade técnica de cada requisito detalhadamente.
    • A elicitação de requisitos gera uma declaração da necessidade e viabilidade, uma declaração delimitada de escopo do sistema, uma lista de usuários que participam, uma descrição do ambiente técnico do sistema, uma lista de requisitos e as restrições do domínio de cada um, um conjunto de cenários, protótipos desenvolvidos.
    • Técnicas
      • Entrevistas
      • Questionários
      • Casos de Uso
      • Brainstorming: reunir pessoas em uma sala e ….
    • Sempre perguntar
      • O que? Por que? Como?
      • Organize as respostas e observe, seja humilde para aprender.
  • Análise e negociação: habilidade do analista negociar com cliente e retirar requisitos que não sejam necessários e também adequar ao valor (custo) e tempo (prazo) disponibilizado. Também define-se prioridade dos requisitos (essencial, obrigatório, desejável...).
    • Verificar se:
      • cada requisito está consistente com objetivo global do sistema?
      • Requisito está no nível de abstração adequado, de fácil entendimento?
      • Requisito é realmente necessário?
      • Requisito tem atribuição (fonte, pessoa) associada?
      • Requisito é limitado e não ambíguo, ou seja, delimita bem, evita que o cliente pessa mais coisas depois.
      • Algum requisito conflita com outro?
      • Requisito é realizável no ambiente técnico do sistema?
      • Requisito pode ser testado quando estiver implementado?
  • Especificação: é um documento escrito, combinando descrições em linguagem natural e modelos gráficos (ex: casos de uso).
  • Modelagem do sistema: processo onde se elabora Modelo ER, modelo de classes, dizendo como o sistema vai ser estruturado → especificação visual tanto para o programador quanto para cliente, mas mais para o programador.
  • Validação: a especificação é avaliada quanto a qualidade através da revisão onde cada requisito é questionado, além de repetir as questões da fase de análise e negociação, os seguintes tópicos:
    • requisitos de desempenho, comportamento e características operacionais estão claramente definidos?
    • Foi criado um índice da especificação? Código para cada requisito (RF1, RNF2, RN1...)
    • O requisito está limitado em termos quantitativos?
    • Que outros requisitos se relacionam com este requisito?
    • Pode-se rastrear o requisito em qualquer modelo criado do sistema?
    • O requisito pode ser rastreado até os objetivos globais do sistema?
    • O requisito viola alguma restrição do domínio?
  • Gestão: é o processo de mudanças de requisitos durante o processo de engenharia de requisitos e o desenvolvimento de sistema. Os requisitos são, inevitavelmente, incompletos e inconsistentes e com isso novos requisitos acabam surgindo durante o processo, à medida que as necessidades de negócio mudam e uma melhor compreensão do sistema é desenvolvida. Os diferentes pontos de vista têm requisitos diferentes e estes são frequentemente contraditórios.
    • É necessário planejar:
      • Identificação requisitos;
      • Processo de mudança de requisitos;
      • Políticas de rastreabilidade: quantidade de informações mantidas sobre as relações entre os requisitos;
      • Apoio de ferramenta CASE;

Requisitos de alta qualidade são claros, completos, sem ambiguidades, implementáveis, consistentes e testáveis. Qualquer requisito que não apresenta estras características poderá ser problemático ao projeto.

IEEE → I3E → Instituto de Engenheiros Eletrônicos e Eletricistas

Instituto responsável por ditar normas e padrões sobre ciclo de vida de software, métricas etc. Normalmente estas normas estão em Inglês, raramente aparece algum em espanhol.
IEEE 830 → Atributos de um bom documento de requisitos:
    • Correto: os requisitos são aqueles que o sistema efetivamente deve atender.
    • Sem ambiguidades: única interpretação.
    • Completo: todos requisitos estão identificados, bem como respostas do sistema para todas situações de utilização.
    • Consistente: todos requisitos estão de acordo com especificações superiores.
    • Verificável: uma pessoa ou sistema atestar o cumprimento de cada requisito listado.
    • Modificável: qualquer requisito listado pode ser alterado sem impactar nos demais requisitos (ortogonais).
    • Trançável: é possível relacionar ele com as telas.

Comentários

Postagens mais visitadas deste blog

Solução para problemas com impressora de cheque Bematech DP-20

Como bloquear Facebook Youtube no Mikrotik

SIOPE 2017 - Instalação e Restauração Cópia de Segurança