Engenharia Software I Aula 02

Transcrição

1 Engenharia Software I Aula 02 UNIDADE 1 Engenharia Requisitos Professor Fábio Codo

2 Definição Profº Fábio Codo Contatos: Telefone: (011) Perfil Profissional: Perfil Pessoal : Site:

3 O que é um requisito? Requisito (Definição - IEEE): Uma condição ou uma funcionalidade necessária a um usuário para resolver um problema. Uma condição ou funcionalidade que deve ser atingida ou influenciada por um componente de sistema para satisfazer um contrato, padrão, especificação, ou outro documento formalmente definido.

4 Definição de Engenharia de Requisitos A engenharia de requisitos fornece o meio adequado para entender o que o cliente deseja, analisando as necessidades, avaliando a exeqüibilidade, negociando uma condição razoável, especificando a solução de modo não ambíguo, validando a especificação e gerindo os requisitos à medida que eles são transformados em um sistema operacional. Eu sei que você pensa que entende o que eu disse, mas o que você não entende é que, o que eu disse, não é o que eu queria dizer.

5 SOMMERVILLE A Engenharia de Requisitos de Software é o ramo da Engenharia de Software que envolve as atividades relacionadas com a definição dos requisitos de software de um sistema, desenvolvidas ao longo do ciclo de vida de software (KOTONYA; SOMMERVILLE, 1998).

6 Análise de Requisitos Tem o objetivo de identificar e analisar os requisitos do software ser desenvolvido O resultado desta atividade é uma lista de requisitos especificados de acordo com os padrões do método de desenvolvimento adotado (documento de requisitos, diagramas, backlog, etc) Responde às seguintes questões: O que? Quais? Quem? Quando?

7 Stakeholders S takeholder é qualquer pessoa ou organização que tenha interesse, ou seja afetado pelo projeto. A palavra vem de: Stake: interesse, participação, risco Holder: aquele que possui Os primeiros stakeholders que imaginamos em um projeto são o Gerente de Projeto, o Patrocinador do Projeto, a Equipe de Projeto e o Cliente. Entretanto, na prática podem existir muitos outros: A comunidade Outras áreas da empresa Concorrentes Fornecedores Investidores e acionistas Governo As famílias da equipe de projeto

8 Passos na Identificação de requsito Concepção define o escopo e a natureza do problema a ser resolvido Levantamento: ajuda o cliente a definir o que é necessário Elaboração: refina e modifica os requisitos básicos; Negociação: Verifica a prioridade, aspectos essenciais, entre outros Especificação: documenta o problema; Gestão: permite revisões e validações

9 Praticando a Engenharia de Requisitos Concepção > Reunião Primeiro Contato Ata Levantamento > Entrevista com os atores - Ata Elaboração> Escrita e detalhamento da necessidade- EA e Documento Negociação > Validação do entendimento e aprovação Ata e documento de aceite Especificação > Especificação final e documento aprovado Gestão > Avaliação em todos os passos

10 Processo engenharia de requisitos

11 Levantando requisitos Entendimento do domínio da aplicação: entendimento geral da área na qual o sistema será aplicado; Entendimento do problema: entendimento dos detalhes do problema específico a ser resolvido com o auxílio do sistema a ser desenvolvido; Entendimento do negócio: entender como o sistema irá afetar a organização e como contribuirá para que os objetivos do negócio e os objetivos gerais da organização sejam atingidos; Entendimento das necessidades e das restrições dos interessados: entender as demandas de apoio para a realização do trabalho de cada um dos interessados no sistema, entender os processos de trabalho a serem apoiados pelo sistema e o papel de eventuais sistemas existentes na execução e condução dos processos de trabalho. Consideram-se interessados no sistema, todas as pessoas que são afetadas pelo sistema de alguma maneira, dentre elas clientes, usuários finais e gerentes de departamentos onde o sistema será instalado.

12 Técnicas para Análise de Requisitos Entrevistas Questionários Observação Análise de documentos Cenários

13 Stackholders Pessoas envolvidas no projeto que participam ou influenciam as decisões: Exemplo: Gerente comercial Diretor de Ti Operadora do Sistema

14 Tipos de requisitos Requisitos Funcionais: são declarações de serviços que o sistema deve prover,descrevendo o que o sistema deve fazer (SOMMERVILLE, 2007).Um requisito funcional descreve uma interação entre o sistema e o seu ambiente (PFLEEGER, 2004), podendo descrever, ainda, como o sistema deve reagir a entradas específicas, como o sistema deve se comportar em situações específicas e o que o sistema não deve fazer (SOMMERVILLE, 2007). Requisitos Não Funcionais: descrevem restrições sobre os serviços ou funções oferecidos pelo sistema SOMMERVILLE, 2007), as quais limitam as opções para criar uma solução para o problema (PFLEEGER, 2004).Neste sentido, os requisitos não funcionais são muito importantes para a fase de projeto (design), servindo como base para a tomada de decisões nessa fase.

15 Classificação Requisitos organizacionais: são derivados de metas, políticas e procedimentos das organizações do cliente e do desenvolvedor. Incluemrequisitos de processo (padrões de processo e modelos de documentos que devem ser usados), requisitos de implementação (tal como a linguagem deprogramação a ser adotada), restrições de entrega (tempo para chegar ao mercado - time to market, restrições de cronograma etc.), restrições orçamentárias (custo, custo-benefício) etc. Requisitos externos: referem-se a todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. Podem incluir requisitos de interoperabilidade com sistemas de outras organizações, requisitos legais (tais como requisitos de privacidade) e requisitos éticos. Requisitos de produto: especificam o comportamento do produto (sistema). Referem-se a atributos de qualidade que o sistema deve apresentar, tais como confiabilidade, usabilidade, eficiência, portabilidade, manutenibilidade e segurança.

16 Requisitos de Usuário: Requisitos de Sistema: Niveis de Requisitos são declarações em linguagem natural acompanhadas de diagramas intuitivos de quais serviços são esperados do sistema e das restrições sob as quais ele deve operar. Devem estar em um nível de abstração mais alto, de modo que sejam compreensíveis pelos usuários do sistema que não possuem conhecimento técnico. definem detalhadamente as funções, serviços e restrições do sistema. São versões expandidas dos requisitos de usuário usados pelos desenvolvedores para projetar, implementar e testar o sistema. Como requisitos de sistema são mais detalhados, as especificações em linguagem natural são insuficientes e para especificá-los, notações mais especializadas devem ser utilizadas.

17 Validando os Requisitos Completo: o requisito deve descrever completamente a funcionalidade a ser entregue (no caso de requisito funcional), a regra de negócio a ser tratada (no caso de regras de negócio) ou a restrição a ser considerada (no caso de requisito não funcional). Correto: cada requisito deve descrever exatamente a funcionalidade, regra ourestrição a ser construída. Consistente: o requisito não deve ser ambíguo ou conflitar com outro requisito. Realista: deve ser possível implementar o requisito com a capacidade e com as limitações do sistema e do ambiente de desenvolvimento. Necessário: o requisito deve descrever algo que o cliente realmente precisa ou que é requerido por algum fator externo ou padrão da organização. Passível de ser priorizado: os requisitos devem ter ordem de prioridade para facilitar o gerenciamento durante o desenvolvimento do sistema. Verificável e passível de confirmação: deve ser possível desenvolver testes para verificar se o requisito foi realmente implementado. Rastreável: deve ser possível identificar quais requisitos foram tratados em um determinado artefato, bem como identificar que produtos foram originados a partir de um requisito.

18 Simulando um Caso Visando aprimorar seus serviços, o gerente geral da Cervejaria BeboSim solicitou à necessário controlar o nome da equipe e a região que atende (por ex. norte do ES, empresa Avalon sul de Minas Gerais, Grande Vitória, etc). Software do Futuro que desenvolvesse um sistema de controle de produção e venda 6. Uma equipe atende somente a uma região por vez. Uma região pode ter mais de de seus produtos. Os requisitos descritos abaixo devem ser atendidos pelo sistema. uma equipe de vendas ao mesmo tempo. Uma equipe não muda de região. 1. A cervejaria produz diversos produtos líquidos, tais como: cerveja branca, cerveja 7. Cada equipe é composta por vendedores e por um gerente. Tanto do gerente escura, guaraná normal, guaraná light, água mineral com gás, água mineral sem quanto do vendedor, (ambos funcionários da cervejaria) é necessário armazenar o gás, etc, que devem estar cadastrados no sistema. De cada produto, devem ser nome, data de admissão, número da carteira de trabalho, do CPF, o endereço armazenados: nome, quantidade em estoque, preço normal de venda residencial, os telefone e de contato. atual (único em todo o país), o percentual de comissão sobre a venda e fórmula de 8. É necessário armazenar o histórico da gerência de cada equipe, armazenando produção. data de início e fim da gerência de cada pessoa. 2. A cervejaria possui diversas unidades de produção (fábricas). De cada uma delas é 9. Um funcionário pode mudar de equipe e é necessário armazenar a data de início e necessário armazenar seu nome, endereço, CNPJ, área construída e telefone de fim de cada funcionário em cada equipe. contato. 10. A cervejaria possui diversos clientes cadastrados. Somente as pessoas jurídicas 3. Cada produto pode ser produzido em mais de uma unidade de produção. Uma podem ser clientes. Dos clientes deve-se armazenar a razão social, o CNPJ, o unidade de produção pode produzir mais de um produto, mas não necessariamente endereço, o telefone e a pessoa de contato. todos. Por exemplo, na unidade da Bahia, são produzidas apenas cerveja branca e 11. O vendedor emite pedidos de venda, que devem ser registrados no sistema. Para cerveja escura. No Espírito Santo são produzidas, por exemplo, cerveja branca, cada pedido de venda é necessário armazenar o vendedor que emitiu o pedido, o água mineral com gás e sem gás e guaraná normal. cliente do pedido, o número do pedido e sua data de emissão. 4. Os produtos são engarrafados em embalagens dos mais variados tipos: garrafas 12. O pedido pode discriminar vários produtos. De cada um deles é necessário de plástico de tamanhos armazenar a quantidade vendida. variados, garrafas de vidro, latinhas de alumínio de tamanhos variados, etc. Um 13. A Cervejaria BeboSim faz constantes campanhas publicitárias, que devem ser produto pode ser armazenado em mais de uma embalagem e uma embalagem pode controladas pelo sistema De cada campanha publicitária é importante armazenar o ser usada por mais de um produto. De cada embalagem, é necessário armazenar o nome da campanha, as datas de início e fim, os produtos que farão parte da nome, uma descrição do tipo de material de que é feita (plástico, alumínio, etc.), o campanha, os preços promocionais de cada produto em cada campanha, o nome do custo de cada embalagem, o volume que ela pode conter e a unidade do volume (ex. garoto/garota propaganda da campanha (ex. Guga, Ronaldinho, Pelé, Romário, Luiza uma latinha de alumínio de 350 ml, uma garrafa de plástico de 1,5 litros, etc.). 5. A Brunet cervejaria possui várias equipes de vendas espalhadas pelo país. De cada equipe é

19 SOMMERVILLE, I. Engenharia de software. 6. Ed. São Paulo: Pearson SCHACH, S. Engenharia de software: Os paradigmas clássico e orientado a objetos. São Paulo: McGraw Hill, PRESSMANN, ROGER S. Engenharia de software. São Paulo: Makron Books, 2010

20 Bibliografia SOMMERVILLE, I Engenharia de Software, 6 Ed. Editora Pearson : São Paulo 2010 PRESSMAN, Roger S. Engenharia de Software, 6 Ed. Editora CGrawHill: Porto Alegre, SCHACH, S. Engenharia de software: Os paradigmas clássico e orientado a objetos. São Paulo: McGraw Hill, PRESSMANN, ROGER S. Engenharia de software. São Paulo: Makron Books, 2010 Professora Juliana Jenny - acessado em Julho/2013

21