Engenharia de Software

Transcrição

1 Engenharia de Software Módulo Engenharia de Requisitos Prof. Maxwell Anderson

2 Agenda Introdução Processo de engenharia de requisitos

3 Introdução Engenharia de requisitos é difícil? Entender os requisitos de um problema está entre as tarefas mais difíceis de um engenheiro de software. Pressman Mas o cliente não sabe o que é necessário? Os usuários finais não deveriam ter um bom entendimento das características e funções? E aí? A resposta é não caro Dr. Watson! A engenharia de requisitos é difícil.

4 Introdução É o seu pior pesadelo. O cliente entra no seu escritório, senta-se, olha você direto nos olhos e diz: 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! Invariavelmente, isso acontece no final de um projeto, depois que os compromissos de prazo de entrega foram feitos, que as reputações estão envolvidas e que dinheiro sério está em jogo.

5 Introdução Todos nós que temos trabalhado no negócio de sistemas e software a alguns anos, vivemos este pesadelo e, no entanto, poucos de nós aprenderam a se livrar dele. Lutamos quando tentamos levantar requisitos de nossos clientes. Temos dificuldade de entender a informação que conseguimos. Frequentemente registramos os requisitos de maneira desorganizada e gastamos muito pouco tempo verificando o que de fato registramos. Permitimos que as modificações nos controlem, em vez de estabelecer mecanismos para controlar as modificações Prefácio do livro Effective Requirements Practices de Ralph Young

6

7 Introdução O que é requisito? Uma condição ou uma capacidade com a qual o sistema deve estar de acordo". Consiste da definição documentada de uma propriedade ou comportamento que um produto ou serviço particular deve atender. Uma característica, atributo, habilidade ou qualidade que um sistema deve necessariamente prover para ser útil a seus usuários.

8 Introdução O que é requisito? São categorizados como: Requisitos funcionais: especificam ações que um sistema deve ser capaz de executar, sem levar em consideração restrições físicas. Requisitos não-funcionais: descrevem apenas atributos do sistema ou atributos do ambiente do sistema; Não-requisitos: descrevem funcionalidades que não deverão ser implementados no sistema;

9 Introdução Requisitos funcionais Podem ser capturados como descrições formais, cenários de uso ou casos de uso. Exemplos de descrição formal: RF00 Cadastrar solicitações O sistema deverá permitir ao atendente cadastrar as solicitações de mudanças dos clientes RF05 Controlar abastecimento O sistema deverá permitir ao frentista realizar o controle de abastecimento dos veículos cadastrados na empresa...

10 Introdução Requisitos funcionais Exemplos de cenário de uso: RF05 Controlar abastecimento Hipótese inicial: o frentista se conectou ao sistema SYSCOMB e acessou a funcionalidade de registrar abastecimento. Normal: o frentista seleciona o tipo de combustível. O sistema solicita ao usuário que forneça informações da placa do veículo, valor para o abastecimento ou quantidade de combustível (em litros) e o código do bico de abastecimento a ser utilizado. O sistema libera a bomba de combustível e reinicializa contadores. O frentista abastece carro. O cliente informa método de pagamento como a vista em dinheiro ou a prazo no cartão de crédito. O frentista realiza registro de pagamento. O sistema realiza procedimentos de controle de estoque conforme definido em RF06 Controlar estoque do combustível. O que pode dar errado: ao realizar pagamento utilizando cartão de crédito, o saldo para pagamento poderá ser insuficiente. Estado do sistema após o término: a funcionalidade será encerrada e o sistema exibirá o dashboard.

11 Introdução Requisitos funcionais Exemplos de caso de uso:

12 Introdução Requisitos funcionais

13 Introdução Requisitos não-funcionais Geralmente são especificados como descrições formais. Podem ser capturados em forma de caso de uso, quando possível. Exemplos de descrição formal: RNF00 Disponibilidade O sistema deverá estar disponível 4 horas por dia, 7 dias por semana, 0 dias por mês. RNF005 Segurança O sistema deverá implementar a segurança de acesso às senhas utilizando criptografia.

14 Introdução Requisitos não-funcionais Categoria Usabilidade Confiabilidade Desempenho Suportabilidade Subcategorias fatores humanos, estética, consistência na interface do usuário, ajuda on-line e contextual, assistentes e agentes, documentação do usuário, materiais de treinamento freqüência e gravidade de falha, possibilidade de recuperação, possibilidade de previsão, exatidão, tempo médio entre falhas (MTBF) Velocidade, eficiência,disponibilidade, exatidão, taxa de transferência, tempo de resposta, tempo de recuperação, uso de recurso possibilidade de teste, extensibilidade, adaptabilidade, manutenibilidade, compatibilidade, possibilidade de configuração, possibilidade de serviço, possibilidade de instalação, possibilidade de localização (internacionalização)

15 Introdução Requisitos não-funcionais Categoria Requisito de Design Requisito de Implementação Requisito de Interface Requisito Físico Descrição especifica ou restringe o design de um sistema. especifica ou restringe o código ou a construção de um sistema. Como exemplos, podemos citar: padrões obrigatórios, linguagens de implementação, políticas de integridade de banco de dados, limites de recursos, ambientes operacionais Um requisito de interface especifica: um item externo com o qual o sistema deve interagir, restrições de formatos, tempos ou outros fatores usados por tal interação Um requisito físico especifica uma característica física que um sistema deve possuir, por exemplo, material, forma, tamanho, peso. Esse tipo de requisito pode ser usado para representar requisitos de hardware, como as configurações físicas de rede obrigatórias.

16 Introdução Não-requisitos Geralmente são especificados como descrições formais. Exemplos de descrição formal: NR00 Usabilidade O sistema não deverá permitir o uso de mouse.

17 Introdução O que é Engenharia de Requisitos? Auxilia os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver. Inclui um conjunto de tarefas que levam a um entendimento de qual será o impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais vão interagir com o software Pressman

18 Introdução Quem faz? Engenheiros de software (algumas vezes conhecidos como engenheiros de sistemas ou analistas de sistemas) ; Outros interessados (gerentes, clientes e usuários finais). []

19 Processo de Engenharia de Requisitos A parte individual mais difícil da construção de um sistema de software é decidir o que construir. Nenhuma parte do trabalho danifica tanto o sistema resultante se for feita de forma errada. Nenhuma outr a parte é mais difícil de consertar depois. Fred Brooks

20 Processo de Engenharia de Requisitos Medição e Análise Engenharia de Requisitos Análise e Projeto Qualidade de Software Engenharia de Software Verificação e Validação Testes Gerência de Projetos Codificação Configuração

21 Processo de Engenharia de Requisitos Concepção Validação Levantamento Engenharia de Requisitos Especificação Elaboração Negociação

22 Processo de Engenharia de Requisitos Concepção Pode começar com uma conversa casual; É realizada quando uma necessidade de negócio é identificada ou um mercado ou serviço novo é descoberto Validação São realizadas uma série de questões livres de contexto Concepção Engenharia de Requisitos Levantamento

23 Processo de Engenharia de Requisitos Levantamento Concepção Porque o levantamento de requisitos é difícil? Porque é tão difícil obter um entendimento claro do que o cliente deseja? Levantamento Problemas de escopo Problemas de entendimento Problemas de volatilidade Engenharia de Requisitos Elaboração Para contornar estes problemas, o engenheiro de software deve realizar a atividade de coleta de requisitos de forma organizada.

24 Processo de Engenharia de Requisitos Elaboração É realizada o refinamento das informações obtidas durante a concepção e o levantamento dos requisitos. Levantamento Engenharia de Requisitos Elaboração Negociação São definidas as funções, características e restrições de software. Ela é guiada pela criação e refinamento de cenários do usuário que descrevem como o usuário final (e outros atores) poderão interagir com o sistema. Define-se o domínio do problema informacional, funcional e comportamental.

25 Processo de Engenharia de Requisitos Negociação Às vezes os clientes pedem demais? o Elaboração Diferentes clientes ou usuários podem propor requisitos conflitantes? Negociação O engenheiro de software deve reconciliar conflitos. Devem ser realizados a priorização dos requisitos junto aos clientes, usuários e demais envolvidos. Engenharia de Requisitos Especificação Riscos são identificados e analisados Estimativas grosseiras são realizados, com o objetivo de avaliar o impacto no custo do projeto e no prazo de entrega.

26 Processo de Engenharia de Requisitos Negociação Usando uma abordagem iterativa (evolutiva), requisitos são eliminados, combinados e/ou modificados de modo que cada parte alcance algum grau de satisfação. Elaboração o Negociação Engenharia de Requisitos Especificação

27 Processo de Engenharia de Requisitos Especificação Significa coisas diferentes para pessoas diferentes. Negociação Engenharia de Requisitos Especificação Pode ser utilizado um documento escrito, um modelo gráfico, um modelo matemático formal, uma coleção de cenários de uso, um protótipo ou qualquer combinação desses elementos. Serve como fundamento das atividades consequentes. o Validação

28 Processo de Engenharia de Requisitos Validação Os requisitos são verificados quanto a sua qualidade. Especificação Engenharia de Requisitos Validação É realizado um checklist dos requisitos: Os requisitos foram claramente estabelecidos? A fonte do requisito foi identificada? O requisito está limitado em termos quantitativos? Que outros requisitos se relacionam a estes requisitos? O requisito pode ser testado? Concepção

29 O que vem agora... Vamos voltar nossos estudos ao processo de engenharia de requisitos, só que agora de maneira detalhada, através das seguintes subáreas ou fases, segundo Pressman []: Concepção Levantamento Elaboração Negociação Especificação Validação

30 Concepção Seria ótimo se clientes e engenheiros de software trabalhassem juntos em uma mesma equipe. A realidade é muito diferente. Clientes podem estar em outros lugares, cidades diferentes, podem ter uma vaga idéia do que querem, ter opiniões conflitantes, ter conhecimento técnico limitado (ou não saber de nada!), tempo limitado, podem achar que software é barato, que é fácil e rápido de se construir etc... Estas coisas são muito, mas muito comuns! Concepção

31 Concepção Vamos nos concentrar nos passos necessários para manter o projeto de desenvolvimento de software no passo certo.. Identificação dos interessados. Reconhecimento de diversos pontos de vista. Trabalho em busca de colaboração 4. Formulação das primeiras questões Concepção 4

32 Concepção. Identificação dos interessados Interessado: quem quer que se beneficie de modo direto ou indireto do sistema que está sendo desenvolvido. Quem são os suspeitos? O chefe? Gerente de negócios? Gerente de produto, de marketing, RH? Clientes externos e internos ao negócio? Usuários finais? Engenheiros de software? Dependendo sim! E outros e outros... Concepção 4

33 Concepção. Identificação dos interessados Todos tem uma visão diferente do sistema, obtém diferentes benefícios quando o sistema é desenvolvido com sucesso e está exposto a diferentes riscos se o esforço do desenvolvimento falhar. O engenheiro de requisitos deve criar uma lista de pessoas que fornecerão entradas à medida que os requisitos forem levantados. Esta lista vai crescer à medida que os interessados forem sendo contatados. Concepção 4

34 Concepção. Identificação dos interessados Esta lista vai crescer à medida que os interessados forem sendo contatados porque, a cada interessado, será perguntado: com quem mais você acha que eu deveria falar? Exemplo: Documento de Visão do RUP Concepção 4

35 Concepção. Reconhecimento de diversos pontos de vista As necessidades dos envolvidos serão explorados a partir de muitos pontos de vista diferentes. Cenário de exemplo de Pressman: O grupo de marketing esta interessado em funções e características que excitem o mercado, tornando o novo sistema fácil de vender; Os gerentes de negócio estão interessados em um conjunto de características que possam ser construídas dentro do orçamento; Os usuários podem querer características que sejam fáceis de aprender; Engenheiros de software podem estar preocupados com funções que permitam melhor manutenibilidade. Concepção 4

36 Concepção. Reconhecimento de diversos pontos de vista Cada um contribuirá com informações para o processo de engenharia de requisitos; À medida que os requisitos forem sendo levantados sob vários pontos de vistas diferentes, eles poderão estar inconsistentes e podem conflitar uns com os outros. Será necessário categorizar todas as informações dos interessados (inclusive requisitos consistentes e conflitantes). Os interessados deverão decidir quais requisitos inconsistentes deverão ser excluídos ou modificados. Concepção 4

37 Concepção. Trabalho em busca de colaboração Os clientes e outros interessados deveriam colaborar entre eles e com os engenheiros de software. O trabalho do engenheiro de requisitos é identificar áreas de concordância e áreas de conflito ou inconsistência. Em muitos casos quem bate o martelo é o gerente de negócios ou o gerente sênior, por exemplo. Eles podem decidir quais requisitos entrarão para o corte. Concepção 4

38 Concepção 4. Formulação das primeiras questões (questões livres de contexto) Identificar os interessados Quem está por trás desta solicitação de trabalho? Quem vai utilizar a solução? Qual será o benefício econômico para a solução? Há outra fonte de solução no mercado? Concepção 4

39 Concepção 4. Formulação das primeiras questões Obter melhor entendimento Como você caracterizaria boas saídas que seriam geradas? Que problemas essa solução enfrentaria? Você pode mostrar (ou descrever) o ambiente no qual essa solução será usada? Existem algumas restrições que poderiam afetar a solução? Concepção 4

40 Concepção 4. Formulação das primeiras questões Foco na própria atividade de comunicação inicial Você é a pessoa certa para responder a estas questões? Minhas questões ou dúvidas são relevantes ao problema que você tem? Estou formulando muitas dúvidas ou questões? Alguém mais pode ou precisa fornecer informações adicionais? Devo perguntar-lhe mais alguma coisa? Concepção 4

41 Concepção Técnicas Entrevistas [RUP] Workshop de requisitos [RUP] Brainstorms Encenação Revisão dos requisitos existentes Etnografia [Sommerville] Concepção 4

42 Levantamento A forma P&R é útil na concepção, mas não é uma abordagem que tenha tido marcante sucesso para o levantamento dos requisitos mais detalhados.. Coleta colaborativa de requisitos. Cenários de usuários. Produtos de trabalho do levantamento Levantamento

43 Levantamento. Coleta colaborativa de requisitos Uma equipe de interessados e engenheiros de software trabalham em conjunto para: Identificar o problema; Propor elementos da solução; Negociar diferentes abordagens; Especificar um conjunto preliminar de requisitos. Levantamento

44 Levantamento. Coleta colaborativa de requisitos Muitas ferramentas são propostas, mas a todas são aplicadas algumas diretrizes básicas: As reuniões são assistidas e conduzidas por engenheiros de software e por clientes. São estabelecidas regras para a participação. É sugerida uma agenda para cobrir todos os pontos importantes, porém deve ser encorajada o livre fluxo de idéias. Um facilitador controla a reunião. Um mecanismo de definição é utilizado: folhas de rascunho, flip charts, papel auto-adesivo, quadro de avisos, fórum virtual, sala de conversa. Levantamento

45 Levantamento. Coleta colaborativa de requisitos O objetivo é identificar o problema, a necessidade do cliente, propor elementos para a solução, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da solução em um ambiente que propicie que o objetivo seja alcançado. Levantamento

46 Levantamento. Coleta colaborativa de requisitos Cenário resumido [PRESSMAN]. Durante a concepção, perguntas e respostas básicas estabelecem o escopo do problema e uma visão geral da solução;. Os interessados redigem uma solicitação de produto de uma ou duas páginas;. São selecionados local e hora para a reunião de levantamento. É escolhido um facilitador; 4. Membros da equipe de software e de outros departamentos são convidados a comparecer; 5. A solicitação do produto é distribuída a todos os participantes antes da data da reunião; Levantamento

47 Levantamento. Coleta colaborativa de requisitos Cenário resumido 6. Enquanto o dia da reunião não chega, é solicitado a cada participante que faça uma lista dos objetos que fazem parte do ambiente que cerca o sistema, objetos que serão produzidos pelo sistema e objetos que serão utilizados pelo sistema para desempenhar sua função; 7. É solicitado também a cada participante que faça uma outra lista de serviços (processos e funções) que manipulam ou interagem com os objetos; 8. São desenvolvidas listas de restrições (custo, tamanho, regras de negócio) e critérios de desempenho (velocidade, desempenho, precisão etc). Estas listas não devem ser enormes e exaustivas. Levantamento

48 Levantamento. Coleta colaborativa de requisitos Cenário resumido (exemplo) descrito por uma pessoa do marketing. Nossa pesquisa indica que o mercado de sistema de gestão residencial esta crescendo a uma taxa de 40% ao ano. A primeira função do CasaSegura que levaremos ao mercado deve ser a função de segurança residencial. A maioria das pessoas está familiarizada com sistemas de alarme, assim essa seria uma venda fácil Levantamento

49 Levantamento. Coleta colaborativa de requisitos Cenário resumido (exemplo) descrito por uma pessoa do marketing. A função de segurança residencial protegeria contra e/ou reconheceria várias situações indesejáveis tais como entrada ilegal, fogo, inundação, níveis de monóxido de carbono e outras. Ela usará nossos sensores sem fio para detectar cada situação, poderá ser programada pelo proprietário e discará automaticamente para a agência de monitoração sempre que uma situação for detectada. Levantamento

50 Levantamento. Coleta colaborativa de requisitos Cenário resumido. Quando a reunião começa, o primeiro tópico de discussão é a necessidade e a justificativa do produto;. Cada participante apresenta suas listas para discussão. As listas podem ser pinduradas nas paredes da sala usando grandes folhas de papel ou escritas em um quadro. Alternativamente, poderá ser colocada em um site ou em um ambiente de conversação ou mensagens instantâneas salvas posteriormente. O ideal é que cada lista possa ser combinada, as entradas apagadas e adições possam ser feitas. Neste estágio, críticas e debates são proibidos. Levantamento

51 Levantamento. Coleta colaborativa de requisitos Cenário resumido. Uma lista combinada é criada pelo grupo. A lista elimina redundâncias, adiciona qualquer idéia nova que tenha surgido durante a discussão, mas não apaga nada; 4. Depois de criadas as listas, o facilitador coordena a reunião para desenvolvimento de uma lista de consenso em cada assunto (objetos, serviços, restrições etc.); 5. Completadas as listas de consensos, a equipe é subdividida em equipes menores para desenvolvimento de miniespecificações. Levantamento

52 Levantamento. Coleta colaborativa de requisitos Exemplo de miniespecificação: O Painel de Controle é uma unidade montada na parede que tem o tamanho x cm. Ele tem conectividade sem fio a sensores e a um PC. A interação com o usuário ocorre por meio do teclado padrão de teclas. Um mostrador LCD de 5 x 5 cm, aproximadamente, fornece um feedback ao usuário. O software fornece prompts interativos, eco e funções similares. Levantamento

53 Levantamento. Cenários de usuários À medida que os requisitos são coletados, uma visão geral das funções e características do sistema começam a se materializar. A equipe agora deverá procurar entender como essas funções e características serão utilizadas por diferentes classes de usuários. Para isto deverá ser construído cenários de usuários ou casos de uso para o sistema que deverá ser construído. Levantamento

54 Levantamento. Produtos de trabalho do Levantamento Uma declaração da necessidade ou viabilidade; Uma afirmação limitada do escopo do sistema ou do produto; Uma lista dos clientes, usuários e outros interessados que participaram do levantamento de requisitos; Uma descrição do ambiente técnico do sistema; Uma lista de requisitos (preferenciamente organizadas por função) e as restrições de domínio; Um conjunto de cenários de uso que fornecem informações sobre o uso do sistema sob diferentes condições de operação; Quaisquer protótipos desenvolvidos para definir melhor os requisitos. Levantamento

55 Elaboração Desenvolvimento de Casos de Uso Um caso de uso conta uma história, sobre como um usuário interage com um sistema, sob seu ponto de vista. Pode ser representado por: Texto narrativo Delineamento de tarefas ou interações Descrição baseada em modelo Diagramas Elaboração

56 Elaboração Desenvolvimento de Casos de Uso Vamos assistir a algumas demonstrações em vídeo. Elaboração

57 Negociação de Requisitos Bom seria se esse processo fosse executado: Concepção Levantamento Elaboração Codificar!!! O cliente e os engenheiros entram em um processo de negociação. Negociação

58 Negociação de Requisitos O cliente será solicitado a ponderar sobre: As funcionalidades O desempenho Outras características em face do custo e do prazo As melhores negociações buscam um resultado ganha-ganha, isto é, o cliente ganha por obter o sistema ou produto que satisfaça à maioria das necessidades e a equipe de software ganha por trabalhar com orçamentos e prazos realistas e realizáveis. [PRESSMAN] Negociação

59 Negociação de Requisitos Atividades [BOEHM]. Identificação dos interessados-chave do sistema ou subsistema. Determinação das condições de ganho dos interessados.. Negociação das condições de ganho dos interessados para reconciliá-las em um conjunto de condições de ganha-ganha para todos os envolvidos (inclusive a equipe de software) São condições importantes para que o processo possa seguir para as atividades subsequentes. Negociação

60 Negociação de Requisitos Diretrizes. Reconheça que não é um competição. Trace uma estratégia. Ouça atentamente 4. Focalize nos interesses de outras partes 5. Não deixe a coisa ficar pessoal 6. Seja criativo 7. Esteja pronto a se comprometer Negociação

61 Especificação de Requisitos Utilização das mesmas práticas contidas na etapa de elaboração, porém a ser realizado em um nível mais detalhado. Inicia-se a fase de Projeto ou Design! Escreveremos coisas específicas para a equipe técnica. Especificação

62 Validação de Requisitos Os requisitos são priorizados pelo cliente Os requisitos são agrupados em pacotes de requisitos O objetivo é implementar o software em incrementos Validação

63 Validação de Requisitos Revisão da análise trata das seguintes questões:. Cada requisito está consistente com o objetivo global do sistema?. Todos os requisitos foram especificados no nível de abstração adequado? Isto é, algum requisito fornece um nível de detalhe técnico inadequado neste estágio?. O requisito é realmente necessário ou pode não ser essencial para o objetivo do sistema? 4. Cada requisito é limitado e não ambíguo? 5. Cada requisito tem atribuição (fonte)? 6. Algum requisito conflita com outros requisitos? Validação

64 Validação de Requisitos Revisão da análise trata das seguintes questões: 7. Cada requisito é realizável no ambiente técnico que vai alojar o sistema ou produto? 8. Cada requisito pode ser testado quando tiver implementado? 9. O modelo de requisitos reflete adequadamente a informação, função e comportamento do sistema a ser contruído? Ferramenta: Planilha de validação Validação

65 Bibliografia Referência Bibliográfica Sommerville. Engenharia de Software. 8ª ed. São Paulo: Pearson Addison-Wesley, 007. Pressman, S. R. Engenharia de Software. 6ª edição. São Paulo: McGraw-Hill, 006. Boehm, B.; Egyed, A., Software Requirements Negociation: Some Lessons Learned, Proc. Intl. Conf. Software Engineering, ACM/IEEE, 998, p