Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Transcrição

1 INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa clayton.maciel@ifrn.edu.br 2 Introdução: Os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais. Eles refletem, portanto, as necessidades dos clientes e o que eles esperam de um sistema computacional. Segundo IEEE, engenharia é: Processo de aquisição, refinamento e verificação das necessidades do cliente, com o objetivo de obter uma especificação correta e completa dos requisitos Introdução (continuação): De acordo com Boehm, a Engenharia de Requisitos é uma disciplina para desenvolver uma especificação completa, consistente e não ambígua do software; um acordo entre as partes descrevendo o que o produto de software irá fazer. B. Meyer acrescenta que especificar o documento de um software é definir, de uma forma completa e não ambígua, as características externas do software oferecidas aos usuários. Clayton Maciel Costa clayton.maciel@ifrn.edu.br 3 Clayton Maciel Costa clayton.maciel@ifrn.edu.br 4 Níveis de descrição: 1. Requisitos de usuário: são declarações, em uma linguagem natural, de quais serviços são esperados do sistema e as restrições sob as quais ele deve operar. 2. Requisitos de sistema: definem, detalhadamente, as funções, os serviços e as restrições operacionais do sistema de forma precisa. Ele deve definir exatamente o que será implementado. Leitores de diferentes tipos de especificação: Requisitos de usuário Requisitos de sistema Gerente de clientes Usuários finais de sistemas Gerentes de fornecedores Arquitetos de sistemas Usuários finais de sistemas Arquitetos de sistemas Desenvolvedores de software Clayton Maciel Costa clayton.maciel@ifrn.edu.br 5 Clayton Maciel Costa clayton.maciel@ifrn.edu.br 6 1

2 Exemplos de tipos de especificação: 1. Requisitos de usuário: LIBSYS deve ter o acervo de livros sempre atualizado. 2. Requisitos de sistema: 1.1 Ao solicitar um documento ao LIBSYS, deve ser apresentado ao solicitante um formulário que registra os detalhes do usuário e da solicitação feita. 1.2 Os formulários de solicitação do LIBSYS devem ser armazenados no sistema durante cinco anos, a partir da data de solicitação. (... ) Tipos : 1. Requisitos funcionais: são as declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Em alguns casos também se diz o que o sistema não deve fazer. 2. Requisitos não funcionais: são restrições sobre os serviços ou as funções oferecidas pelo sistema. Aplicam-se geralmente ao sistema como um todo e podem ser requisitos de produto, organizacionais ou externos. Clayton Maciel Costa clayton.maciel@ifrn.edu.br 7 Clayton Maciel Costa clayton.maciel@ifrn.edu.br 8 Tipos não funcionais: 1. Requisitos de produto: especificam o comportamento do produto. Exemplos: rapidez com que o sistema deve operar e quanto de memória ele requer, requisitos de confiabilidade que definem a taxa aceitável de falhas, portabilidade e usabilidade. 2. Requisitos organizacionais: são derivados das políticas e procedimentos da organização do cliente e do desenvolvedor. Exemplos: padrões de processos que devem ser usados, requisitos de implementação como a linguagem de programação ou o método de projeto usado. 3. Requisitos externos: abrange os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. Exemplos: interoperabilidade, requisitos legais e éticos. Clayton Maciel Costa clayton.maciel@ifrn.edu.br 9 Qualidade dos requisitos: Os requisitos de software devem possuir um alto grau de qualidade, visto que os processos posteriores, do ciclo de desenvolvimento de sistemas, dependem deles. Para alcançar esta qualidade exigida os requisitos devem possuir algumas características: claros completos sem ambiguidades implementáveis testáveis Clayton Maciel Costa clayton.maciel@ifrn.edu.br 10 Processo de engenharia : Estudo de viabilidade Relatório de viabilidade Elicitação e análise Modelos de sistema Especificação Requisitos de usuário e de sistemas Validação Documento Estudo de viabilidade: É um estudo breve e focalizado que procura responder a uma série de questões, e a partir destas construir um relatório que recomenda se vale a pena ou não prosseguir com os processos de engenharia e de desenvolvimento do sistema. Abaixo temos estas questões: 1. O sistema contribui para os objetivos gerais da organização? 2. O sistema pode ser implementado com tecnologia atual e dentro das restrições definidas de custo e prazo? 3. O sistema pode ser integrado a outros sistemas já implantados? Clayton Maciel Costa clayton.maciel@ifrn.edu.br 11 Clayton Maciel Costa clayton.maciel@ifrn.edu.br 12 2

3 Estudo de viabilidade (continuação): Para responder as três questões anteriores é preciso falar com gerentes de departamentos em que o sistema será usado, engenheiros de software familiarizados com o tipo de sistemas, especialistas em tecnologia e usuários finais do sistema. Este estudo leva de duas a três semanas. 1. Como a organização se comportaria se esse sistema não fosse implementado? 2. Quais são os problemas com os processos atuais e como o novo sistema ajudaria a reduzir esses problemas? 3. Qual será a contribuição direta do sistema para os objetivos e requisitos da empresa? 4. As informações podem ser transferidas e recebidas de outros sistemas da organização? 5. O sistema requer tecnologia que ainda não foi usada na organização? 6. O que deve ser apoiado pelo sistema e o que não precisa ser apoiado? Clayton Maciel Costa clayton.maciel@ifrn.edu.br 13 Elicitação e análise : Nesta atividade, os engenheiros de software trabalham com os clientes e os usuários finais do sistema para aprender sobre o domínio da aplicação, quais serviços o sistema deve fornecer, o desempenho esperado pelo sistema, restrições de hardware, etc. Clayton Maciel Costa clayton.maciel@ifrn.edu.br 14 Elicitação e análise (continuação): A elicitação e a compreensão dos requisitos dos stakeholders são difíceis devido a várias razões: 1. Os stakeholders frequentemente não sabem o que querem do sistema de computador a não ser em termos gerais. 2. Os stakeholders expressam os requisitos naturalmente em seus próprios termos e com o conhecimento implícito de seu trabalho. 3. Diferentes stakeholders possuem diferentes requisitos, expressos de diferentes formas. 4. Fatores políticos podem influenciar os requisitos do sistema. 5. O ambiente econômico e de negócios sobre o qual a análise é realizada é dinâmico. Processo de elicitação e análise : Classificação e organização Obtenção de requisitos Priorização e negociação de requisitos Documentação Clayton Maciel Costa clayton.maciel@ifrn.edu.br 15 Modelo genérico Clayton Maciel Costa clayton.maciel@ifrn.edu.br 16 Obtenção : É o processo de interação com os stakeholders do sistema para coletar seus requisitos. Os requisitos de domínio são também descobertos durante essa atividade, provenientes dos stakeholders e da documentação. Algumas técnicas para obtenção desses requisitos são: Entrevistas Brainstorm Storyboards Casos de uso Role playing Prototipagem Clayton Maciel Costa clayton.maciel@ifrn.edu.br 17 Obtenção : entrevista É uma técnica simples e direta. Precisamos saber: Quem são os usuários? Quem são os clientes? As necessidades deles são diferentes? Onde a solução desse problema pode ser encontrada? Resultado: repositório. IMPORTANTE: Questionário não substitui uma entrevista. Clayton Maciel Costa clayton.maciel@ifrn.edu.br 18 3

4 Obtenção : entrevista com gerente 1. Qual é sua visão do problema? 2. Quais são as mudanças desejadas com a solução do problema? 3. Em que ambiente essa solução deverá funcionar? 4. Qual é a abrangência geográfica e número de usuários que estarão utilizando a solução? 5. Como é o parque tecnológico existente (Servidores, Desktops, Topologia da Rede, Internet)? 6. Quais são os ambientes existentes na empresa (Desenvolvimento, Testes, Produção, etc...); 7. Como serão as integrações entre os sistemas? 8. Haverá migração de dados? Em que estrutura estão esses dados? 9. Existe alguma padronização a ser seguida e/ou algum artefato de sua metodologia que deverá ser gerado e entregue? 10. Como está estruturada a equipe de TI? Clayton Maciel Costa clayton.maciel@ifrn.edu.br 19 Obtenção : entrevista com o usuário 1. Qual é sua visão do problema? 2. Quais são as mudanças desejadas com a solução do problema? 3. Que facilidades você espera do sistema? 4. Qual informação do negócio é a mais difícil de processar (trabalho braçal, formato do dado, baixa navegabilidade em sistemas existentes)? 5. Quais são as macro funcionalidades necessárias para os sistema? 6. Quais são as pessoas que se relacionam com o sistema? 7. Como são as telas imaginadas para o sistema (esboços de telas)? 8. Quais são as importações e exportações de dados necessárias para o funcionamento do sistema (detalhar layout dos arquivos / fontes de dados)? Clayton Maciel Costa clayton.maciel@ifrn.edu.br 20 Obtenção : entrevista com outros Manutenções: 1. Quais são as dificuldades de manutenção do sistema? 2. Qual é a qualidade das estruturas do banco de dados? 3. Qual é a qualidade do código fonte do aplicativo? 4. A documentação do sistema é suficiente e compreensível? 5. Como é a demanda (freqüência) de manutenção (corretiva, melhorias, legal)? 6. Quais são os pontos de gargalo do sistema atual? Obtenção : brainstorm É uma técnica em que as pessoas colocam tudo que vier na cabeça com relação ao projeto. Ela é muito útil quando existem diversos interessados no projeto. Clayton Maciel Costa clayton.maciel@ifrn.edu.br 21 Clayton Maciel Costa clayton.maciel@ifrn.edu.br 22 Obtenção : brainstorm É dividido em duas etapas: Na primeira: anota-se todas as idéias que surgirem, sem que sejam questionadas. Neste momento o que importa mais é a quantidade, não deixe de anotar nada. Na segunda: debate-se com o grupo para ir refinando as idéias apresentadas anteriormente. Deixe as regras bem claras, e defina uma pessoa (facilitador) para comandar a reunião, para garantir que as regras sejam respeitadas. Obtenção : storyboarding Corresponde a qualquer técnica que expressa o comportamento do sistema, projeto ou intenção de implementação pela perspectiva do usuário. Esta técnica foi utilizada inicialmente no cinema e desenhos animados, representando um esboço dos personagens e da história. Pode ser efetiva no desenvolvimento de um novo projeto, na fase inicial, para identificar requisitos de alto nível, aqueles mais macros. Clayton Maciel Costa clayton.maciel@ifrn.edu.br 23 Clayton Maciel Costa clayton.maciel@ifrn.edu.br 24 4

5 Obtenção : casos de uso Descreve a funcionalidade proposta para o novo sistema. Ele representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema. É uma unidade de um trabalho significante. Ex: o "login para o sistema", "registrar no sistema" e "criar pedidos". ATENÇÃO: um caso de uso tem uma descrição ao qual descreve a funcionalidade que irá ser construída no sistema proposto. Obtenção : role playing Esta técnica, conhecida também como etnografia, consiste em observar o usuário executando determinada tarefa, no dia-a-dia do seu trabalho, ou, até mesmo, você fazendo o trabalho deste usuário, para identificar suas dificuldades e necessidades, sentindo na pele como é realizar a tarefa. Muito útil quando o usuário não consegue identificar ou transmitir as informações necessárias para a identificação dos requisitos. Clayton Maciel Costa clayton.maciel@ifrn.edu.br 25 Clayton Maciel Costa clayton.maciel@ifrn.edu.br 26 Obtenção : prototipagem Criação, apresentação e debate de modelos de interação não funcionais que ajudem a ilustrar como o sistema se deverá comportar, permitindo assim obter feedback mais detalhado dos stakeholders sobre o sistema. É a atividade de desenvolvimento de uma versão inicial do sistema baseada no atendimento dos requisitos ainda pouco definidos, permitindo a descoberta de falhas difíceis de serem encontradas na comunicação verbal. Clayton Maciel Costa clayton.maciel@ifrn.edu.br 27 Obtenção : prototipagem Um processo que propõe a criação de um protótipo de software objetiva apoiar a fase levantamento a fim de prevenir as possíveis falhas no sistema. Um protótipo simula a aparência e funcionalidade do software permitindo que os clientes, analistas, desenvolvedores e gerentes percebam os requisitos do sistema podendo interagir, avaliar, alterar e aprovar as características mais marcantes na interface e funções. IMPORTANTE: os protótipos podem ser evolutivos ou descartáveis. Clayton Maciel Costa clayton.maciel@ifrn.edu.br 28 Validação : Dedica-se a mostrar que os requisitos realmente definem o sistema que o usuário deseja. A validação se sobrepõe à análise; está relacionada à descoberta de problemas com os requisitos. Lembrando que a descoberta tardia de erros relacionados aos requisitos geram um alto custo em qualquer projeto de software. Validação (continuação): Durante o processo de validação, devem ser realizadas verificações nos requisitos do documento. Essas verificações incluem: Verificações de validade Verificações de consistência Verificações de completeza Verificações de realismo Clayton Maciel Costa clayton.maciel@ifrn.edu.br 29 Clayton Maciel Costa clayton.maciel@ifrn.edu.br 30 5