Engenharia de Requisitos

1 Definição
1. Processo de atividades para documentação de requisitos e sua manutenção
2. Deve ser precedido de estudos de viabilidade, para determinar se é ou não viável prosseguir a identificação dos requisitos
3. especificar o que o sistema deverá fazer e determinar os critérios de validação que serão utilizados para que se possa avaliar se o sistema cumpre o que foi definido.
4. Coletar, detalhar e organizar o conjunto (pacote) de artefatos que descrevem completamente os requisitos de software do sistema ou subsistema.
5. Atividades
  1. Identificação.
  2. Análise e negociação.
  3. Especificação e documentação.
  4. Validação.
2 Estudos de viabilidade
1. Responder as seguintes questões, juntamente com os Stakeholders do projeto
  1. Será que o sistema contribui para os objetivos da organização?
  2. Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o sistema pode ser implementado?
  3. Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível?
2. Identificar quem pode responder as questões
3. e coletar informações
  1. Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização?
  2. Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas falhas?
  3. De que forma é que o sistema irá contribuir diretamente para os objetivos da organização?
  4. É possível a integração com os outros sistemas da organização (de um ponto de vista tecnológico)? Com que facilidade é que se consegue partilhar informação entre estes sistemas?
4. produção de um relatório que determinará a continuação do desenvolvimento do projeto, e definindo alguns requisitos de alto nível.
3 Identificação
1. Atividades
  1. Compreensão do Dominio
    1. Conhecer o Core Business da empresa que será implantado o sistema facilita o levantamento de requisitos
  2. Identificação das partes interessadas
  3. Captura
    1. Obter com os stakeholders os Requisitos necessários
  4. Identificação e análise de problemas
    1. Identificar problemas e propor soluções junto com os stakeholders
2. Dificuldades
  1. O cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo mas não conseguir articulá-lo (o que é bastante comum).
  2. Os requisitos identificados podem não ser realistas (do ponto de vista econômico ou tecnológico, por exemplo).
  3. Cada parte interessada pode expressar os mesmos requisitos de formas diferentes, sendo necessário - através de um bom conhecimento do domínio - identificar estas situações.
3. Técnicas para levantamento de requisitos
  1. Entrevistas e Questionários
  2. Workshops de requisitos
  3. Cenários
  4. Prototipagem
  5. Estudo etnográfico
4 Análise e negociação dos requisitos
1. Atividades
  1. Classificação
    1. agrupamento de requisitos em "módulos"
  2. Resolução de conflitos
  3. Prioritização
    1. consiste na atribuição de uma "prioridade" a cada requisito
  4. Confirmação
    1. Confirmar com stakeholders completude dos requisitos, sua consistência e validade
2. Dificuldades
  1. Fatores externos (políticos) podem influenciar os requisitos
  2. O ambiente (económico e/ou organizacional) em que a análise é feita possui fatores dinâmicos, e como tal, os requisitos estão sujeitos a alterações em decorrência destes
3. Negociações
  1. Dicas
    1. Saber lidar com ataques pessoais, de preferência nunca tomando partidos.
    2. Fomentar a justificação das posições (negativas) tomadas pelos intervenientes na negociação.
    3. Salientar (e procurar encontrar) os benefícios que uma solução apresenta para todos os envolvidos.
    4. Relaxar restrições, quando se torna óbvio que as actuais não conseguem levar a um consenso.
5 Especificação e documentação
1. Produção da documentação de Requisitos
2. Tipos de Requisitos:
  1. Requisitos Funcionais
    1. descrevem as funcionalidades, de uma forma completa e consistente. É aquilo que o utilizador espera que o sistema ofereça.
  2. Requisitos Não-Funcionais
    1. referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema.
      1. Requisitos não-funcionais de: Utilidade,
      2. Confiança,
      3. Desempenho,
      4. Suporte
      5. Escalabilidade.
  3. Requisitos do Domínio
3. tipos de especificação:
  1. Especificação de requisitos do utilizador.
    1. destinam-se aos vários níveis hierárquicos da organização, e são descritos usando apenas linguagem natural, formulários e diagramas muito simples.
    2. Dificuldades
      1. Ambiguidade:
      2. torna-se difícil descrever os requisitos de uma forma inequívoca sem tornar a sua descrição muito longa ou de difícil compreensão.
      3. Confusão:
      4. a distinção entre requisitos funcionais/não-funcionais e objetivos do sistema torna-se difícil.
      5. Agrupamento de requisitos:
      6. pode tornar-se difícil separar claramente os requisitos, o que leva a que vários requisitos sejam expressos como sendo apenas um.
    3. Considerações
      1. Usar o mesmo formato em todos os requisitos
      2. Distinguir claramente entre comportamentos esperados e desejáveis. É importante deixar claro o que o sistema tem de fazer e sugestões de como o deve fazer.
      3. Usar formatação de texto para salientar determinados aspectos do documento (usando negrito, por exemplo).
      4. Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, identificando-os e definindo-os de uma forma clara quando for absolutamente necessário usá-los.
  2. Especificação de requisitos do sistema.
    1. carácter mais técnico
    2. consistindo numa descrição detalhada dos requisitos do utilizador, para além da linguagem natural, de linguagens estruturadas e notações gráficas.
    3. Estes requisitos destinam-se ainda aos utilizadores do sistema
    4. destinam-se também às equipes de especificação de arquitetura do sistema e de desenvolvimento
    5. dificuldades
      1. As mesmas palavras podem designar conceitos diferentes.
      2. O mesmo requisito pode ser descrito de formas diferente
  3. Especificação do design da aplicação.
    1. Design da aplicação
      1. documento usado pela equipe de desenvolvimento do sistema
      2. detalhamento da arquitetura em nível técnico
      3. entendimento comum do sistema, facilidade de compreensão por novos membros da equipe.
      4. arquitetura inicial não conseguirá prever todos os eventos.
4. Documento de Especificação de Requisitos
  1. declaração oficial dos requisitos do sistema
  2. (Software Requirements Specification ou SRS)
  3. combinação dos requisitos do utilizador e do sistema
  4. e tem diferentes utilidades para diferentes pessoas
    1. Clientes: confirmar a completude dos requisitos e propor alterações.
    2. Gestores: orçamentar o sistema e planejar o processo de desenvolvimento.
    3. Engenheiros: compreender o sistema a desenvolver.
    4. Engenheiros (testes): desenvolver testes para validar o cumprimento dos requisitos.
    5. Engenheiros (manutenção): compreender o sistema e a ligação entre as suas partes.
10 Análise e especificação de requisitos de software
1. determinar os objetivos de um software
2. as restrições associadas a ele
3. elaborar a especificação precisa do software.
4. parte da análise de sistemas.
5. iniciadas juntamente com a análise do sistema
6. Análise e especificação são atividades inter-dependentes
  1. devem ser realizadas conjuntamente
7. processo de
  1. observação,
  2. classificação
  3. modelagem dos elementos do domínio
8. Identificar
  1. pessoas,
  2. as atividades,
  3. as informações do domínio
9. A especificação é a descrição sistemática e abstrata do que o software deve fazer, a partir daquilo que foi analisado
10. olução de como os problemas levantados na análise serão resolvidos pelo software
11. descrever de maneira sistemática quais as propriedades funcionais são necessárias para resolver o problema do domínio.
12. forma de comunicação sistemática com os arquitetos, programadores e testadores do software.
9 seções
1. Visão geral do produto e Sumário
2. Ambientes de desenvolvimento, operação e manutenção
3. Interfaces Externas e Fluxo de Dados
4. Requisitos Funcionais
5. Requisitos de Desempenho
6. Tratamento de Exceções
7. Prioridades de Implementação
8. Antecipação de mudanças e extensões
9. Dicas e diretrizes de Design
10. Critérios de aceitação
11. Índice Remissivo
12. Glossário
8 Uma boa especificação de requisitos deve ser:
1. Clara e não-ambígua
2. Completa
3. Correta
4. Compreensível
5. Consistente
6. Concisa
7. Confiável
7 Requisitos
1. Requisitos são objetivos ou restrições estabelecidas por clientes e usuários que definem as suas diversas propriedades do sistema.
2. Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessária que o software deve possuir (1) para que o usuário possa resolver um problema ou atingir um objetivo ou (2) para atender as necessidades ou restrições da organização ou dos outros componentes do sistema.
3. Tipos de requisitos
  1. Funcionais
    1. Exemplos
      1. "o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal".
      2. "o software deve emitir relatórios de compras a cada quinze dias"
      3. "os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.
    2. deve determinar o que se espera que o software faça
    3. não se preocupar como
    4. descrição das diversas funções que clientes e usuários querem ou precisam que o software faça
  2. Não funcionais
    1. qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras.
    2. Exemplos
      1. "a base de dados deve ser protegida para acesso apenas de usuários autorizados".
      2. "o tempo de resposta do sistema não deve ultrapassar 30 segundo".
      3. "o software deve ser operacionalizado no sistema Linux"
      4. "o tempo de desenvolvimento não deve ultrapassar seis meses".
    3. estabelecer os requisitos de forma precisa
6 Validação
1. validar documentação de requisitos
2. encontrar problemas/conflitos na especificação
3. lida com uma especificação completa dos requisitos.
4. reduzir riscos
5. reduzir custos
6. checklist dos seguintes atributos dos requisitos
  1. Validade:
    1. a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas e aceite a especificação final obtida.
  2. Consistência:
    1. não devem existir conflitos entre os requisitos identificados.
  3. Compreensibilidade / Ambiguidade:
    1. os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas.
  4. Completude:
    1. todas as funcionalidades pretendidas devem fazer parte da especificação do sistema.
  5. Realismo:
    1. dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável.
  6. Verificabilidade:
    1. se o sistema final corresponde à especificação inicial.
  7. Rastreabilidade:
    1. a origem dos requisitos, em relação ao cliente, deve estar claramente identificada.
  8. Conformidade com normas:
7. Técnicas de validação
  1. Revisões dos requisitos
    1. Uma equipe de revisores pode analisar sistematicamente a especificação produzida
  2. Prototipificação
    1. A implementação de um protótipo pode ser útil para os utilizadores finais
    2. desvantagens:
      1. tempo gasto na sua implementação
      2. desilusões com a versão final do sistema
      3. tentação de usar o protótipo para continuar o desenvolvimento do sistema
  3. Geração de casos de teste
    1. cada requisito deve ser testável
    2. deveria ser possível criar (desenhar) os respectivos testes
    3. se isto não for possível, é sinónimo de que a implementação deste requisito será difícil e que este poderá ter de ser reconsiderado.
  4. Análise de consistência automática
    1. testar de forma automática a consistência dos modelos criados