Engenharia de Requisitos

Pressman vs Summerville

• Pressman
• Concepção
• Levantamento/Elicitação
• Elaboração/Refinamento/ Análise
• Negociação
• Especificação
• Validação
• Gestão de Requisitos
• Summerville
• Estudo de Viabilidade = Concepção
• Elicitação e Análise = Levantamento + Elaboração
• Especificação = Negociação + Especificação
• Validação
• Gestão de Requisitos

Concepção ou Estudo de Vialibilidade

• É identificada a necessidade de negócio ou descoberta um novo serviço ou mercado potencial;
• Interessados da comunidade de negócios definem um plano de negócio para a ideia, tentam identificar o tamanho do mercado, fazem uma análise de viabilidade aproximada e identificam uma descrição operacional do escopo do projeto.
• Todas as infos estão sujeitas a mudanças ao longo do projeto.
• Nesta fase estabelecemos um entendimento básico do problema, as pessoas que querem uma solução, a natureza da solução desejada e a eficacia da comunicação e colaboração preliminares entre os demais interessados e a equipe de software.

Levantamento ou Elicitação

• Perguntar ao cliente, usuário e demais interessados:
• quais são os objetivos do sistema para o sistema
• o que deve ser alcançado
• como o sistema atenda às necessidades da empresa
• como o sistema deve ser utilizado no dia a dia.
• Geralmente são encontrados:
• Problemas de Volatilidade: os requisitos mudam com o tempo.
• Problemas de Escopo: Necessita-se apenas do objetivo global do sistema. Porém:
• limites do sistema são definidos de forma precária
• são fornecidos detalhes técnicos desnecessários que podem confundir.
• Problemas de Entendimento: O usuário/cliente:
• omite infos óbvias para ele
• não está certo doq é preciso
• não possui entendimento completo do domínio do problema
• não sabe transmitir o que quer
• especifica requisitos que conflitam com de outros clientes ou requisitos ambíguos (impossíveis de testar).

Elaboração ou Refinamento ou Análise

• As infos obtidas nas fases anteriores são expandidas e refinadas.
• Concentra-se no dev de um modelo de requisitos refinado que identifique os diversos aspectos da função, do comportamento e das infos de software.
• Procura-se eliminar problemas das fases anteriores:
• É feito um refinamento de cenários que os usuários e outros sistemas irão interagir;
• Cada cenário de usuário é analisado sintaticamente e são definidas classes de análise (entidades de domínio de negócio)
• Os atributos de cada classe são definidos, e os serviços exigidos por cada classe são identificados.
• As relações e a colaboração entre as classes são identificadas e produze-se vários diagramas suplementares levando em conta conceitos de projeto (baixo acoplamento e alta coesão)

Negociação

• Conciliar conflitos como:
• Pedirem mais do que é possível alcançar. (dados os recursos)
• Clientes proporem necessidades conflitantes com o de outros. (argumentando a sua ser mais importante)
• É preciso conciliar conflitos por meio de ordenação e prioridades de requisitos que cada cliente faz.
• Avalia-se custos e riscos nesta priorização e então requisitos são eliminados, combinados e/ou modificados, de modo que cada parte atinja certo nível de satisfação.

Especificação

• É feita uma especificação(documento formal ou aceite do cliente), e sua forma depende da necessidade (se o sistema é grande, pequeno, complexo...)
• Sua forma pode ser:
• Um documento por escrito
• Um conjunto de modelos gráficos
• Um modelo matemático formal
• Um conjunto de cenários de uso
• Um protótipo
• Qualquer combinação dos citados.
• Ex: Para sistemas grandes, um doc escrito combinado com descrições em linguagem natural e modelos gráficos pode ser a melhor abordagem.
• obs: existe um modelo padrão que alguns autores dizem que os requisitos são apresentados de forma mais consistente e compreensível.

Validação

• Os artefatos produzidos pela engenharia de requisitos são avaliados quanto à qualidade.
• Aqui se examina a especificação para garantir que:
• Todos os requisitos de software tenham sido declarados de forma não-ambígua
• Todas as inconsistências, omissões e erros tenham sido detectados e corrigidos
• Todos os artefatos estejam de acordo com os padrões estabelecidos para o processo, projeto e produto.
• O principal mecanismo de validação é a revisão técnica:
• Feita por uma equipe formada por engenheiros de software, clientes, usuários e outros interessados
• Esses examinam a especificação em busca de erros no conteúdo ou na interpretação.

Gestão de Requisitos

• Conjunto de atividades que ajuda a equipe de projetos a identificar, controlar e acompanhar as necessidades e mudanças nos requisitos a qualquer momento do andamento do projeto.
• (avalia o impacto das mudanças que ocorreram e avalia se vai acatar mudanças sugeridas)
• Usa-se aqui a matriz RACI:
• rastreabilidade de usuário: quem solicitou o requisito?
• rastreabilidade de projeto: a qual ou quais projetos pertence?
• rastreabilidade de requisito: quais requisitos dependem desse?

Questão TRERR FCC 2015 Analista

• A Engenharia de Software realiza tarefas de modelagem
• que levam à especificação completa dos requisitos e à representação
• abrangente do projeto para o software a ser
• construído. Considerando a fase de análise de requisitos,
• é correto afirmar que
• (A) a análise de requisitos tem foco na especificação
• das características arquiteturais do software, sem se
• importar com a interface do software com outros elementos
• do sistema e sem estabelecer restrições.
• (B) a modelagem da análise de requisitos sempre começa
• com a entrevista ao cliente. O analista de sistemas
• elenca todos os objetos de dados definidos
• pelo cliente e cria um primeiro protótipo do sistema.
• (C) ao longo da modelagem de análise de requisitos, o
• principal foco do analista de sistemas está em
• “como” e não em “o que” deve ser feito. O “como” é
• mais importante, pois fornece os detalhes que nortearão
• a implementação.
• (D) a análise orientada a objetos focaliza a definição de
• relacionamentos, que define o modo pelo qual os desenvolvedores
• devem trabalhar para atender aos requisitos
• do cliente. UML e MVC são predominantemente
• orientados a objetos.
• (E) na análise de requisitos deve-se buscar minimizar o
• acoplamento ao longo de todo o sistema. Se o nível
• de interconexão é muito alto, esforços devem ser feitos
• para reduzi-lo.

Gabarito

• A Engenharia de Software realiza tarefas de modelagem que levam à especificação completa dos requisitos e à representação abrangente do projeto para o software a ser construído. Considerando a fase de análise de requisitos, é correto afirmar que
• (A) a análise de requisitos tem foco na especificação das características arquiteturais do software, sem se importar com a interface do software com outros elementos do sistema e sem estabelecer restrições.
• (B) a modelagem da análise de requisitos sempre começa com a entrevista ao cliente. O analista de sistemas elenca todos os objetos de dados definidos pelo cliente e cria um primeiro protótipo do sistema.
• (C) ao longo da modelagem de análise de requisitos, o principal foco do analista de sistemas está em “como” e não em “o que” deve ser feito. O “como” é mais importante, pois fornece os detalhes que nortearão a implementação.
• (D) a análise orientada a objetos focaliza a definição de relacionamentos, que define o modo pelo qual os desenvolvedores devem trabalhar para atender aos requisitos do cliente. UML e MVC são predominantemente orientados a objetos.
• (E) na análise de requisitos deve-se buscar minimizar o acoplamento ao longo de todo o sistema. Se o nível de interconexão é muito alto, esforços devem ser feitos para reduzi-lo.