Fundamentos da Engenharia de Software - Volume 2

Fundamentos da Engenharia de Software Danielle Rousy Dias da Silva Volume 2 Sumário Apresentação 4 Conhecendo o Volume 2 5 Capítulo 1 Engenharia de Requisitos 6 11 Requisitos de Software 6 12 Engenharia de Requisitos ER e Engenharia de Software ES 10 13 Ponto de partida para um processo de ER 12 14 Processo Genérico da ER 13 Fundamentos da Engenharia de Software Conhecendo o Volume 2 Neste segundo volume você irá encontrar o Módulo 2 da disciplina Fundamentos da Engenharia de Software Para facilitar seus estudos veja a organização desta segunda unidade Módulo 2 Áreas de Conhecimento Base da Engenharia de Software Carga Horária do Módulo 2 15 haula Objetivo do Módulo 2 Apresentar algumas das áreas básicas de conhecimento da Engenharia de Software como Engenharia de Requisitos Análise e Projeto de Software e Verificação validação e testes de software Conteúdo Programático do Módulo 2 Engenharia de requisitos Análise e projeto de software Verificação validação e teste de software Fundamentos da Engenharia de Software 6 Capítulo 1 Engenharia de Requisitos Vamos conversar sobre o assunto Um dos problemas mais comuns encontrados nos softwares ainda hoje está relacionado direta ou indiretamente com a dificuldade de especificar corretamente os requisitos do software Por exemplo é comum encontrarmos softwares com requisitos especificados incorretamente ou com especificações incompletas Dessa forma a fase de levantamento de requisitos normalmente encontrada nos ciclos de desenvolvimento do software assume um importante papel na qualidade final do produto e é destinada a melhorar os resultados dessa fase em que a Engenharia de Requisitos é aplicada Neste capítulo explanaremos do que se trata a Engenharia de Requisitos e qual o seu papel no ciclo de desenvolvimento de software Você conhecerá sobre O que é Engenharia de Requisitos ER Qual o seu papel dentro do ciclo de desenvolvimento do software O que é um requisito de software e quais seus tipos Quais as fases de atividades associadas a especificação de requisitos 11 Requisitos de Software Vimos no fascículo anterior que o desenvolvimento de software é complexo por natureza Muito dessa complexidade está associada à especificação do que o software irá fazer Entenda como requisito neste caso a definição das necessidades e restrições do software que contribuem para a solução de algum problema real do mundo por exemplo os requisitos que você utiliza para acessar o ambiente virtual deste curso como envioleitura de email chat envio de tarefas etc Existem diferentes definições encontradas na literatura técnica para requisitos Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos Fundamentos da Engenharia de Software 7 As descrições das funções e restrições são os requisitos do sistema Um requisito é uma propriedade que o software deve exibir para resolver algum problema no mundo real Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato padrão especificação ou outro documento formalmente imposto Percebese que as citações encontradas definem o mesmo conceito sob diferentes perspectivas Podemos entender requisitos como sendo o conjunto de necessidades explicitadas pelo clienteusuário que deverão ser atendidas para solucionar um determinado problema do negócio no qual o clienteusuário faz parte É importante estar atento para esta definição embora o requisito seja definido pelo cliente nem sempre o que o cliente quer é o que o negócio precisa Cabe à equipe que estar levantando os requisitos identificar a real necessidade do negócio Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessárias que o software deve possuir 1 para que o usuário possa resolver um problema ou atingir um objetivo ou 2 para atender as necessidades ou restrições da organização ou dos outros componentes do sistema Os requisitos são importantes para Estabelecer uma base de concordância entre o cliente e o fornecedor sobre o que o software fará Fornecer uma referência para a validação do produto final Reduzir o custo de desenvolvimento requisitos mal definidos causam retrabalho De acordo com Presman 2006 existem três tipos de requisitos de usuário de sistemas e de software Os requisitos de usuário representam declarações em linguagem natural e também em diagramas sobre as funções que o sistema deve fornecer e as restrições sob as quais deve operar Os requisitos do sistema constituem um documento estruturado que estabelece detalhadamente as funções e as restrições de sistema Escrito como um contrato entre o cliente e o desenvolvedor E por último se tem os requisitos do software que compreendem uma descrição detalhada do software que serve como base para projeto e a implementação Cada um desses tipos de requisitos atende a um conjunto específico de público Figura 11 Figura 11 Tipos de requisitos e seus interessados Fundamentos da Engenharia de Software 8 No decorrer deste capítulo quando falarmos de requisitos estaremos nos referindo aos requisitos do software Neste contexto os requisitos expressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do usuáriocliente e em geral independem da tecnologia empregada na construção da solução sendo a parte mais crítica e propensa a erros no desenvolvimento de software Tradicionalmente os requisitos do software são separados em requisitos funcionais e nãofuncionais Outro tipo de requisito é o de domínio Estes se originam do domínio da aplicação do sistema e que refletem características desse domínio mas eles sempre se encaixarão em uma dessas duas categorias requisitos funcionais e não funcionais 111 Requisitos Funcionais São requisitos diretamente ligados a funcionalidade do software descrevem as funções que o software deve executar Por exemplo considerando o software que você utiliza para realizar este curso moodle alguns exemplos são O software deve permitir o cadastro dos alunos tutores e professores O software deve permitir a geração de relatórios sobre o desempenho dos alunos tutores e professores no semestre O software deve permitir o enviorecebimento de mensagens eletrônicas Outros exemplos de requisitos funcionais são O software deve possibilitar o cálculo dos gastos diários semanais mensais e anuais com pessoal O software deve emitir relatórios de compras a cada quinze dias Os usuários devem poder obter o número de aprovações reprovações e trancamentos em todas as disciplinas por um determinado período de tempo A especificação de um requisito funcional deve determinar o que se espera que o software faça sem a preocupação de como ele faz É importante diferenciar a atividade de especificar requisitos da atividade de especificação que ocorre durante o projeto do software No projeto do software devese tomar a decisão de quais as funções o sistema efetivamente terá para satisfazer àquilo que os usuários querem 112 Requisitos Nãofuncionais São requisitos que expressam condições que o software deve atender ou qualidades específicas que o software deve ter Em vez de informar o que o sistema fará os requisitos nãofuncionais colocam restrições no software como manutenibilidade usabilidade desempenho custos e várias outras Alguns exemplos são O software deve ser compatível com os browsers IE versão 50 ou superior e Firefox 10 ou superior O software deve garantir que o tempo de retorno das consultas não seja maior do que 5 segundos A base de dados deve ser protegida para acesso apenas de usuários autorizados O tempo de resposta do sistema não deve ultrapassar 30 segundo O software deve ser operacionalizado no sistema Linux Fundamentos da Engenharia de Software 9 O tempo de desenvolvimento não deve ultrapassar seis meses Requisitos não funcionais dizem respeito ao sistema como um todo Alguns podem restringir o processo que é utilizado para desenvolver o sistema ditar um sistema CASE específico linguagem de programação ou método de desenvolvimento Podem ser mais críticos que requisitos funcionais A falha em atender um requisito não funcional de sistema pode inutilizar o sistema Os requisitos não funcionais subdividemse em três categorias de produtos organizacionais e externos Os de produto especificam o comportamento do software como inclusive já citamos alguns Por exemplo velocidade de execução confiabilidade portabilidade facilidade de uso etc Os organizacionais são consequência de políticas de procedimentos nas organizações do cliente e do desenvolvedor por exemplo padrões de processos que devem ser utilizados requisitos de implementação E os externos são procedentes de fatores externos ao sistema e a seu processo de desenvolvimento por exemplo requisitos de interoperabilidade requisitos legais e os requisitos éticos Devido à sua própria definição requisitos nãofuncionais também são esperados ser mensuráveis caso contrário seria impossível validar a corretude e completude do requisito Assim devese associar forma de medidareferência a cada requisito não funcional elicitado Alguns exemplos dessas medidas são ilustradas no quadro a seguir Quadro 11 Medidas para requisitos nãofuncionais Propriedade Medida Velocidade Transações processadasseg Tempo de resposta do usuárioevento Tamanho K bytes No de chips de RAM Facilidade de uso Tempo de treinamento No de quadros de ajuda Confiabilidade Tempo médio de falhas Probabilidade de indisponibilidade Taxa de ocorrência de falhas Robustez Tempo de reinício após falha Percentual de eventos causando falhas Probabilidade de corrupção de dados após falha Portabilidade Percentual de declarações dependentes do destino No de sistemas destino A necessidade de se estabelecer os requisitos de maneira de forma precisa é crítica na medida em que o tamanho e a complexidade do software aumenta Os requisitos exercem influência uns sobre os outros Por exemplo o requisito do software de ter grande portabilidade por exemplo ser implementado em Java pode implicar em que o requisito desempenho não seja satisfeito programas em Java são em geral mais lentos Uma boa especificação de requisitos deve ser Clara e nãoambígua Fundamentos da Engenharia de Software 10 Para Refletir Construir um sistema de software com base em requisitos inconsistentes e mal definidos é como construir uma casa sem alicerce na areia Você sabia que A área de Engenharia de requisitos é uma subárea da Engenharia de Software e surgiu em 1993 com a realização do I International Symposium on Requirements Engineering Completa Correta Compreensível Consistente Concisa Confiável 12 Engenharia de Requisitos ER e Engenharia de Software ES O processo de definição de requisitos é uma interface entre os desejos e necessidades dos clientes e a posterior implementação desses requisitos em forma de software e compreendem uma das primeiras atividades do ciclo de produção de um software Entender as necessidades e atender os desejos dos clientes sempre foi colocado como um dos maiores desafios da Engenharia de Software A postura da Engenharia de Requisitos é a de prover ao Engenheiro de Software métodos técnicas e ferramentas que auxiliem o processo de compreensão e registro dos requisitos que o software deve atender Diferentemente de outras subáreas da engenharia de software a área de requisitos tem que lidar com conhecimento interdisciplinar envolvendomuitas vezes aspectos de ciências sociais e ciência cognitiva pois você precisará saber lidar e compreender pessoas os requisitos partiram delas e chegaram a elas em forma de software No contexto da Engenharia de Software a área de engenharia de requisitos está concentrada com a elicitação análise especificação validação e gerência de requisitos de software Figura 12 Já é consolidado para a indústria de software que quando a elicitação análise especificação e validação são feitas incorretamente ou são incompletas podem fazer com que o produto final de software falhe em suas funções e isso é algo que necessita ser evitado sempre Fundamentos da Engenharia de Software 11 Para Refletir Por que será tão difícil obter um entendimento claro do que o cliente deseja Discuta com seus colegas de curso Figura 12 Engenharia de requisitos ER Neste ponto podemos citar alguns dos principais objetivos da ER são eles Estabelecer uma visão comum entre o cliente e a equipe de projeto em relação aos requisitos que serão atendidos pelo projeto de software Registrar e acompanhar requisitos ao longo de todo o processo de desenvolvimento Documentar e controlar os requisitos alocados para estabelecer uma linha de referência de versões para uso gerencial e da engenharia de software Manter planos artefatos e atividades de software consistentes com os requisitos alocados Para apoiar o alcance destes objetivos é importante que se tenha um processo de engenharia de requisitos bem definido Um processo de engenharia de requisitos é um conjunto estruturado de atividades a serem seguidas para criar validar e manter um documento de requisitos Poucas organizações têm um processo de ER explicitamente definido e padronizado Entretanto sugerese que cada organização deva desenvolver um processo adequado à sua realidade Contudo as entradas e saídas desse processo normalmente são as apresentadas na Figura 13 Fundamentos da Engenharia de Software 12 Figura 13 Entrada e saída do processo de ER 13 Ponto de partida para um processo de ER Segundo o SWEBOK 2004 o processo da ER precisa ser definido segundo os seguintes pontos Definição do ciclo de vida do processo de ER este ponto se refere à definição de como as atividades de elicitação análise especificação e validação de requisitos serão executadas A ideia é semelhante ao ocorrido na definição do processo de desenvolvimento de software comentado no fascículo I você se recorda Por exemplo para um software em que os requisitos ainda não são claros nem para o cliente nem os usuários poderia ser definido um ciclo de vida interativo e incremental ou um ciclo baseado em prototipação em que pequenos conjuntos de requisitos são elicitados analisados especificados e validados de forma incremental até que os requisitos do software estejam completamente especificados É importante ressaltar que a definição do ciclo ou modelo de processo está estritamente ligada com a análise do software a ser produzido se ele é critico Se é embarcado Se é de automação Se é um jogo etc Identificação dos atores este ponto se trata da definição das pessoas que estarão envolvidas direta ou indiretamente no processo de ER como por exemplo os engenheiros de software testadores clientes usuários arquitetos etc E em que atividades e fases do processo de ER esses atores estarão envolvidos e pelo que serão responsáveis Definição dos processos de suporte e gerenciamento ao processo de ER todo processo necessita definir mecanismo que possibilitem o gerenciamento e controle da execução e resultados das atividades deles Normalmente isto é feito adotando processos secundários que dão suporte ao gerenciamento Por exemplo você já imaginou como são gerenciados os requisitos do software que são liberados em Fundamentos da Engenharia de Software 13 cada versão Como saber que requisitos mudaram de uma versão para outra O processo de ER não especifica essa atividade mas é necessário identificar processos de suporte para realizar tal atividade senão a gerência dos requisitos ficará caótica e dificultará a manutenção certa do software Definição dos processos de melhorias do processo de ER outro ponto importante a se pensar é definir como o processo de ER será melhorado com o uso e experimentação Esses são os pontos básicos para iniciar um processo de ER em sua empresa por exemplo ou mesmo para o desenvolvimento de um software específico Assim para definir um processo para ER você precisará primeiramente definir o modelo de ciclo de vida que o processo executará os atores do processo as atividades e os mecanismos de gerenciamento suporte e melhoramento 14 Processo Genérico da ER De uma forma geral podemos estabelecer um processo genérico contendo as atividades mais comuns encontradas como as apresentadas na Figura 14 Essas atividades são encontradas por exemplo no especificado por PRESSMAN 2006 SOMMERVILLE 2007 SOARES 2005 para essa subárea da Engenharia de Software Não existe um processo ideal de engenharia de requisitos mas no geral possuem a seguinte ordem iniciase com a elicitação de requisitos juntamente com análise de requisito seguida das negociações Após essas fases os requisitos são documentados e validados Paralelamente a todas essas atividades é realizado o gerenciamento de requisitos que consiste em administrar as inevitáveis mudanças dos requisitos propostos O intuito com isso é ter ao final os requisitos acordados com os interessados no sistema e a especificação dos requisitos Normalmente o que se observa na indústria de software é que a especificação dos requisitos de software quase sempre é feita de forma interativa e incremental durante o ciclo de desenvolvimento de software isto é os requisitos são desenvolvidos em pequenos pedaços Fundamentos da Engenharia de Software 14 Você sabia que O termo stakeholder compreende todos os envolvidos em um processo que pode ser de caráter temporário como um projeto ou duradouro como o negócio de uma empresa ou a missão de uma organização No caso do desenvolvimento de software são por exemplo os desenvolvedores gerentes clientes e usuários Figura 14 Fases e atividades do processo de ER 141 Elicitação de Requisitos Essa primeira fase é normalmente executada pelo engenheiro de requisitos ou de software ou analista juntamente com outros stakeholders do projeto de software clientes e demais pessoas interessadas e candidatas a usuárias do software a ser produzido Neste caso o engenheiro de requisitos utiliza alguma ou um conjunto de técnicas para descobrir elicitar os requisitos do software a ser desenvolvido incluindo as informações do negócio ou problema que restringem este software Algumas das técnicas mais conhecidas são técnicas de leitura de documentos observação entrevistas reuniões questionários antropologia participação ativa dos atores e engenharia reversa Iremos falar de algumas dessas técnicas ainda nesse volume Os requisitos podem ser originados de várias fontes Por exemplo os requisitos podem ser descobertos do conhecimento do domínio no qual o software atuará podem ser originados dos stakeholders do ambiente operacional e organizacional no qual o software Fundamentos da Engenharia de Software 15 trabalhará dentre outras fontes O importante é que o responsável por essa elicitação tente cobrir o maior número de fontes possível para evitar especificações errôneas ambíguas e ou incompletas A atividade de levantamento de requisitos não é trivial apesar de aparentar o contrário Existe um conjunto grande e variado de fatores que a tornam complexa por exemplo Falta de conhecimento das suas reais necessidades ClienteUsuário com vaga noção do que precisa e do que um produto de software pode oferecer Falta de conhecimento do desenvolvedor do domínio do problema Desenvolvedor sem conhecimento adequado do domínio o que leva a decisões erradas Domínio do processo de levantamento de requisitos pelos desenvolvedores Desenvolvedor não ouve o que os clientesusuários têm a dizer e força suas próprias visões e interpretações Comunicação inadequada entre os desenvolvedores e usuáriosclientes usuários clientes incapazes de expressar suas necessidades apropriadamente significados diferentes a termos comuns Dificuldade do usuário tomar decisões Falta de entendimento sobre as consequências das decisões ou as alternativas possíveis Problemas de comportamento o levantamento de requisitos é um processo social conflitos e ambiguidades nos papéis que os usuários e desenvolvedores desempenham Questões técnicas complexidade crescente dos sistemas atuais Para auxiliar a superar estes problemas os responsáveis pela elicitação devem abordar os requisitos de maneira organizada Alguns passos são sugeridos para elicitação de requisitos Avaliar a viabilidade técnica e de negócio para o sistema proposto Identificar as pessoas que vão auxiliar a especificar os requisitos e compreender seus preconceitos organizacionais Definir o ambiente técnico no qual o sistema será instalado Identificar regras de domínio que limitam a funcionalidade ou desempenho do sistema ou produto que será construído Definir um ou mais métodos de elicitação de requisitos Solicitar participação de várias pessoas para que os requisitos sejam definidos a partir de diversos pontos de vista Identificar claramente a justificativa de existência para cada requisito registrado Identificar requisitos ambíguos que serão candidatos a prototipação Os produtos de trabalho a criar como consequência das atividades de elicitação de requisitos irão depender do tamanho do sistema ou produto que será construído Para a maioria dos sistemas estes produtos de trabalho incluem As necessidades e viabilidade estruturadas Fundamentos da Engenharia de Software 16 Para Refletir A parte mais árdua na construção de um software consiste exatamente em identificar o que construir Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma incorreta Nenhuma outra parte oferece tanta dificuldade para efetuar correções posteriores Fred Brook O limite de escopo do sistema ou produtos Uma lista de clientes usuários e outros stakeholders que participaram da atividade de elicitação de requisitos Uma descrição do ambiente técnico do sistema Uma lista de requisitos e as regras de domínio aplicáveis a cada um Um conjunto de cenários de uso capazes de prover uma ideia do uso do sistema ou produto sob diferentes condições de operação Qualquer protótipo que eventualmente tenha sido desenvolvido para melhor definir os requisitos Cada um destes produtos deve ser revisado por todas as pessoas que tenham participado da elicitação de requisitos Para facilitar e buscar um melhor resultado no processo de elicitação de requisitos há algumas técnicas propostas Não podemos dizer aqui qual a melhor ou pior tudo vai depender do contexto em que o software atuará e será desenvolvido O importante é você ter conhecimento delas e quando adequado usar uma a outra ou até mais de uma dependendo do momento do ciclo de desenvolvimento do software 1411 Algumas técnicas de elicitação de requisitos As técnicas de elicitação de requisitos são divididas em formais e informais onde as técnicas que pressupõem a construção de um modelo formal conceitual do problema que está sendo analisado ou de um protótipo do produto a ser construído são consideradas formais e as técnicas que se baseiam em interações com o usuáriocliente e comunicação estruturada são consideradas informais Dentre as principais técnicas temos a Entrevista É a técnica mais comum e mais utilizada na coleta de fatos pois nada mais é do que a comunicação entre entrevistado cliente por exemplo e entrevistador engenheiro ou analista por exemplo Segundo Kotonya 1998 há basicamente dois tipos de entrevista a entrevistas fechadas onde o engenheiro de requisitos procura as perguntas para um conjunto prédefinido de questões b entrevistas abertas onde não há agenda prédefinida e o engenheiro de requisitos discute de modo aberto o que os usuários querem do sistema Na Figura 15 mostramos algumas questões normalmente encontradas quando se usa essa técnica para elicitar os requisitos Essa técnica está condicionada a alguns fatores Influência do entrevistador nas respostas do clienteusuário convém que o entrevistador dê margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida Relação pessoal entre os intervenientes na entrevista Fundamentos da Engenharia de Software 17 Alguns exemplos de perguntas a responder 1 Quemm são o cliente e o usuário 2 Possuem necessidade diferentes 3 Qual é o problema 4 Como é resolvido atualmente 5 Qual a razão para resolvêlo 6 Qual o valor de uma solução bemsucedida 7 Onde mais uma solução pode ser encontrada Predisposição do entrevistado caso por exemplo o papel do entrevistado venha a ser afetado pela introdução de um sistema na organização este pode propositadamente dificultar o acesso à informação Capacidade de seguir um plano para a entrevista na ausência destes planos é natural que haja tendência para que os intervenientes se dispersem um pouco levando a que a entrevista demore mais tempo do que seria suposto Caso a entrevista se torne demasiado longa as pessoas podem cair na tentação de querer despachar sendo os últimos pontos da entrevista abordados de forma superficial ou podem nem chegar a ser abordados Figura 15 Perguntas a responder em uma entrevista b Questionário O emprego do Questionário se justifica quando se deseja coletar dados de pessoas fisicamente distantes ou que constituem um grupo numeroso de pessoas a serem inquiridas Para facilitar a sua elaboração devese inicialmente elaborar um esquema que possa congregar títulos de assunto de mesma natureza c Tempestade de ideias do inglês brainstorming Tratase de uma técnica realizada em um ambiente mais informal propício à criação de ideias para solução de um problema toda a ideia deve ser levada em consideração é proibido a critica a qualquer que seja a sugestão dada é encorajada a criação de ideias bizarras Ocorrem em um grupo de 6 a 12 pessoas com a presença de um moderador que é quem gerencia toda a discussão Uma das desvantagens dessa técnica é que pode demorar a se conseguir um ideia ou um conjunto delas que resolva o problema Essa é uma técnica muito utilizada no projeto de jogos digitais d Pesquisas a pesquisa institucional eou revisão bibliográfica deve ser a primeira técnica empregada em um levantamento pois oferece suporte às demais possibilitando um entendimento mais direcionado ao assunto a ser tratado A revisão bibliográfica consiste em pesquisar a literatura pertinente livros revistas especializadas legislação artigos etc e a pesquisa Institucional consiste basicamente em identificar na empresa trabalhos que já foram desenvolvidos sobre os assuntos estatuto social regimentos normas regulamentosmanuais instruções normativas relatórios etc e JADJoint Application Design Tratase do agrupamento de ferramentas Fundamentos da Engenharia de Software 18 Você sabia que Os casos de uso foram definidos por Ivar Jacobson tendo sido adotados pela linguagem UML Unified Modeling Language a qual tem sido considerada uma linguagem de modelagem padrão para a especificação de sistemas de software orientados a objetos cooperação e participação de todas as partes envolvidas desde os usuários até os profissionais de TI Segundo Damian 1997 JAD consiste de 5 fases definição do projeto pesquisa preparação para a sessão JAD a sessão JAD o documento final Um das dificuldades dessa técnica é justamente a comunicação efetiva entre pessoas de áreas muitas vezes distintas f Prototipação essa técnica consiste em construir a partir dos requisitos iniciais um protótipo do produto para ser testado pelo usuáriocliente O ponto forte desta atividade é apresentar muitas alternativas para o usuário antes de se gastar muito esforço para qualquer protótipo em particular O uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos por exemplo na identificação análise e validação O uso de protótipos deve ser considerado apenas mediante uma análise custobenefício já que os custos de desenvolvimento de um protótipo podem facilmente crescer sendo particularmente úteis em situações em que a interface com os utilizadores é para eles um aspecto crítico g workshop de requisitos consiste numa técnica usada através de uma reunião estruturada da qual devem fazer parte um grupo de analistas e um grupo representando o cliente para então obter um conjunto de requisitos bem definidos Ao contrário das reuniões promovese a interação entre todos os elementos presentes no workshop fomentando momentos de descontracção como forma de dinamizar o trabalho em equipe existindo um facilitador neutro cujo papel é conduzir o workshop e promover a discussão entre os vários intervenientes ainda que não tenha realmente poder de decisão As tomadas de decisão devem seguir processos bem definidos e devem resultar de um processo de negociação mediado pelo facilitador Uma técnica que é também útil em workshops é o uso de brainstorming tempestade de ideias como forma de gerar um elevado número de ideias numa pequena quantidade de tempo Como resultado dos workshops deve ser produzida documentação que reflita os requisitos e decisões tomadas sobre o sistema a implementar h Cenários uma forma de levar as pessoas a imaginarem o comportamento de um sistema é o uso de cenários Através de exemplos práticos descritivos do comportamento de um sistema os seus utilizadores podem comentar acerca do seu comportamento e da interação que esperam ter com ele Tratase de uma abordagem informal prática e aplicável a qualquer tipo de sistema Um exemplo de cenário de uso típico para um sistema da biblioteca seria Um aluno chega na biblioteca para procurar livrostexto dos cursos que está frequentando Ele entra no sistema e seleciona os cursos e obtém uma lista de todos os livrostexto e sua localização na biblioteca Seleciona a opção de bibliografia complementar e uma nova lista de livros e periódicos lhe é apresentada Ele então manda imprimir todas as referências encontradas O tipo mais comum de cenário é o caso de uso Os casos de uso constituem uma técnica baseada em cenários UML que identificam os agentes em uma interação e Fundamentos da Engenharia de Software 19 que descrevem a interação em si Um conjunto de casos de uso deve descrever todas as possíveis interações com o sistema De um modo geral os cenários devem incluir os seguintes elementos Estado do sistema no início do cenário Sequência de eventos esperada na ausência de erros no cenário Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como estes erros serão tratados Outras atividades que podem ser executadas ao mesmo tempo que as deste cenário Estado do sistema depois de o cenário terminar 142 Análise e negociação de requisitos Após descobrir os requisitos do software passase para a fase de análise e negociação de requisitos essa fase também não é muito trivial e exige muita experiência e maturidade dos engenheiros responsáveis por ela Nesta fase o objetivo é Identificar e resolver conflito entre os requisitos Definir os limites do software e como ele interagirá com o ambiente no qual será inserido Derivar os requisitos de software O objetivo da análise e negociação dos requisitos é estabelecer um acordo do conjunto de requisitos que são completos e consistentes Estes requisitos não devem ser ambíguos de forma que eles podem ser usados como uma base para o desenvolvimento do sistema Durante o processo de análise requisitos perdidos requisitos conflitantes requisitos ambíguos requisitos duplicados e requisitos irreais são normalmente descobertos Outra importante atividade realizada nessa fase é a definição de prioridades dos requisitos Este procedimento ajuda os stakeholders a definir as bases do sistema e a decidir sobre a arquitetura e a resolver os conflitos que surjam As atividades iniciais de análise dos requisitos levam à identificação de classes que representem adequadamente os conceitos expressos nos requisitos e à descoberta dos respectivos atributos e relacionamentos Esta parte da análise fornece o modelo lógico de dados equivalente a um modelo de entidade e relacionamentos que pode corresponder ao modelo conceitual de um banco de dados usado pelo produto 143 Documentação dos requisitos Esta atividade está relacionada com a descrição detalhada do sistema e dos requisitos do software na forma de um documento que é usado para registrar os requisitos dos stakeholders Muitas vezes essa atividade é intercalada com as atividades de elicitação análise e negociação dos requisitos Segundo Somerville e Kotonya 1997 o documento de requisitos descreve 1 Os serviços e as funções que o sistema deve prover 2 As limitações sobre as quais o sistema deve operar e as limitações nos processos usados para desenvolver o sistema Fundamentos da Engenharia de Software 20 3 As propriedades gerais do sistema 4 As definições de outros sistemas com o qual o sistema deve se integrar 5 As informações sobre o domínio da aplicação do sistema 6 As descrições sobre o hardware no qual o sistema irá executar 7 Registrar a estratégia sobre o ciclo de vida do sistema Esse documento também deve ser fácil de ser modificado e servir como ferramenta de referência para a manutenção Além disso é necessário um capítulo introdutório que contêm um resumo do sistema as necessidades de negócio suportadas pelo sistema e um glossário que explica a terminologia usada É importante lembrar que este documento não deve especificar detalhes de implementação ou algo parecido ele deve especificar o que o sistema deve fazer e não como Existe uma especificação que é a usada como declaração oficial dos requisitos do sistema Este documento normalmente chamado de Documento de Especificação de Requisitos Software Requirements Specification ou SRS inclui uma combinação dos requisitos do usuário e do sistema e tem diferentes utilidades para diferentes pessoas SOMMERVILLE e KOTONOYA 1997 Clientes confirmar a completude dos requisitos e propor alterações Gestores orçamentar o sistema e planejar o processo de desenvolvimento Engenheiros compreender o sistema a desenvolver Engenheiros testes desenvolver testes para validar o cumprimento dos requisitos Engenheiros manutenção compreender o sistema e a ligação entre as suas partes Existem diversos padrões para este documento embora não se possa apontar nenhum como o ideal Uma estrutura proposta pelo IEEE que é talvez a mais usada é o IEEEANSI 8301993 THAYER e DORFMAN 1993 contudo podemos citar o modelo de Volere 2006 e Sommerville 2007 Um pequeno esboço desses modelos é ilustrado na Figura 16 Fundamentos da Engenharia de Software 21 Figura 16 Esboco dos SRS segundo diversos modelos 144 Validação e verificação de requisitos Na atividade de validação de requisitos a preocupação é que os requisitos estejam definidos corretamente e assegurar que os requisitos satisfaçam as necessidades dos stakeholders e clientes Existem diferentes meios para a verificação no processo de validação de requisitos mas os grandes destaques são a verificação de novas ou diferentes funções no sistema verificação de consistência verificação na documentação de requisitos que definem todas as funções e restrições do sistema e verificação se os requisitos podem realmente ser implementados utilizando uma determinada tecnologia existente Para a verificação dos requisitos existe uma série de técnicas que podem ser utilizadas tais como 1 Revisões de requisitos os requisitos são analisados por uma equipe de revisores que analisam discutem e apontam caminhos para solucionar problemas encontrados 2 Prototipação um modelo executável é mostrado aos usuários finais e clientes para demonstrar uma melhor representação dos requisitos do sistema 3 Geração de casos de teste os requisitos são testados para garantir a validade dos requisitos Se existem dificuldades em projetar o sistema significa que os requisitos possuem problemas e devem ser reconsiderados Fundamentos da Engenharia de Software 22 4 Análise automatizada da consistência para verificar a consistência dos requisitos expressos em uma notação estruturada A ferramenta CASE deve construir uma base de dados para verificação de todos os requisitos na base de dados e então produzir um relatório das inconsistências que foram descobertas 145 Gerenciamento de requisitos Gerenciamento de requisitos é o processo para compreender e gerenciar as mudanças de requisitos que ocorrem no sistema SOMERVILLE e KOTONYA 1997 Por este motivo esta atividade é uma das mais importantes no processo de engenharia de requisitos A rastreabilidade é uma forma de identificar os requisitos a serem alterados Segundo Pinheiro 2000 o processo de desenvolvimento de software deixa rastros cuja identificação e acompanhamento é função da rastreabilidade Assim ele define rastreabilidade de requisitos como a habilidade de definir capturar e seguir os rastros deixados pelos requisitos nos outros elementos do ambiente de desenvolvimento de software e os rastros deixados por esses elementos nos requisitos Ferramentas de automação adequadas são de fundamental importância para o gerenciamento dos requisitos pois a dificuldade está no grande volume de informação gerado Atividades e Orientações de Estudos Para melhor assimilar o conteúdo deste capítulo sugerimos algumas atividades de fixação Como o assunto é simples e bem objetivo teremos basicamente os seguintes tipos de atividades para esse capítulo Atividades práticas representam questões simples e objetivas sobre o assunto aqui abordado Na prática bastará estudar o assunto contido no capítulo para respondêlas corretamente Atividades de pesquisas representam tópicos de pesquisas dirigidos não muito extensos Para cada tópico de pesquisa sugerido indicaremos fontes que poderão auxiliar na pesquisa mas você terá total liberdade de consultar outras fontes caso deseje Em cima do tópico sugerido definimos algumas questões que deverão ser respondidas Sugerimos ainda que as atividades de pesquisa sejam feitas em equipe pois isso favorece o aprendizado e enriquece a discussão sobre o assunto Atividades de interação correspondem atividades que visam discutir sobre o assunto nos fóruns criados para o curso E não esqueça na dúvida sintase à vontade em perguntar Interaja com seus colegas nos fóruns e chats participe Estamos aqui para auxiliar uns aos outros na construção do saber Seguem alguns exemplos de atividades respondidas eou comentadas que serão encontradas neste capítulo Não forneceremos exemplos de atividades de interação elas são atividades simples e caracterizadas pelas discussões abertas nos fóruns Atividades Práticas 1 Cite exemplos de requisitos funcionais e não funcionais para um sistema de controle Fundamentos da Engenharia de Software 23 de IRPF via internet Resposta Como requisitos funcionais podemos citar O sistema deve ser capaz de recuperar os dados de usuários previamente cadastrados na receita O sistema deve ser capaz de validar o IRPF analisando se há algum erro de preenchimento antes de salvar o imposto O sistema deve ser capaz de imprimir uma cópia do IRPF em arquivo pdf Como requisitos não funcionais podemos citar Os dados do IRPF trafegados pela internet devem ser criptografados Para utilizar o sistema pela rede o usuário deve ter sua máquina identificada na receita federal 2 Identifique alguns dos stakeholders envolvidos com a produção de um sistema automático de sinalização ferroviária Resposta Podemos citar como alguns dos stakeholders do software os operadores do sistema os condutores dos comboios os gestores os passageiros os engenheiros de instalação e manutenção as autoridades de certificação e segurança Aprenda Praticando Exercício Proposto 11 Tomando com base o que foi explicado no capítulo responda as questões abaixo justificando suas respostas quando apropriado 1 Explique qual a importância da elicitação de requisitos para a Engenharia de software 2 Explique cada uma das fases do processo de ER 3 Indique os possíveis stakeholders de um sistema de catalogação bibliotecária 4 Dê exemplos pelo menos 5 de requisitos funcionais para os seguintes sistemas a Um jogo do estilo pacman b Um sistema de catalogação bibliotecária c Um sistema de rede social como o Twitter ou o Orkut 5 Dê exemplos pelo menos 3 de requisitos não funcionais para os seguintes sistemas a Um sistema de aprendizagem virtual como o que você usa para acessar esse curso b Um jogo jogado em rede c Um sistema de transações bancárias 6 Sugira como reescrever os seguintes requisitos numa forma que possa ser quantificada a O sistema bibliotecário deve ser fácil de usar Fundamentos da Engenharia de Software 24 b O sistema deve fornecer um serviço confiável a todas as classes de utilizador c O sistema deve permitir uma resposta rápida a todos os pedidos de informação 7 Recorrendo a exemplos explique porque é que o conhecimento do domínio é importante para o processo de elicitação de requisitos 8 Que técnica de elicitação de requisitos você usaria nos seguintes sistemas a Um jogo do estilo pacman b Um sistema de catalogação bibliotecária c Um sistema de rede social como o Twitter ou o Orkut 9 Escreva cenários plausíveis para as seguintes atividades a Matriculandose num curso universitário de educação a distancia como este que você está fazendo b Transferindo dinheiro de uma conta para outra 10 Diga quem são os atores do processo de ER para as ações e responsabilidades especificadas na tabela Considere para responder os atores cliente gestores engenheiros a Utilizam o documento de requisitos para planejar estimar levantar riscos b Utilizam os requisitos para compreender que sistema deve ser desenvolvido c Especificam os requisitos e os leem para verificar se eles atendem a suas necessidades Especificam as mudanças nos requisitos d Utilizam o documento de requisitos para ajudar a compreender o sistema e as relações entre suas partes 11 Forneça exemplos dos tipos de questões que devem ser preparados com antecedência para uma entrevista visando à extração de requisitos 12 A locadora registra os seguintes dados dos clientes nome endereço cidade telefone RG data de inscrição e atribui um código a cada cliente Os clientes fazem uma locação a qual é atribuída um número sequencial e deve registrar o sócio que locou e a data da locação Cada cliente em cada locação pode alugar diversas fitas As fitas possuem código e título pertencem a uma determinada categoria de filmes romance comédiaaventura etc e estão classificadas como lançamento especial ouro ou prata Descreva a Funções e restrições do sistema b Ambiguidades do sistema c Aplique um conjunto de perguntas que vise esclarecer o maior número de dúvidas omissões e ambiguidades 13 Explique porque é útil envolver pessoas com formações diferentes num processo de revisão de requisitos 14 Dê exemplos de tipos de problemas que podem ser descobertos numa verificação de um documento de requisitos 15 Explique porque é que as matrizes de rastreabilidade podem se tornar difíceis de Fundamentos da Engenharia de Software 25 Atenção As respostas das questões dessa seção podem ser facilmente encontradas relendo os textos do capitulo Aproveite essa oportunidade para fixar melhor os pontos principais do conteúdo abordado no capitulo gerir quando há uma grande número de requisitos