Apostila Estácio: Engenharia de Software de Roger S. Pressman. 6º Edição/2006 1
2
A engenharia de requisitos é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo. Este processo deve ser precedido de estudos que viabilizem a partir das restrições do projeto, determinando se este é ou não viável e se deve prosseguir para a identificação dos requisitos. 3
O processo de engenharia de requisitos é composto por cinco atividades de alto nível (THA, 1997), para que possamos entender o que o cliente deseja: 1. Identificação. 2. Análise e negociação. 3. Especificação e documentação. 4. Validação. 5. Gerindo os requisitos. 4
O processo de engenharia de requisitos é realizado por meio da execução de sete funções distintas: 1. Concepção. 2. Levantamento. 3. Elaboração. 4. Negociação. 5. Especificação. 6. Validação. 7. Gestão. Algumas dessas funções ocorrem em paralelo, sendo no geral, todas adaptadas às necessidades do projeto, tentando definir o desejo do cliente, estabelecendo uma fundação sólida e equilibrada para o projeto. 5
6
CONCEPÇÃO Apostila Como podemos iniciar um projeto de software? Apostila Existe um evento único que se torna catalisador de um novo sistema ou produto baseado em computador que conforme a necessidade evolui com o passar do tempo? Não existem resposta para essas perguntas. Não se trata de seguir determinadas regras, mas interligar com a experiência da engenharia em identificar as necessidades do cliente. Muitos dos assuntos relacionados ao seu conteúdo e a forma de como deverá ser desenvolvido precisam estar claramente determinados, exemplificados e rascunhados, contendo a aprovação de todos interessados no projeto. 7
CONCEPÇÃO Para o início do projeto, as vezes um conversa casual seria tudo que a engenharia de software necessitaria para começar um esboço. No geral todo início de projeto está ligado a alguma necessidade de mercado ou negócio. Essa necessidade leva os gerentes do negócio/produto e a área de marketing a definir a idéia principal e tentar identificar as necessidades e abrangência de mercado através de análises de viabilidade, elaborando uma descrição do funcionamento do escopo do projeto. Na realidade o que acontece na Concepção é que os engenheiros de software estabelecem um série de questões livres de contextos com a intenção de estabelecer um entendimento básico do problema. 8
CONCEPÇÃO QUALIDADE DE SOFTWARE REQUISITOS ATIVIDADES DE ALTO NÍVEL FUNÇÕES Identificação Análise e Negociação Especificação e Documentação Validação Gerindo Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Esboço Mercado de Negócio Idéia Principal Necessidades Abrangência 9
LEVANTAMENTO O levantamento dos requisitos é muito simples: Pergunte ao cliente, aos usuários e aos outros quais são os objetivos do sistema ou do produto? O que precisa ser conseguido? Como o sistema ou o produto se encaixa nas necessidades do negócio? Como o sistema ou o produto será usado no dia a dia? Muito simples, quatro perguntas resolvem todos os problemas. Infelizmente não é simples, é muito difícil. 10
LEVANTAMENTO Christel e Kang (1992) identificam vários problemas que nos ajudam a compreender por que o levantamento é tão difícil: Problemas de escopo Se o limite do sistema for mal definido ou o cliente/usuário especificar detalhes técnicos não necessários, estes poderão confundir em vez de esclarecer os objetivos gerais do sistema. Problemas de entendimento: Clientes/usuários em muitas das vezes não estão totalmente corretos sobre as necessidades do sistema. No geral possuem pouca compreensão das capacidades e limitações que seu ambiente computacional oferece para o desenvolvimento. 11
LEVANTAMENTO Possuem dificuldades de passar aos engenheiros as informações que acreditam ser óbvias. Especificam requisitos que conflitem com as necessidades de outros clientes/usuários. Especificam requisitos ambíguos (podem seguir mais de um sentido) ou impossíveis de testar. Problemas de votabilidade Este é simples, são os requisitos que mudam ao longo do tempo. Organização é tudo na coleta de dados para os Requisitos. 12
LEVANTAMENTO QUALIDADE DE SOFTWARE REQUISITOS ATIVIDADES DE ALTO NÍVEL FUNÇÕES Identificação Análise e Negociação Especificação e Documentação Validação Gerindo Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Esboço Mercado de Negócio Idéia Principal Necessidades Abrangência Escopo Entendimento Votabiliade 13
ELABORAÇÃO São o refinamento das informações obtidas do cliente na concepção e no levantamento. A elaboração de uma modelagem de análise (UML) descrevendo como o usuário final e outros atores irão interagir com o sistema. Cada cenário é analisado para extrair as classes das análises visíveis ao usuário final. Os atributos de classes são definidos e os serviços requeridos pelas classes identificados. Os relacionamentos e colaborações entre classes são identificados. Vários diagramas UML suplementares costumam ser elaborados. Teremos como resultado final de um modelo de análise que define: as informações, funcionalidades e sistemas comportamentais. 14
ELABORAÇÃO QUALIDADE DE SOFTWARE REQUISITOS ATIVIDADES DE ALTO NÍVEL FUNÇÕES Identificação Análise e Negociação Especificação e Documentação Validação Gerindo Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Esboço Mercado de Negócio Idéia Principal Necessidades Abrangência Escopo Entendimento Votabiliade Refinamento Elaboração UML Classes Atributos Relacionamentos Colaborações 15
NEGOCIAÇÃO Fase em que clientes e usuários costumam pedir mais do que pode ser conseguido, não considerando os recursos limitados do negócio. São ouvidas propostas de clientes/usuários com requisitos conflitantes, argumentando ser essenciais para suas necessidades especiais. Quando isso acontece, é muito importante reconciliar esses conflitos usando processos de negociação. A partir desses conflitos precisamos solicitar aos clientes/usuários que ordenem os requisitos e discutam os conflitos de prioridade. Os riscos associados aos requisitos precisam ser identificados e analisados. Elaborar estimativas, mesmo que grosseiras, do desenvolvimento para avaliar os impactos de cada requisito no custo e no prazo de entrega do projeto. 16
NEGOCIAÇÃO QUALIDADE DE SOFTWARE REQUISITOS ATIVIDADES DE ALTO NÍVEL FUNÇÕES Identificação Análise e Negociação Especificação e Documentação Validação Gerindo Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Esboço Mercado de Negócio Idéia Principal Necessidades Abrangência Escopo Entendimento Votabiliade Refinamento Elaboração UML Classes Atributos Relacionamentos Colaborações Processos Conflitantes Riscos Estimativas de Prazos e Custos 17
ESPECIFICAÇÃO No geral uma especificação pode ser: Um documento escrito; Um modelo gráfico; Um modelo matemático; Uma coleção de cenários de uso; Um protótipo; Enfim, qualquer combinação desses elementos. Alguns engenheiros preferem usar um gabarito padrão para elaborar suas especificações, isso torna a apresentação dos requisitos mais consistente. No entanto, algumas vezes isso não possível, e se faz necessário elaborar especificações mais flexíveis. 18
ESPECIFICAÇÃO Quando desenvolvemos grandes sistemas, um documento escrito, combinando descrições em linguagem natural e modelos gráficos que podem ser uma melhor abordagem para o problema. Já para produtos ou sistemas menores residentes em um ambiente técnico com um bom desenvolvimento, somente os cenários de uso sejam o suficiente. Precisamos mentalizar que a especialização é o produto final produzido pelo engenheiro de requisitos, servido para: Descrever a função; Descrever o desempenho de um sistema baseado em computador; Descrever as restrições que orientarão o seu desenvolvimento. 19
ESPECIFICAÇÃO QUALIDADE DE SOFTWARE REQUISITOS ATIVIDADES DE ALTO NÍVEL FUNÇÕES Identificação Análise e Negociação Especificação e Documentação Validação Gerindo Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Esboço Mercado de Negócio Idéia Principal Necessidades Abrangência Escopo Entendimento Votabiliade Refinamento Elaboração UML Classes Atributos Relacionamentos Colaborações Processos Conflitantes Riscos Estimativas de Prazos e Custos Funções Desempenho Restrições 20
VALIDAÇÃO É nesta fase que os produtos são avaliados quantos a qualidade. Garante que todos os requisitos do software tenham sido declarados de modo não tomar mais de um sentido, quanto: As inconsistências; Omissões; Erros tenham sido declarados e corrigidos; Produtos de trabalho de acordo com as normas estabelecidas para: o Processo; o Projeto; o Produto. O principal mecanismo de validação de requisitos é a revisão técnica formal, que será vista mais adiante. 21
VALIDAÇÃO Apostila, pag. 120 Checklist de Validação dos Requisitos: Os requisitos foram claramente estabelecidos para não serem mal interpretados? A fonte do requisito foi identificada e examinada pela fonte original ou com ela? O requisito está limitado em termos quantitativos? Que outros requisitos se relacionam a este requisito? O requisito viola alguma restrição do domínio? O requisito pode ser testado? Se sim, podemos especificar os testes? 22
VALIDAÇÃO Podemos relacionar o requisito a qualquer modelo de sistema que tenha sido criado? O requisito está relacionado aos objetos globais do sistema/produto? A especificação do sistema está estruturada de modo que seja: o Leve e de fácil entendimento? o Fácil referenciação? o Fácil tradução em produtos de trabalho mais técnicos? Foi criado um índice para a especificação? Os requisitos associados ao desempenho, ao comportamento e às características operacionais do sistema foram claramente declarados? Que requisitos parecem estar implícitos? 23
VALIDAÇÃO QUALIDADE DE SOFTWARE REQUISITOS ATIVIDADES DE ALTO NÍVEL FUNÇÕES Identificação Análise e Negociação Especificação e Documentação Validação Gerindo Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Esboço. Mercado de Negócio. Idéia Principal. Necessidades. Abrangência. Escopo. Entendimento. Votabiliade. Refinamento. Elaboração UML. Classes. Atributos. Relacionamentos. Colaborações. Processos Conflitantes. Riscos. Estimativas de Prazos e Custos. Funções. Desempenho. Restrições. Inconsistências. Omissões. Erros. Normas: Processo; Projeto; Produto. 24
GESTÃO QUALIDADE DE SOFTWARE A gestão dos requisitos é um conjunto de atividades que ajudam a equipe de projeto a: Identificar; Controlar; Rastrear os requisitos e suas modificações em qualquer época. A gestão dos requisitos começa com a forma de identificação que é atribuída a cada requisito, sendo desenvolvidas tabelas de rastreamento, onde estas estão relacionados aos requisitos identificados a um ou mais aspectos do sistema ou ao seu ambiente. 25
GESTÃO QUALIDADE DE SOFTWARE Requisitos Tabela de Rastreamento Genérico Aspectos específicos do sistema ou de seu ambiente A01 A02 A03 A04 A05 A06 A07 A08 R01 R02 R03 R04 R05 R06 R07 Rii Aii Exemplo da apostila Estácio do autor Roger S. Pressman 6ª Edição/2006, pag. 122. 26
GESTÃO QUALIDADE DE SOFTWARE A tabela apresentada é genérica, mas temos outras tabelas: De rastreamento de características; De rastreamento de fontes; De rastreamento de dependências; De rastreamento de subsistemas; De rastreamento de interface. Para mais informações sobre essas tabelas, consulte a página 121 da apostila Estácio do autor Roger S. Pressman 6ª Edição/2006. 27
GESTÃO QUALIDADE DE SOFTWARE REQUISITOS ATIVIDADES DE ALTO NÍVEL FUNÇÕES Identificação Análise e Negociação Especificação e Documentação Validação Gerindo Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Concepção Levantamento Elaboração Negociação Especificação Validação Gestão Esboço. Mercado de Negócio. Idéia Principal. Necessidades. Abrangência. Escopo. Entendimento. Votabiliade. Processos Conflitantes. Riscos. Estimativas de Prazos e Custos. Funções. Desempenho. Restrições. Refinamento. Elaboração UML. Classes. Atributos. Relacionamentos. Colaborações. Inconsistências. Omissões. Erros. Normas: Processo; Projeto; Produto. Identificação. Controle. Rastreamento. 28
LEITURA DA APOSTILA QUALIDADE DE SOFTWARE Consulte o material didático: Faça uma leitura do material didático referente a apostila Engenharia de Software. 6º Edição/2006 de Roger S. Pressman, págs. 116 à 122. Uma especial atenção para a pag. 121, item Ferramentas de Software, leitura obrigatória. 29
AULAS DE APOIO QUALIDADE DE SOFTWARE Estarão disponibilizadas nos descritos a baixo para downloads os arquivos nos formatos: PowerPoints ou Word das aulas. Alguns estarão disponíveis para impressão, outros, somente para leitura, mas não para edição. Em alguns casos em que se fizer necessário a impressão, o professor estará liberando para um melhor desenvolvimento dos trabalhos a ser solicitados. www.aulasprof.6te.net ou www.profcelso.orgfree.com/ Contato: celsocan@gmail.com 30
FIM 31