engenharia de software processos de engenharia de requisitos abr/2010

Engenharia de Software

Processos de Engenharia de Requisitos

Abr/2010

Objetivos – Engenharia de Requisitos

Criar e manter um documento de requisitos do Sistema.

Quatro subprocessos: Estudo de Viabilidade Levantamento e análise de Requisitos Especificação de Requisitos (Aula anterior) Validação de Requisitos



Quatro subprocessos: Estudo de Viabilidade Levantamento e análise de Requisitos Especificação de Requisitos Validação de Requisitos

Estudo de Viabilidade Entrada:

Conjunto preliminar de requisitos de negócio Esboço da descrição do sistema Como o Sistema apoiará o negócio

Saída Relatório que recomenda ou não prosseguir com os processos

de Engenharia de Requisitos e de Desenvolvimento de Sistemas

Estudo breve que responde: Sistema contribui para os objetivos gerais da organização Sistema pode ser implementado com

Tecnologia atual Restrição de custo Restrição de prazo

Sistema pode ser integrado aos outros Sistemas

Estudo de Viabilidade

Possíveis questões a serem levantadas:

Como seria se esse sistema não fosse implantado? Problemas com os processos atuais e como o novo sistema

ajudaria? Contribuição direta do novo Sistema para os objetivos da

empresa? As informações podem ser transferidas e recebidas de outros

sistemas da organização? O Sistema requer Tecnologia ainda não usada na

organização? O que deve ser apoiado pelo Sistema e o que não deve ser

apoiado?

Estudo de Viabilidade

Consulta: Gerência de Departamentos onde o Sistema será usado Outros desenvolvedores familiarizados com o Sistema proposto Especialistas em TI Usuários Finais

Relatório de Viabilidade Pode Propor:

Mudanças de escopo Mudanças de orçamento Mudanças de prazo Sugestões de requisitos de alto nível adicionais



Quatro subprocessos: Estudo de Viabilidade Levantamento e análise de Requisitos Especificação de Requisitos Validação de Requisitos

Levantamento e Análise de Requisitos

Trabalham com clientes e usuários finais do Sistema:

Para aprender sobre o domínio da aplicação Quais serviços o Sistema deve fornecer Desempenho esperado Restrições de Hardware

Envolve qualquer pessoa ou grupo afetado pelo Sistema, direta ou indiretamente (stakeholder)


Detalhamento e Compreensão dos requisitos dos stakeholders é difícil por várias razões: Não sabem o que querem do Sistema a não ser em termos

gerais Não tem conhecimento dos custos envolvidos Expressam as necessidades em seus próprios termos e com o

conhecimento implícito de seu trabalho Diferentes stakeholders tem diferentes requisitos, expressos de

diferentes formas (pontos de convergência e conflitos) Fatores políticos Ambiente econômico e de negócios é dinâmico.


As atividades envolvidas em espiral

Atividades: Obtenção dos requisitos

Classificação e Organização dos requisitos

Priorização e negociação de requisitos

Documentação de Requisitos

Obtenção dos Requisitos

Processo que reúne informações sobre o sistema proposto e os existentes.

Fontes:

Documentação Stakeholders (entrevistas e observações) – Uso de cenários e

protótipos para auxiliar na obtenção dos requisitos. Especificações de Sistemas Similares Dominío da aplicação Outros sistemas que interagem com o Sistema


Fontes de requisitos podem ser representadas como Pontos de Vista do Sistema, em que cada ponto de vista apresenta um subconjunto de requisitos do Sistema.

3 tipos genéricos de Pontos de Vista:

Ponto de Vista de interação – utilizam diretante. Ponto de Vista Indiretos – não usam, mas são afetados Ponto de Vista de Domínio (ex. padrões de comunicação de

daods)


Identificar os Pontos de Vista relevantes pode ser difícil.

Para ajudar, tentar identificar tipos mais específicos de pontos de vista: Fornecedores e receptores de serviços do Sistema. Sistemas que tem interface. Regulamentos e padrões aplicáveis. Fontes de requisitos de negócio e não funcionais do sistema. Desenvolvedores do Sistema Marketing

Depois de identificados e estruturados, identificar os PV mais importantes e começar com eles a obtenção dos requisitos do Sistema.


Entrevistas

Formal/Informal Questões sobre o sistema que eles usam e o Sistema a ser

desenvolvido. Fechadas / Abertas. Pré-roteiro. Úteis para:

Entendimento geral sobre o que os stakeholders fazem Como eles podem interagir com o sistema Dificuldades com os sistemas atuais


Entrevistas

Difícil levantar o conhecimento de domínio durante as entrevistas devido a:

Terminologia e jargões específicos Alguns conhecimentos de domínio são tão familiares aos

stakeholders que são considerados difíceis de explicar ou não vale a pena mencionar.

Problemas também para levantar requisitos e restrições organizacionais.

Obtenção dos RequisitosCenários

Pessoas consideram mais fácil relatar exemplos do que abstrair descrições.Começa com um esboço da interação que será detalhada durante o levantamento.Inclui: Descrição do que os usuários esperam do sistema no início do

cenário Descrição do fluxo normal de eventos no cenário Descrição do que pode dar errado e como é tratado Informações sobre outras atividades que podem ocorrer

simultaneamente Descrição do estado do sistema ao final do cenário.

Podem ser escritos ou completados com diagramas, imagens de computador ou ainda uma abordagem mais estruturada como cenários de eventos ou casos de uso.


Casos de Uso

Técnica baseada em cenários para elicitação de requisitos.

Identifica o tipo de interação e os agentes envolvidos.

Como enfocam as interações são eficazes para os requisitos de pontos de vista de interação, em que cada tipo de interação pode ser representado como um caso de uso.

Não são eficazes para restrições de requisitos de negócio e requisitos não funcionais de alto nível.


Casos de Uso

Busca Artigos

Impressão Artigos

Adm Usuários

Serv. Catálogo

Usuário de Biblioteca

Fornecedor

Funcionários Biblioteca


Etnografia

Técnica de observação para compreender os requisitos sociais e organizacionais.

Um analista se insere no ambiente de trabalho aonde o sistema será usado e observa o dia a dia.

Eficaz para: Requisitos implícitos do sistema que refletem os processos reais Requisitos derivados de como as pessoas realmente trabalham Requisitos derivados da cooperação e do conhecimento das

atividades das outras pessoas.



Quatro subprocessos: Estudo de Viabilidade Levantamento e análise de Requisitos Especificação de Requisitos (aula anterior) Validação de Requisitos

Validação de Requisitos

Mostrar que os requisitos realmente definem o Sistema que o Usuário deseja.

Verificações de Validade – Necessidade do Sistema ou de mais funções ou características

Verificações de Consistência – Requisitos não conflitantes. Verificações de Completeza – O documento de requisitos deve

incluir todas as funções e restrições necessárias. Verificação de Realismo – Se podem ser implementados. Facilidade de Verificação – Os requisitos de sistema devem ser

escritos de modo que sejam verificáveis. Isto é, pode-se definir um conjunto de testes que possa demonstrar que o sistema entregue atende cada requisito especificado.

Validação de Requisitos

Revisões de Requisitos

É um processo manual que envolve pessoas de ambas as organizações. Eles verificam o documento de requisitos em busca de anomalias e omissões.Podem ser formais ou informais e com o maior número de stakeholders a confirmação dos requisitos.Os requisitos devem atender: Consistência Completeza. Facilidade de Verificação. Facilidade de Compreensão. Rastreabilidade. Adaptabilidade.

Gerenciamento de Requisitos

Processo para compreender e controlar as mudanças dos requisitos do sistema. Manter o acompanhamento dos requisitos individuais e manter as ligações entre os requisitos dependentes de modo que seja possível avaliar o impacto das mudanças de requisitos.

Requisitos de Sistema de Software sempre mudam. Normalmente Requisitos de Sistema são incompletos Durante o processo o entendimento dos Stakeholders muda. Depois de instalado surgem novos requisitos

Prioridades são mudadas Quem paga o Sistema é diferente de quem usa Ambiente de negócios e técnico do sistema muda.


Requisitos Permanentes e Voláteis

A evolução de requisitos durante o processo engenharia de requisitos e após a entrada em operação é inevitável.

Requisitos Permanentes – Relativamente estáveis derivados da atividade central da organização e que se relacionam diretamente ao domínio do Sistema.

Requisitos Voláteis. Ex: políticas do governo.


Planejamento de Gerenciamento de Requisitos

No gerenciamento de requisitos devemos: Identificação de requisitos – identificação única para referencia

cruzada e avaliações de rastreabilidade. Processo de Gerenciamento de Mudanças – Avaliação do

impacto e custo das mudanças. Política de rastreabilidade Apoio informatizado

Informações de rastreabilidade: Origem – stakeholders que propuseram e os motivos Requisitos – requisitos dependentes. Projeto – requisitos aos módulos de projeto, nos quais esses

requisitos são implementados.


Gerenciamento de mudanças de requisitos

O gerenciamento de mudanças de requisitos deve ser aplicado a todas as mudanças propostas aos requisitos.

Existem três estágios no processo: Análise do problema e especificação da mudança – Se existe o

problema e se a mudança é válida ou é realizado um maior detalhamento.

Análise da mudança e estimativa de custo – Efeito avaliado usando as informações de rastreabilidade e o conhecimento geral dos requisitos do Sistema.

Implementação da mudança – O documento de requisitos, o projeto e a implementação do Sistema são modificados.

engenharia de software processos de engenharia de requisitos abr/2010

Documents