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.