Estudo Dirigido Disciplina: REQUISITOS DE SISTEMAS Aula 1: INTRODUÇÃO A REQUISITOS DE SISTEMAS Certamente que você deve está familiarizado sobre o conceito da palavra “sistema”, aonde este representa um tipo de rotina; ou seja, quando estamos construindo um software, na realidade estamos transferindo uma seqüenciada operação definida e seqüencial, de acordo com o seu funcionamento. Por exemplo, uma grande montadora de veículos encomenda um sistema para fazer com que “braços” mecânicos possam executar a tarefa de alocar as peças para que o carro seja construído. Portanto, o software opera sobre o hardware para que o computador possa desenvolver a determinada ação (para ver o funcionamento de um robô em uma montadora de carros, veja o vídeo: http://www.youtube.com/watch?v=oZ3eodFKBg). Fonte da imagem: http://t1.gstatic.com/images? q=tbn:ANd9GcTSNcPgpLUdjsxzmP0iRI6amRfZp_FRpa Uj7GsV1UAqHX8gnRX7 Portanto, antes de se pensar em questões tecnológicas (ambiente de desenvolvimento, linguagens de programação, banco de dados a ser utilizado, etc.), é preciso ter a concepção correta do que se está sendo solicitado. Se não conseguirmos compreender corretamente o que precisamos sistematizar, temos grande risco de não entregarmos o que se desejava no referido software. Não existe um bom projeto, uma boa linguagem de programação, um SGBD (sistema gerenciador de banco de dados), se a análise dos requisitos foi mal elaborada. Analise esse dado: “Numa recente pesquisa da indústria, as organizações avaliadas sofreram aumentos de até 60% no tempo e no orçamento quando utilizaram más práticas de requisitos. As organizações com recursos deficientes de análise de negócios tiveram três vezes mais falhas que sucessos nos projetos.” [IBM. Definição e Gerenciamento de Requisitos. Acessível em: http://www01.ibm.com/software/br/rational/offerings/irm/). É preciso massificar a concepção nos profissionais e empresas que trabalham com software, a necessidade de destinar investimentos para capacitação em análise e documentação, visto que vai agregar uma rentabilidade melhor para o software, com maior grau de acerto do que será entregue para atender a requisição do cliente. Sem um levantamento de requisitos adequado, certamente o desafio será muito maior!
Fonte da imagem: http://t1.gstatic.com/images? q=tbn:ANd9GcT3touV_5gjZfFNsLKzbHXisrwoXfJFix8G fKmaZoPvMPlMfe42aA O processo de levantamento de requisito está vinculado para garantir qualidade no produto que vamos entregar. Mas você sabe definir o que é qualidade? Segundo o Aurélio, atribui-se o termo qualidade a algo e/ou alguém que possui uma superioridade, excelência. Para qualquer empresa, ter qualidade nos seus processos para seu é ter uma estratégia competitiva, principalmente para aquela que desenvolve software. A muito tempo já deixamos de ter a visão que qualidade é algo voltado a classes sociais mais ricas. É preciso definir ou escolher um determinado padrão de qualidade a ser seguido nas atividades para o
desenvolvimento do sistema, a fim de poder acompanhar em diferentes estágios se está tudo em conformidade com as normas estabelecidas, e por fim garantir a qualidade do software. É perceptível atualmente um significativo movimento em busca da qualidade. Adventos de várias transformações no mundo, as organizações precisam produzir produtos e serviços de qualidade, não mais como uma estratégia de diferenciação de mercado, mas como uma condição de subsistência. Mas qual o caminho para um produto de qualidade? Como atingir a qualidade do produto de software? Variáveis como: qualidade de software, garantia da qualidade e custo da qualidade também são assuntos que exige análise. Lembre-se que, qualquer empresa precisa ser rentável, e a qualidade tem seus custos.
Para facilitar nossa compreensão na definição da palavra qualidade, Pressman (2006) atribuiu o alcance da qualidade de
software como uma consequência formal no desenvolvimento; para tanto, estima-se que seja colocada em prática e não somente uma idéia ou desejo que uma organização venha a ter. Ele cita as seguintes colocações sobre qualidade de software: a) Definir explicitamente o termo qualidade de software, quando o mesmo é dito. b) Criar um conjunto de atividades que irão ajudar a garantir que cada produto de trabalho da engenharia de software exiba alta qualidade. c) Realizar atividades de segurança da qualidade em cada projeto de software. d) Usar métricas para desenvolver estratégias para a melhoria de processo de software e, como consequência, a qualidade no produto final. Sendo assim, qualidade se consegue nos fragmentos do processo, não apenas no começo do projeto ou no seu final realizando testes, mas sim dentro do contexto visa abranger
toda a engenharia de software, contando como a colaboração de todos os envolvidos no projeto. “Qualidade de software deve ser compreendido e empreendido como um processo sistêmico que precisa está presente todas as etapas e artefatos produzidos, visando a garantia da conformidade de processos e produtos mediante aos requisitos definidos.” Portanto, isso consiste em realizar a qualidade tanto do processo quanto o produto. No processo, podemos quantificar a sua qualidade através de métricas para qualidade e no produto com as técnicas de verificação e validação. Essas atividades podem ser, por exemplo, avaliações como as citadas pela ISO 9000, auditorias, inspeções formais, testes, revisões. Ainda no processo podemos usar os métodos de garantia da qualidade no formato de auditorias e reportes para a alta gerência, além de avaliações constantes do processo e análise estatística de controle do processo. No produto os métodos de garantia da qualidade são revisões, inspeção formal e testes, além de revisão dos resultados do teste realizada por profissionais altamente capacitados, auditorias do produto e testes realizados pelo cliente. Não podemos confundir os conceitos e a aplicação dos termos Controle da Qualidade e Garantia da Qualidade. Para que possam utilizá-los adequadamente, acompanhe na tabela abaixo diferenças entre estas duas atividades: Garantia da Qualidade a) Garantia da qualidade garante que o processo é definido e apropriado. b) Metodologia e padrões de desenvolvimento são exemplos de garantia da qualidade. c) Garantia da qualidade é orientada a processo. d) Garantia da qualidade é orientada a prevenção. e) Foco em monitoração e melhoria de processo. f) As atividades são focadas no inicio das fases no ciclo de vida de desenvolvimento de software. g) Garantia da qualidade garante que você está fazendo as coisas certas e da maneira correta.
Controle da Qualidade a) As atividades de controle da qualidade focam na descoberta de defeitos em i específicos. b) Um exemplo de controle da qualidade poderia ser: "Os requisitos definidos são os requisitos certos?". c) Controle da qualidade é orientado a produto. d) Controle da qualidade é orientado a detecção. e) Inspeções e garantia de que o produto de trabalho atenda aos requisitos especificados. f) As atividades são focadas no final das fases no ciclo de vida de desenvolvimento de software. g) Controle da qualidade garante que os resultados do seu trabalho são os esperados conforme requisitos. Fonte da Tabela: http://mauricio.hernaski.com.br/blog/qualidade-doproduto-vs-qualidade-do-processo-2/
Pode-se afirmar que o teste de software é uma das atividades de controle da qualidade, ou seja, o teste de software é orientado a produto e está dentro do domínio do controle da qualidade.
De acordo com o PMBOK (Project Management Body Of Knowledge) do PMI (Project Management Institute), na versão 2004, os processos de gerenciamento da qualidade do projeto detêm todas as atividades da organização executora que determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que o projeto atenda às necessidades que motivaram sua realização. Eles desenvolvem o sistema de gerenciamento da qualidade através da política, dos procedimentos e dos processos de planejamento da qualidade, garantia da qualidade e controle da qualidade, com atividades de melhoria contínua dos processos conduzidas do início ao fim, conforme adequado. Com isso os três principais processos são: a) Planejamento da Qualidade: Identificação dos padrões de qualidade relevantes para o projeto e determinação de como satisfazê-los. b) Garantia da Qualidade: Aplicação das atividades de qualidade planejadas e sistemáticas para garantir que o projeto emprega todos os processos necessários para atender aos requisitos. c) Controle da Qualidade: Monitoramento de resultados específicos do projeto a fim de determinar se eles estão de acordo com os padrões relevantes de qualidade e identificação de maneiras de eliminar as causas de um desempenho insatisfatório. Há diversas semelhanças entre os conceitos usados no PMBOK e os conceitos da própria ISO (International Organization of Standardization). Com isso, é possível ainda relacionar estes três processos do PMBOK com as definições de qualidade de processo, qualidade de projeto, controle da qualidade e garantia da qualidade. A norma ISO 9000 estabelece um padrão para a qualidade de software. Ela aponta um conjunto de características de trata de um produto, processo ou sistema que está adequado os requisitos inicialmente estipulados para estes. “A ISO 9001 é de longe a estrutura de qualidade melhor estabelecida, sendo utilizada atualmente por mais de 750 mil organizações em 161 países, e define o padrão não só para sistemas de gestão da qualidade, mas para sistemas de gestão em geral.” Fonte: http://www.bsibrasil.com.br/certificacao/sistemas_gestao/nor mas/iso9001/. Enfim, alcançar um produto de software de maneira mais assertiva, que consegue o problema de maneira correta e que entrega dentro de um tempo e lugar que satisfazem ao cliente, inicia com a identificação dos requisitos. Então devemos primeiramente levantamos as pessoas, os processos e recursos que estão envolvidos, e buscar então evidenciar suas ações e documentá-las, da maneira mais detalhadamente necessária para que não haja dúvidas do(s) respectivo(s) comportamento(s). A seguir, trataremos de identificar os comportamentos relacionados aos requisitos que definem como eles estão classificados a partir de seus propósitos, que são diferentes, porém com algum(ns) relacionamento(s) entre si. exercicios
1) Qual o objetivo da área de requisitos de sistema? a. Identificar quem vai desenvolver o sistema. b. Informar qual a ISO deve ser utilizada naquele sistema. c. Programa computacional para estabelece regras para a qualidade. d. Sistema de apoio aos gerentes para aprimoramento de veículos. e. Levantar os dados para definição correta e completa para o sistema a ser desenvolvido. (resposta certa) 2) O que significa a sigla ISO? a. Empresa internacional que desenvolve software. b. Empresa internacional de padronização de processos. (resposta certa) c. Empresa internacional de requisitos de software. d. Empresa internacional de validação de requisitos. e. Empresa internacional de banco de dados. 3) Qual a norma da ISO que trata sobre gestão da qualidade? a. 9001 (resposta certa) b. 9010 c. 9100 d. 1900 e. 0190 Aula 02: REQUISITOS DE SISTEMA E REQUISITOS DE USUÁRIO
deverá ser capaz de efetivamente realizar, visando assim atingir os objetivos macros que motivaram o início do projeto. Pudemos também dizer que requisitos apontam a conduta desejada de um sistema. 1
Os requisitos classificados por níveis estão vinculado na linguagem ou ambiente do teor da especificação para determinada finalidade, com o intuito de consegui ser entendível, evitando que qualquer anomalia na qualidade da informação disposta imponha obstáculos para se alcançar plenamente o resultado esperado. E não adianta apenas constar, mas a compreensão do que se preciso tem que ser clara. Na figura ao lado (Sommerville, pág. 58), temos um exemplo descrito detalhadamente, que visam atender diferentes necessidades de informações. Por exemplo, nele estão visíveis para o programador saber qual(ais) a(s) regra(s) para se atingir o objetivo esperado, e o que o usuário deve efetivar no momento de obter o resultado daquele processamento. Todos estes devem sempre fornecer a dimensão exata dentro da especificidade do cenário, sendo claro e sem ambigüidades, para evitar desencontros e/ou desentendimentos. Para então contemplar todos os envolvidos no processo de levantamento de requisitos, de maneira que compreendam o cenário proposto para resolução de determinada necessidade que culminou na tarefa de desenvolver um sistema, dividimos os requisitos em dois níveis: sistema e usuário. Os requisitos de usuário definem em uma linguagem qualquer o que o sistema deve atender, sem se preocupar como vai atender. O foco é apontar características que agregam o valor do software, sem apontar como isso foi feito. É uma espécie de manual do sistema, que aponta suas funcionalidades para todos que o venham a ler. Exemplos: clientes (contratantes) e usuários finais do sistema.
Conforme estudamos na aula anterior, definir bem requisitos é um passo importante para alcançarmos o desenvolvimento de um projeto de determinado software com qualidade. Independente das características que definam maior ou menor, o primeira iniciativa será identificar o que se espera do sistema. Notadamente o sistema a ser desenvolvido substituirá ou aperfeiçoará algum outro existente ou automatizar um processo que atualmente não está sendo realizado por computador. Quando falamos em requisitos, estamos identificando algo intrínseco ao sistema, ou seja, alguma característica que
Nesta etapa, por exemplo, o usuário define então a rotina de determinada atividade, expressando claramente qual a necessidade, de forma que seja então criado todo o processo necessário para atender os anseios, e consequentemente possa 1
OBS: Fonte da imagem: Livro Engenharia de Software - Sommerville
atingir plenamente os objetivos. Notadamente neste caso não estão sendo levado em consideração quaisquer tecnologias a serem empregadas; pelo contrário, deve ser permissiva e sentida a flexibilidade, de modo que o usuário possa ter total liberdade para sua explanação. Como a leitura de um código de barras realizado por uma máquina de autoatendimento de um banco (ver ilustração, fonte: http://eratastads.blogspot.com/2008/10/requisitos-de-usuario-2.html). O usuário realiza o seu pagamento independente da infraestrutura de rede, linguagem de programação, etc. O que importa é que consiga interagir com o software e hardware, de forma a realizar a operação desejada. No tocante aos requisitos de sistema, estes já são especificados para um grupo de leitores que detém de uma experiência, seja no negócio como na área de tecnologia da informação, nas especificidades da empresa. Precisa não necessariamente entender de detalhes tecnológicos, mas estima-se que ostente algum tipo de experiência, dotando-o da capacidade de, por exemplo, identificar os insumos já presentes e aqueles também necessários, mas que não estão sendo gerados, para se alcançar uma determinada informação e com base na regra do negócio, aplicada e requerida pelo cliente.
Observando a figura que detalha os requisitos mínimos de sistema, é possível concluir que nem todas as pessoas terão capacidade de avaliar se realmente seu computador poderá fazer com que o jogo funcione. Mediante as informações serem mais de ordem técnica, é necessário alguém que tenha alguma familiaridade para que tenha a capacidade de avaliar e definir. Importante destacar que nada impede que os requisitos de sistema e/ou de usuário estejam disponíveis, ou seja, possam ser lidos por pessoas sem conhecimento apropriado (salvo por questões de confidencialidade); portanto, o documento está sendo disponível a todos, contudo, o grau de a relevância está mais associados àqueles que detém vínculo com determinado perfil de informação.
Um exemplo que facilita a compreensão é vinculado a software de jogos eletrônicos. Sempre ao comprar (recomenda-se) analisar quais são as características mínimas exigidas para que o jogo possa funcionar em um determinado computador. As informações ali dispostas são consideradas, obrigatórias, pois define os componentes e configurações para que seja possível usufruir das emoções dos jogos. Portanto, são requisitos do sistema (Fonte das imagens: http://froog.com.br/requisitos-de-sistema-need-for-speedshift/).
A seguir, veremos sobre mais dois tipos de requisitos, porém estes agora mais voltado para características mais internas do próprio requisitos, que apontam pela funcionalidade do requisito, o que justifica então a presença dele, tanto de maneira mais direta (requisito funcional), como indireta (requisitos não funcional). O processo de engenharia de requisitos é composto por quatro atividades de alto nível (Soares, 2005): Identificação. Análise e negociação. Especificação e documentação. Validação. Uma outra atividade que se pode considerar que faz também parte deste processo, se incluirmos a fase posterior à produção do documento (isto é, a sua "manutenção"), é a gestão dos requisitos (change management, sendo que as alterações podem ser causadas pelos mais diversos fatores desde inovações tecnológicas a mudanças na natureza do negócio (e consequentemente nos requisitos), entre outras. Identificação Caso se determine que o projeto é viável, o passo seguinte é a identificação dos requisitos. Atividades envolvidas Algumas das atividades envolvidas nesta fase incluem: Compreensão do domínio: é muito importante para o analista compreender o domínio no qual a organização e o projeto se inserem; quanto maior for o conhecimento acerca do domínio, mais eficaz será a comunicação entre o analista e as partes interessadas.
Identificação das partes interessadas: estes já deverão ter sido identificados nos estudos de viabilidade, porém para efeitos de identificação de requisitos convém concentrar as atenções nos utilizadores do sistema. Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não-funcionais) pretendidos para o sistema. Identificação e análise de problemas: os problemas devem ser identificados (e a sua definição deve ser consensual) e devem ser propostas soluções em conjunto com as partes interessadas. Dificuldades Esta fase não é trivial, sendo que existem algumas dificuldades típicas que lhe estão associadas: O cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo mas não conseguir articulá-lo (o que é bastante comum). Os requisitos identificados podem não ser realistas (do ponto de vista econômico ou tecnológico, por exemplo). Cada parte interessada pode expressar os mesmos requisitos de formas diferentes, sendo necessário - através de um bom conhecimento do domínio - identificar estas situações. Especificação e documentação É nesta fase que se dá a produção propriamente dita do documento de especificação de requisitos. Em todos os tipos de especificação há 2 tipos de requisitos a considerar: Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido. Requisitos não-funcionais: referem-se a aspectos nãofuncionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança, Desempenho, Suporte e Escalabilidade. Pode-se também considerar os requisitos do domínio, que tal como o nome indica derivam do domínio e não de necessidades específicas dos utilizadores, podendo depois ser classificados como funcionais ou não-funcionais. [editar]Requisitos do sistema Os requisitos do sistema têm um carácter mais técnico, consistindo numa descrição detalhada dos requisitos do utilizador correspondentes recorrendo ao uso, para além da linguagem natural, de linguagens estruturadas e notações gráficas. Estes requisitos destinam-se ainda aos utilizadores do sistema (e particularmente aos engenheiros que trabalhem nessa organização) e destinam-se também às equipes de especificação de arquitetura do sistema e de desenvolvimento. Tal como nos requisitos do utilizador, o uso de linguagem natural levanta problemas, embora alguns deles sejam ligeiramente diferentes: As mesmas palavras podem, de acordo com a interpretação de cada pessoa, designar conceitos diferentes. O mesmo requisito pode ser descrito de formas diferentes, o que leva a que cada pessoa tenha de saber quando é que descrições diferentes se referem ou não a requisitos diferentes. ]Documento de Especificação de Requisitos Apesar da existência dos 3 tipos de especificação vistos nos itens anteriores, 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 utilizador e do sistema e tem diferentes utilidades para diferentes pessoas (Kotonya e Sommerville, 1998): 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 IEEEque é talvez a mais usada é o IEEE/ANSI 830-1993 (Thayer e Dorfman, 1993). Durante a fase de validação dos requisitos, devem ser verificados (através de checklists) os seguintes atributos dos requisitos: Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas. Como tal, requisitos identificados individualmente (isto é, junto de cada parte interessada) podem diferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada cliente compreenda e aceite a especificação final obtida. Consistência: não devem existir conflitos entre os requisitos identificados. Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas. Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema. Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável. Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos requisitos especificados, estes devem ser descritos de modo a que seja possível verificar se foram ou não concretizados, isto é, se o sistema final corresponde à especificação inicial. Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos. Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua especificação deve obedecer às normas usadas ao longo de todo o documento. Especificação de Requisitos O objetivo da Especificação Preliminar ou Anteprojeto é transmitir uma idéia global e genérica do projeto a ser desenvolvido segundo a visão dos usuários. É elaborado para compreender a real necessidade dos usuários e suas expectativas, dimensionar a sua abrangência e delimitar o seu escopo. A principal característica do Anteprojeto é a sua natureza de estudo de viabilidade, de algo desejado, mas que ainda não foi devidamente analisado, permitindo dessa forma explorar alternativas para verificação de sua eficácia como solução. É fundamental o estabelecimento das Premissas Básicas que nortearão o desenvolvimento do sistema, atendo-se ao que o sistema? deve? fazer para cumprir a sua finalidade. Compreende aspectos como:
• Levantamento Inicial? Onde se busca encontrar, embora em termos genéricos, o máximo de informações relacionadas à área do Negócio, que sejam relevantes aos objetivos do projeto ou que possam impactar o seu desenvolvimento. • Estudo Preliminar? Identificação de todas as áreas envolvidas na solução e os grandes módulos de processamento, bem como o seu inter-relacionamento, sendo desejável a elaboração de um desenho macro onde o usuário possa identificar cada componente da solução pretendida. Nessa especificação não deverá haver a preocupação com a solução técnica que será adotada, poderá, no entanto, descrever as opções já verificadas ou desejadas pelos usuários no que se refere à tecnologia pretendida. A solução tecnológica propriamente dita será objeto da fase de Projeto. Como todo relatório deverá zelar pela clareza e objetividade das informações, seus dados devem ser precisos e suas estimativas e projeções deverão ser realistas, sem exageros ou omissões, dando base a conclusões sobre Custos e Benefícios com a implantação do sistema. A apresentação deverá ser organizada em tópicos coerentes favorecendo a compreensão e a seqüência do raciocínio. Resumindo, trata-se de uma peça importante e que merece total cuidado na preparação, pois além de possibilitar que seja dado aprovação ao prosseguimento do projeto, a apresentação criará expectativas nos futuros usuários e servirá de base ao detalhamento das fases seguintes do desenvolvimento. Uma verificação dos documentos obrigatórios da nossa metodologia vai permitir encontrar alguns itens que poderão ou deverão compor o relatório de Especificação de Projetos, de modo genérico, lembrando que quanto mais precisa for a especificação original, maior será a chance de sucesso na implementação. Requisitos do Sistema: Mas afinal o que são requisitos? Requisito pode ser descrito como: Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo; Condição necessária para a obtenção de certo objetivo, ou para o preenchimento de certo fim; Uma condição ou capacidade que deve ser suprida por um sistema para satisfazer um contrato ou um padrão; Enfim, tudo o que o sistema deve fazer para implementar uma necessidade de automação requerida pela solução. Na prática, requisito é o que o sistema tem que ter para atender plenamente ao propósito para o qual foi criado. Para garantir a aderência aos requisitos é fundamental que a Metodologia implemente e gerencie eficazmente o documento: Especificação dos Requisitos de Software, que tem como objetivos: • Descrever cuidadosamente, quais os requisitos do sistema e como o sistema deverá implementar tais requisitos. • Descrever objetivamente, como essa implementação poderá ser testada e verificada pelo usuário. Os requisitos podem ser classificados em: • Requisitos Funcionais? Funcionalidade a ser implementada no software para atender a uma necessidade de automação. • Requisitos Operacionais? Especificação de características relacionadas com o processamento do software, tais como: volume, freqüência, disponibilidade, performance, localização física etc. • Requisitos de Contingência? Tarefas alternativas para o caso de não funcionamento ou indisponibilidade eventual do software.
• Requisitos Técnicos? Premissas e restrições quanto à arquitetura tecnológica, aos padrões, à comunicação, às ferramentas, às linguagens etc. Exemplo: Projeto: ABC • Objetivo do Projeto; • Público Alvo; • Políticas Internas; • Premissas Básicas que regem o negócio; • Definição do Produto; • Condições de operacionalização; • Aspectos envolvendo processamento e comunicação com o Cliente; • Fatores que deram origem ao projeto; • Limitações ou Restrições Operacionais; • Benefícios Esperados pelos Usuários com a implantação do Sistema; • Principais necessidades que deverão ser atendidas pelo projeto; • Alternativas de Solução; • Necessidade de Integração com Sistemas Corporativos; • Padrões de Qualidade e Performance a serem obtidos; • Atribuição de Responsabilidades; • Fatores de Risco; • Aspectos Contábeis e Financeiros; • Aspectos Legais e Jurídicos; • Gerenciamento das Informações do Sistema. Além desses requisitos que definem objetivos e funcionalidades do sistema, devemos lembrar que qualquer sistema deve estar aderente às políticas da organização em relação à qualidade e segurança das informações; deve rodar em um ambiente produtivo em que rodam os outros sistemas da empresa, portanto deve estar em compatibilidade com todas as características operacionais desse ambiente sem impactar ou causar distúrbios nesses processamentos; deve estar em conformidade com os padrões de mercado em termos de tempo de resposta, desempenho e performance em máquina, minimizando a utilização dos recursos computacionais. A cada dia, as empresas tornam-se mais dependentes dos seus sistemas de informações. Construir esses sistemas, em tempo hábil para serem úteis aos negócios, com a qualidade e custos adequados à sua importância para a organização, é o desafio que todos os desenvolvedores estão enfrentando. Pressman define qualidade de software como? conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido?. Requisitos Não-Funcionais A Norma ISO / IEC 9126 define seis características de qualidade de software que devem ser avaliadas: • Funcionalidade (finalidade do produto); • Usabilidade (esforço para utilizar, aprender o produto); • Confiabilidade (freqüência de falhas, recuperabilidade); • Eficiência (característica relacionada ao desempenho); • Manutenibilidade (esforço necessário para modificar); • Portabilidade (capacidade de transferir o produto para outros ambientes). Pressman define Requisitos Não-Funcionais como: Fatores de qualidade de software que podem ser medidos de forma indireta?, ou como:? Características implícitas que são esperadas de todo software profissionalmente desenvolvido?.
• Reusabilidade (Capacidade de reutilização de módulos do sistema em outras aplicações). Este requisito está relacionado a outros fatores tais como: o Modularidade: independência funcional dos componentes; o Generalidade: amplitude do potencial de aplicação; o Encapsulação; o Abstração; • Portabilidade (Esforço exigido para transferir um sistema de um ambiente de hardware e / ou software para outro). Fator diretamente relacionado a reusabilidade e às linguagens de programação e ferramentas utilizadas; • Manutenibilidade (Esforço exigido para localizar e reparar erros em um sistema ou para modificá-lo com o propósito de adaptá-lo a um novo ambiente, a novas funcionalidades ou a outras metas de qualidade). Este requisito está relacionado a outros fatores, tais como: o Boa documentação; o Legibilidade; o Reusabilidade; o Portabilidade • Multimodalidade (Uso de diferentes mecanismos para representação ou apresentação da informação e para a interação com o usuário). Este requisito está relacionado ao uso de diversos canais de comunicação: o Visual; o Tátil; o Auditiva; o Motora. • Eficiência e Desempenho (Eficiência: quantidade de recursos de computação e de código exigida para que o programa execute a sua função - Desempenho: é medido avaliando-se a velocidade de processamento, o tempo de resposta, o consumo de recursos) Outros requisitos ou outras definições para o mesmo tipo de requisito ainda podem ser encontrados em diversas literaturas sobre o assunto: • Usabilidade (Refere-se ao grau de facilidade oferecido para que um usuário aprenda a operar, fornecer entradas e interpretar saídas de um componente ou sistema). A usabilidade de um sistema é um conceito que se refere à qualidade da interação de sistemas com os usuários e depende de vários aspectos. Alguns destes fatores são: o Facilidade de aprendizado do sistema: Tempo e esforço necessários para que os usuários atinjam um determinado nível de desempenho; o Facilidade de uso: Avalia o esforço físico e cognitivo do usuário durante o processo de interação, medindo a velocidade de uso e o número de erros cometidos durante a execução de uma determinada tarefa; Pressupõe a existência de Help, manuais de usuário e boa documentação; o Satisfação do usuário: Avalia se o usuário gosta e sente prazer em trabalhar com este sistema; o Flexibilidade e Nível de Parametrização: Avalia a possibilidade de o usuário acrescentar e modificar as funções e o ambiente iniciais do sistema. Assim, este fator mede também a capacidade do usuário utilizar o sistema de maneira inteligente e criativa, realizando novas tarefas que não estavam previstas pelos desenvolvedores; o Produtividade: Avalia se o uso do sistema permite ao usuário ser mais produtivo do que seria se não o utilizasse; o Consistência de interface; o Cuidado com a navegabilidade;
o Tolerância a erros. • Rastreabilidade (Capacidade de manutenção de histórico das ações dos usuários tais como: número de acessos ao sistema e material consultado ou do comportamento do sistema); • Extensibilidade (Capacidade de ampliar o sistema, pela incorporação de novas funcionalidades, pelo aumento da capacidade de armazenamento etc, e a Medida do esforço necessária para isso). • Escalabilidade (Capacidade de um componente ou de um software manter o mesmo desempenho (tempo de resposta) quando há um aumento no número de usuários e / ou de requisições simultâneas). Este requisito está relacionado aos fatores: o Pool de conexões; o Cuidado com operações de I / O. • Configurabilidade (Capacidade de organizar e controlar elementos da configuração do sistema ou Capacidade de gerar diferentes configurações ou visões do sistema). Este requisito está relacionado a outros fatores tais como: o Habilitação ou omissão de conteúdos e serviços; o Parametrização; o Personalização e customização do sistema ou componente de acordo com o contexto ou com o perfil de usuário. • Variabilidade (Está associada à variação de componentes de uma arquitetura). Pode haver variações: o De funcionalidade; o De dados; o De fluxo de controle; o De tecnologia; o De ambiente; o De metas de qualidade. • Segurança (Premissas e Restrições para o controle e segurança do software além da disponibilidade de mecanismos que controlam ou projetam programas e dados). Este requisito está relacionado aos fatores como: necessidade de criptografia, autenticação de usuários etc. o Controle de acesso e manipulação de recursos; o Autenticação; o Autorização / permissão; o Integridade dos dados e confiabilidade; o Privacidade e confidencialidade. • Tolerância à Falha (Capacidade do sistema de manter o seu funcionamento normal dada a ocorrência de uma falha de hardware ou software). Este requisito está relacionado aos fatores: o Disponibilidade; o Confiabilidade; o Freqüência e gravidade das falhas; o Acurácia dos resultados; o Capacidade de recuperação; o Redundância. Entre outros como: • Interoperabilidade; • Testabilidade; • Correção; • Consistência; • Compatibilidade; • Complexidade; • Internacionalização (capacidade do sistema para suportar diferentes línguas (Português, Inglês, Espanhol etc.) sem a necessidade de recodificação)
Conhecer e dominar uma linguagem de programação é bom mas não é tudo. Para criar sistemas robustos e que com qualidade é preciso mais do que uma boa linguagem e um bom programador. A princípio todo o sistema tem um objetivo e uma necessidade de criação. Não se cria um sistema que não tem utilidade e que ninguém vai usar , não é mesmo. Assim, um sistema deve ser criado para atender as expectativas de um cliente. A análise e especificação de requisitos de software envolve as atividades de determinar os objetivos de um sistema de software e as restrições associadas a ele. Ela deve também estabelecer o relacionamento entre estes objetivos e restrições e a especificação precisa do software A maior parte dos problemas no desenvolvimento de software são originados nas etapas iniciais do desenvolvimento justamente na etapa de levantamento e definição dos requisitos do sistema onde as principais atividades são : elicitação, análise, especificação, gerenciamento e validação de requisitos. Havendo falhas na realização das atividades acima citadas haverá inconsistência nos documentos de requisitos e o que acarretará um software de baixa qualidade com um custo elevado. São exemplos de requisitos funcionais: • "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 design do software. No design do software deve-se tomar a decisão de quais a funções o sistema efetivamente terá para satisfazer àquilo que os usuários querem. Requisitos não-funcionais são as qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente estes requisitos são descritos de maneira informal, de maneira controversa (por exemplo, o gerente que segurança mas os usuários querem facilidade de uso) e são difíceis de validar. São exemplos de requisitos não-funcionais: • "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" • "o tempo de desenvolvimento não deve ultrapassar seis meses". ________________________________________ ______ Aula 03: REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS Introdução da aula Conforme estudado anteriormente, os requisitos são responsáveis em apontar, com exatidão, as características
inerentes em um determinado sistema, inclusive sendo este como um aspecto de qualidade para o desenvolvimento correto do software a ser entregue, principalmente aqueles de grande porte. Segundo Summerville (2011, pág. 58), requisitos de software são frequentemente classificados como requisitos funcionais e requisitos não funcionais. Nesta aula, estaremos estudando sobre o conceito cada um deles, além de detalhar as características para podermos identificar corretamente se um requisito é funcional ou não funcional. Ao longo desta aula, você deve se familiarizar com as características que definem qual a correta classificação dos requisitos, a partir dos tipos que iremos estudar. Lembrem-se que, como um bom projetista de software, é preciso ter bem definidos os objetivos que são esperados no software que está sendo desenvolvido. Livro:Engenharia de Sommerville – Capítulo 4
Software
–
antes de entrarmos nas características que definem a classificação de requisitos, é importante enfatizar que um sistema não é concluído com apenas um tipo de requisito. E que também não existe algum que é mais ou menos importante. Recapitulando o que já estudamos, requisitos definem o que o sistema deve fazer; portanto, quando eles são evidenciados, entende-se que devem ser contemplados e inseridos no software. Sommerville (2011, pág. 60), destaca que os requisitos devem especificar todos os intentos do cliente, e que sejam de forma clara – os quais denominam pelo conceito de completude e consistência. Um fato que vamos estudar na próxima aula: as pessoas que fazem parte da empresa cliente, nem sempre são precisos em identificar corretamente um contexto. De maneira geral, os requisitos são classificados em três tipos. São eles: a. Funcionais; b. Não funcionais; e c. Interface. Vamos então analisar através do exemplo a seguir: Relativo ao sistema a ser desenvolvido, pede-se: deve disponibilizar um grid na tela, que permitirá a visualização dos dados relativos a nossa conta bancária (saldo disponível para o saque). Esses informações poderão ser acessadas apenas com o interesse do cliente. Portanto, o grid somente será ativado (e também pode ser desativado) através do clique em um botão. Esse grid não poderá durar mais do que 3 segundos para aparecer ao cliente. Separando corretamente os requisitos especificados no exemplo acima, visto que não houve preocupação em de distinguir – ou seja, temos uma aglutinação de requisitos, o resultado seria: • Funcional: o Sistema deve possuir um módulo para saque. o No módulo de saque deve ser disponibilizado um grid para a visualização do saldo. o O grid pode ser ativado ou desativado, dependendo do interesse do cliente.
• Não funcional: o Software deve possuir características de confiabilidade, pois trabalha com dados sensíveis (saldo de conta). o O tempo máximo para visualizar as informações no grid é de 3 segundos. Muitas vezes é difícil discernir entre quais requisitos são funcionais e quais não são. Essa prática vem com o tempo e com a experiência e, por isso, para quem não trabalha diretamente com análise, é sempre bom exercitar. O processo de análise é uma das fases mais complexas do projeto de software. Vamos ainda continuar falando sobre o processo de elicitação de requisitos e de análise em geral em próximas ocasiões. Os requisitos funcionais são aqueles que estabelecem e descrevem as funcionalidades do sistema desejadas pelos clientes, ou seja, retratam “O QUE” se espera que o software faça. Então, por exemplo, uma empresa determinada empresa está com interesse em ter um sistema que gerencie o seu cadastro de fornecedor. Ela deseja acabar com um cadastro de fornecedor atualmente realizado em fichas. Para tanto, encomendou um sistema que sistema possibilite cadastrar e armazenar todos os dados daqueles que lhe fornece produtos e/ou serviços. Mediante este cenário, tudo que envolver funcionalidades ou serviços que se espera do sistema no tratamento para o controle do fornecedor será um requisito funcional Por exemplo: o sistema deve disponibilizar o cadastro dos campos “A”, “B” e “C”. Também foi solicitado que pudesse ser emitido um relatório de todos os fornecedores que não conseguiram entregar no prazo estabelecido, citando o motivo e o número do pedido, além de outros relatórios que são importantes para os gerentes da empresa. Todos estes são exemplos de requisitos funcionais. Os requisitos não funcionais envolvem fatores para o sucesso do produto a ser entregue porque atua diretamente com a satisfação dos usuários na operação do software. São exemplos de características de requisitos não funcionais que devem ser avaliadas2: • Funcionalidade Está vinculado a finalidade do produto. É preciso entender as característica de quem e o que foi pedido. • Usabilidade Esforço para utilizar o sistema; aprendizagem do produto; acessibilidade, principalmente por público de necessidades especiais • Confiabilidade Relacionado a freqüência de falhas, e, quando ocorrerem, qual o tempo necessários para a recuperação do ambiente, caso ocorrar alguma indisponibilidade. • Eficiência Característica relacionada ao desempenho do sistema relativo a quantidade da demanda gerada quando ele estiver em atividade. • Manutenibilidade
2
Fonte: Norma ISO/IEC 9126
Esforço necessário para modificar o sistema para possíveis cenários, sejam eles novos ou resultado de ajustes para atender alguma nova característica. • Portabilidade Capacidade de transferir o produto para outros ambientes.
São exemplos de requisitos não-funcionais: 1. Software deve ser operável por deficientes visuais. 2. Tempo de resposta do sistema não deve ultrapassar 10 segundos. 3. Software deve ter módulo de backup. 4. A base de dados deve ser acessível apenas para autorizados.
Na figura 1, temos uma abrangente descrição dos tipos de requisitos não funcionais, a qual nos permite ter uma noção mais exata sobre as características necessárias para enquadrarmos um item como um requisito não funcional. Fonte: Sommerville, 2011 – pág. 61. Mediante o cenário muito intangível (mas que precisa obter um métrica), detalhamos na figura 2, as principais métricas para especificar requisitos não funcionais. Acompanhe então cada medida que pode ser utilizada em relação a uma determinada propriedade do requisito.
Fonte: Sommerville, 2011 – pág. 62. Resumindo então a diferença entre os requisitos funcionais e não funcionais, podemos dizer que o primeiro tem características tangíveis (é mais fácil de se observar),
enquanto o outro trata de questões intangíveis, e que podem obter diversas maneiras de ser avaliado, ou seja, vai depender diretamente do contexto computacional e do tipo do sistema a ser produzido. Aula
04: IDENTIFICAÇÃO DOS STAKEHOLDERS. TÉCNICAS DE LEVANTAMENTO DE REQUISITOS Introdução da aula Nesta aula, vamos aprender sobre os indivíduos que estão relacionados direta ou indiretamente com um software. Iremos perceber que eles, por exemplos, nem precisam fazer uso do sistema, mas mesmo assim, ele é afetado em algum aspecto. A estes, denominamos stakeholders. É é sobre ele que vamos iniciar nossos estudos. Também teremos a oportunidade de aprender sobre o levantamento de requisitos, o qual sempre está associado a algum ou vários stakeholders. Vamos entender então como nem sempre é uma atividade fácil conseguir identificar o que realmente deve ser um requisito funcional ou não funcional. Por fim, você terá a oportunidade, ao término da aula, de identificar modelos e/ou formas para atingir o objetivo da área de requisitos: entregar o produto com um alto grau de satisfação do cliente. Uma vez que já definimos uma estrutura e classificação para o desenvolvimento de um projeto de software com controle e garantia da qualidade, vamos na aula de tratar de identificar e detalhar sobre as pessoas que tenham e/ou sejam afetados por um software. Porque, também independente de tecnologia, certamente um projeto que atua na área da engenharia de software, contemplará a participação direta ou indireta, ativa ou passiva, de pessoas. Figura 1
(computacional ou não), sempre teremos agentes diretos ou indiretos, que irão compor ou sofrer das suas características. Acompanhando a Figura 1 (fonte: http://cnx.org/content/m26195/latest/), tente identificar a atividade da empresa que possa conter todos os usuários com base nos “pensamentos” citados nas caixas. Também procure distinguir quais deles seriam colaboradores e quais representam o(s) cliente(s), e, principalmente, sinalize quais serão os stakeholders desse cenário. Deixe anotada a sua resposta para verificar se está correta ou completa. Com foco então em um ciclo de vida do software é possível claramente saber que ele é composto por diversas e distintas responsabilidades que estão vinculadas as pessoas, grupos e entidades. Dentre essas responsabilidades que podemos aqui elucidar, são exemplos: o responsável pelo financiamento, o projeto, o desenvolvimento, o teste, o uso e a manutenção do software. A todos estes chamamos de stakeholder. A palavra vem de da seguinte composição: • Stake: interesse, participação, risco. • Holder: aquele que possui. Portanto, todos aqueles que de alguma maneira é afetado pelo software, é um stakeholder (reveja sua resposta da questão vinculada a Figura 1). Então é correto afirmar que toda a preocupação no tocante ao correto desenvolvimento de um sistema e demais recursos de infra-estrutura, por sua vez, tem o duplo objetivos de facilitar o cumprimento das responsabilidades dos stakeholders, quanto atender às suas necessidades (voltando a Figura 1, temos: a urgência por desempenho; os aspectos de segurança e usabilidade). Segundo Summerville (2009), podemos definir da seguinte forma: “Um stakeholder em uma arquitetura de software é uma pessoa, grupo ou entidade com um interesse ou preocupações sobre a realização da arquitetura.” Com base então no que já aprendemos, podemos então relacionar os seguintes exemplos e atribuições de stakeholders no desenvolvimento de um projeto de sofware: Gerente de Projeto – Responsável em organizar e conduzir as equipes em suas responsabilidades. Como gestor, precisa manter harmonia no desenvolvimento do projeto, supervisionando a execução das tarefas, observar os processos, sustentar e fomentar o equilíbrio entre os stakeholders, etc.
E justamente nesse perfil de um indivíduo que em algum momento influi algum tipo de interesse, participação, etc., sobre um determinado software, a este caracterizamos como um stakeholder. Antes de levantarmos as considerações específicas da engenharia de software, vamos buscar um entendimento mais amplo do que vem a ser um stakeholder, permitindo assim que possamos compreender, por exemplo, que não é somente na Computação que existem, mas em todo em qualquer sistema
Analista de Sistema – Responsável em analisar quais as características o que deverá ter o produto a ser desenvolvido para atingir o objetivo final, ou seja, o que o cliente espera. Para isso, busca analisar as especificidades inerentes ao determinado software. Programador – São os responsável em efetivamente desenvolver do software. Cabe a ele a implementação das linhas de códigos que construirão a identidade lógica do software. Patrocinador – Popularmente é quem “paga a conta”. É aquele que libera os recursos, custeia a produção do projeto.
Ele será o responsável por prover financeiramente a arquitetura necessária para o desenvolvimento de software.
desenvolvimento de software deve ser o levantamento de requisitos.
Cliente (usuário) – É aquele que, a partir de uma necessidade, faz a encomenda de um software. Portanto, é quem vai usufruir do produto a ser entregue; seja ele apenas um ou um grupo de usuários.
Como já sabemos, a fonte das informações inerentes ao que queremos automatizar está com os futuros usuários, os quais atualmente já desenvolvem as mesmas tarefas, de forma manual ou automática. Além que o cliente não estabelece claramente todas as regras relativas ao negócio; e quem está sendo contratado desconhece as especificidades referente ao processo que atualmente está em execução.
Contudo, além destes supracitados, podemos ter muitos outros stakeholders – que não são tão elementares, mas possuem algum tipo de interesse. Por exemplo: • • • • • •
Poder público A comunidade Concorrentes Fornecedores Investidores e acionistas As famílias da equipe de projeto
Para contextualizar melhor, acompanhe o exemplo abaixo: • No contexto da Figura 1 tratado no início dessa aula, podemos dizer que uma pessoa qualquer que ficou no carro aguardando o amigo ou parente devolver um filme, tem grande interesse no desempenho do sistema utilizado pela locadora; caso contrário, o tempo de espera será maior do que o previsto. Portanto, tanto que está no carro aguardando, como quem está na locadora para devolver o filme, são stakeholders. São outras características dos stakeholders: 1) São específicos para cada projeto; 2) Possuem anseios e objetivos distintos em um projeto; 3) São atores fundamentais para detalhamento do que deve ser desenvolvido. Mediante então a todos esse envolvimento, fato que pode atrapalhar consideravelmente o êxito de um projeto de software é a ocorrência de uma falha no levantamento dos stakeholders. Tal realidade pode representar que o gerente de projeto não estará pensando nas necessidades de todos os envolvidos; como conseqüência, podemos ter um software que não atende aquilo que o cliente esperava, e de que deverá ser revisto e ajustado posteriormente. Portanto, gerará desgastes de recursos, além da insatisfação daquele que encomendou o sistema. Entretando, o gerente de projeto deve observar bem seus objetivos e não procurar stakeholders por todos lados, o que culminará em um cenário difícil de gerenciar. Deve haver limitação no escopo daqueles que afetam e/ou serão afetados pelo projeto. Caso contrário, com um pouco de imaginação, pode-se considerar stakeholder até a mulher do gerente de projeto que deixará de sair com o marido no fim de semana porque ele terá que trabalhar! Concluindo essa primeira etapa de nossa aula, esperamos que você possa ter entendido toda o envolvimento e influência dos stakeholders em um projeto de software, suas relações e interdependência na concepção e uso de um determinado sistema. Técnicas para levantamento de Requisitos Diferentemente do que pode representar a melhor das iniciativas, acionar os programadores para começarem a escrever linhas de códigos não deve ser o foco de atenção para o projeto de software, a abertura para toda a atividade de
Sommerville (2009) propõe um processo genérico de levantamento e análise que contém as seguintes atividades: 1) Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação; 2) Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade; 3) Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes; 4) Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos; 5) Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes; 6) Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema. Apesar de aparentemente parecer elementar, o problema de não saber especificar corretamente o que o sistema deverá fazer é muito rotineiro. Realidades como: (a) de um usuário principal do sistema não saber o que quer que o sistema faça ou sabe e não consegue/quer transmitir para o analista; ou (b) requisitos identificados, mas que não exprimem a realidade; e (c) não estão em concordância com os requisitos informados por pessoas diferentes, são constantes na elaboração dos requisitos. Um stakeholder ou informação errada afetará em perda de tempo e dinheiro para ambas as partes envolvidas no desenvolvimento do sistema. É preciso aferir e revisar os requisitos. No tocante ao do analista responsável pelo levantamento dos requisitos, dois fatores contribuem para o baixo grau de satisfação dos usuários, o que aumenta consideravelmente a perspectiva do erro. São eles: • Não utiliza uma técnica adequada para extrair os requisitos do sistema; • Descrever os requisitos do sistema de modo pouco claro, com ambigüidades, sem consistência com todos os aspectos significativos do sistema proposto. Como contramedida para atacar primeiro item acima destacado, vamos agora estudar sobre as técnicas de levantamento de requisitos, detalhando seu conceito e suas respectivas vantagens e desvantagens, que podem ser utilizadas em conjunto pelo analista. Etnografia
A etnografia é caracterizada como uma técnica de observação, aonde o analista buscar uma familiarização do cliente, seus valores, sua história. Ela pode ser utilizada para compreender os requisitos sociais e organizacionais, que facilitem compreensão da política organizacional e da sua cultura. Nesta técnica, o analista é inserido no ambiente de trabalho em que o sistema será utilizado, aonde diariamente são realizadas anotações das tarefas observadas, e que serão incorporadas no sistema a ser utilizado. Esta técnica tem por principal objetivo em auxiliar na descoberta de requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais, onde as pessoas estão envolvidas. Portanto, tem eficácia em atuar na descoberta da maneira como as pessoas realmente trabalham, em vez da maneira pelas quais as definições de processo dizem como elas deveriam trabalhar, além do contexto de integração e colaboração entre o stakeholder e os demais vinculados a ele. São ações consideradas importantes que devem ser executados antes, durante e depois do estudo de observação: • Antes, é necessário identificar as áreas de usuário a serem observadas; obter a aprovação das gerências apropriadas para executar as observações; obter os nomes e funções das pessoas chave que estão envolvidas no estudo de observação; e explicar a finalidade do estudo; • Durante, é necessário familiarizar-se com o local de trabalho que está sendo observado. Para isso é preciso observar os agrupamentos organizacionais atuais; as facilidades manuais e automatizadas; coletar amostras de documentos e procedimentos escritos que são usados em cada processo específico que está sendo observado; e acumular informações estatísticas a respeito das tarefas, como: freqüência que ocorrem, estimativas de volumes, tempo de duração para cada pessoa que está sendo observada. Além de observar as operações normais de negócios acima é importante observar as exceções; • Depois, é necessário documentar as descobertas resultantes das observações feitas. Para consolidar o resultado é preciso rever os resultados com as pessoas observadas e/ou com seus superiores. Mediante suas características, a análise de observação tem algumas desvantagens como, consumir bastante tempo, além da possibilidade do analista ser induzido a erros em suas observações, mediante anomalia no comportamento dos stakeholders. Mas em geral a técnica de observação é muito útil e freqüentemente usada para complementar descobertas obtidas por outras técnicas. Workshops Trata-se de uma técnica de elicitação desenvolvida em grupo, usada em uma reunião estruturada. São integrantes do grupo que participaram do workshop: 1) Equipe de analistas. 2) Seleção dos stakeholders mais envolvidos no contexto em que o sistema atuará. A principal estratégia do workshop tem é acionar o trabalho em equipe. Há um facilitador neutro cujo papel é conduzir a workshop e promover a discussão entre os vários mediadores. As tomadas de decisão são baseadas em processos bem
definidos e com o objetivo de obter um processo de negociação, mediado pelo facilitador. Uma vez encerrado, serão produzidas documentações que refletem os requisitos e decisões tomadas sobre o sistema a ser desenvolvido. Aspectos considerados importantes para o sucesso são: 1) A postura do condutor do seminário - mediador e observador; 2) Deve possuir dia, hora, local, horário de início e de término; destacando o assunto a ser debatido e sua documentação. Entrevistas A entrevista também é uma das técnicas de levantamento de requisitos. Tradicionalmente mais simples de utilizar, produz bons resultados na fase inicial de obtenção de dados. Sobre a entrevista, deve-ser considerar: 1) O entrevistador dê margem ao entrevistado para expor as suas idéias. 2) Ter um plano de entrevista para que seja mantido o foco no cerne do assunto principal. 3) Evita que a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados. Representam boas práticas de auxilio na direção de entrevistas: 1) Desenvolver um plano geral de entrevistas; 2) Certificar-se da autorização para falar com os usuários; 3) Planejar a entrevista para fazer uso eficiente do tempo. Previamente o analista que fará a entrevista deve procurar está bem contextualizado, sendo mais assertivo e produtivo do que será tratado na entrevista. Para tanto, o planejamento deve envolver um momento para coleta e estudo todos os dados pertinentes à discussão, como formulários, relatórios, documentos e outros. Ao término, é necessário validar se o que foi documentado pelo analista está de acordo com a necessidade do usuário, que o usuário não mudou de opinião e que o usuário entende a notação ou representação gráfica de suas informações. São exemplos de como aferir a veracidade das informações levantadas na entrevista: Faça uma explanação sobre o relacionamento entre o que está em discussão e as demais partes do sistema; Informe do ponto de vista de outros usuários em relação ao item que foi discutido; Descreva informalmente a narrativa do item em que o analista deseja obter informações; O analista deve dizer ao usuário o que acha que ouviu ele dizer. Neste caso, o analista deve utilizar as suas próprias palavras em lugar das do entrevistado e solicitar ao entrevistado confirmação do que foi dito. Questionários Existem vários tipos de questionários que podem ser utilizados. Entre estes podemos listar: múltipla escolha, lista de verificação e questões com espaços em branco. São aspectos relevantes no uso dessa técnica:
Um ambiente oportuno para o uso de questionário é quando há diversos grupos de usuários que podem estar em diversos locais diferentes do país. Neste caso, elaboram-se pesquisas específicas de acompanhamento com usuários selecionados, que a contribuição em potencial pareça mais importante, pois não seria prático entrevistar todas as pessoas em todos os locais. 1) Identifique todos os destinatários que o receberão. 2) Realize a distribuição junto com instruções detalhadas sobre seu preenchimento. 3) Defina e informe o prazo para devolução do questionário. 4) Documente o resultado da análise e consolidação das respostas dos participantes. 5) Envie uma cópia com as informações levantadas para o participante, como sendo uma forma de agradecimento e consideração pelo tempo dedicado a pesquisa.
3. A viabilidade desempenho.
de
atendimento
dos
requisitos
de
As técnicas utilizadas na elaboração do protótipo são várias: interface de usuário, relatórios textuais, relatórios gráficos, entre outras. Um dos principais benefícios que podemos relacionar são as reduções dos riscos na construção do sistema, pois é possível detectar se o usuário chave já verificou o que o analista captou nos requisitos do produto. São elementos para o sucesso na elaboração dos protótipos: 1. Seleção do ambiente de prototipagem; 2. Compreender os objetivos do protótipo por parte de todos os interessados no projeto; 3. Focar em áreas que estejam com maior dificuldade na compreensão; e 4. Rapidez na construção.
Brainstorming Brainstorming é uma técnica para geração de idéias. Uma idéia preliminar gerada serve como incentivo para que outras apareçam, sejam concordantes ou não, propiciando um aprimoramento e compartilhamento de todos os envolvidos. Pode ser estabelecida uma ou várias reuniões. O número de idéias geradas deve ser bem grande, pois quanto mais idéias forem propostas, maior será a chance de aparecerem boas idéias. Os participantes também devem ser encorajados a combinar ou enriquecer as idéias de outros e, para isso, é necessário que todas as idéias permaneçam visíveis a todos os participantes.
JAD Por fim, não menos importante, vamos apresentar uma técnica de grande adesão pelos analistas a fim de realizar o levantamento de requisitos: JAD (Joint Application Design). É uma técnica destinada a principalmente promover cooperação, entendimento e trabalho em grupo entre os usuários desenvolvedores. Com a intenção de facilitar a criação de uma visão compartilhada do que o produto de software deve ser, ela ajuda os usuários e desenvolvedores a formular problemas e explorar soluções, no escopo do projeto a ser desenvolvido. Tal fato estabelece sentimento de envolvimento, posse e responsabilidade com o sucesso do produto.
Uma vez definido que esta é a técnica mais apropriada para determinada situação, as próximas etapas necessárias para conduzir uma sessão de brainstorming são:
Possui quatro princípios básicos:
Seleção dos participantes ou grupo de trabalho: Estes devem ser selecionados em função direta com as contribuições que possam oferecer durante a sessão. É aconselhável sempre a presença de pessoas que estejam sempre bem informadas, sejam de diferentes grupos; Prepara a sessão: Duração e local do encontro, bem como o que será tratado. Explicar a técnica e as regras a serem seguidas: Definir os conceitos básicos de brainstorming e as regras a serem seguidas durante a sessão; Gerar ou produzir uma boa quantidade de idéias: Os participantes geram tantas idéias quantas forem exigidas pelos tópicos que estão sendo o objeto do brainstorming. Os participantes são convidados, um por vez, a dar uma única idéia. Se alguém tiver problema, passa a vez e espera a próxima rodada. Analisar as idéias: Revisar a produção de idéias, destacando as mais valiosas definidas pelo grupo e classificando-as com prioridades. Prototipagem Protótipo tem por alvo explorar requisitos vinculados a um produto que possua aspectos críticos, implementando de maneira mais rápida um pequeno subconjunto de funcionalidades deste produto. O protótipo é aconselhado para: 1. Estudar as alternativas de interface do usuário; 2. Problemas de comunicação com outros produtos; e
Dinâmica de grupo: são realizadas reuniões com um líder experiente, analista, usuários e gerentes, para despertar a força e criatividade dos participantes. O resultado final será a determinação dos objetivos e requisitos do sistema; Uso de técnicas visuais: para aumentar a comunicação e o entendimento; Manutenção do processo organizado e racional: o JAD emprega a análise top down e atividades bem definidas. Possibilita assim, a garantia de uma análise completa reduzindo as chances de falhas ou lacunas no projeto e cada nível de detalhe recebe a devida atenção; Utilização de documentação padrão: preenchida e assinada por todos os participantes. Este documento garante a qualidade esperada do projeto e promove a confiança dos participantes. E um total de seis tipos de participantes – levando em consideração quem nem todos participam de todas as fases. São eles: Líder da sessão: É um facilitador dos encontros. Deve ser competente, com bom relacionamento pessoal e qualidades gerenciais de liderança. Engenheiro de requisitos: É um participante experiente nas questões técnicas, diretamente responsável pela produção dos documentos de saída das sessões JAD. Executor: É o responsável pelo produto sendo construído.
Representantes dos usuários: São pessoas na empresa que terão incumbência de utilizar o produto de software. Representantes de produtos de software: São pessoas que estão familiarizadas com as capacidades dos produtos de software, capazes de mediar os usuários na compreensão entre o que é possível e razoável no sistema. Especialista: é a pessoa que pode fornecer informações detalhadas sobre um tópico específico. Aula 05: DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE Introdução da aula O documento de requisitos é um documento formal utilizado para comunicar os requisitos aos clientes, engenheiros e gestores, além de outros envolvidos que necessitem acessar este documento. Contudo, não apenas a ação de desenvolvê-lo, é importante conhecer o que deve conter e a quem e como será utilizado, que permita uma visão geral do sistema, necessidades de negócio suportadas pelo sistema e um demais informações que consigam explicitar todo o contexto a ser desenvolvido, mediante a necessidade identificada por quem encomendou um determinado software. Iremos então compreender que a documentação de requisitos não é exclusivamente importante para o desenvolvimento de software, ela também é muito útil na análise e seleção de fornecedores de aplicações comerciais já desenvolvidas. Até essa etapa, conseguimos estabelecer uma boa perspectiva de todo o contexto que envolve um projeto relacionado a desenvolvimento de software. Mesmo para aqueles que já atuam na área de desenvolvimento de sistema, mas a cada aula vamos adicionando necessidades e entendendo que não basta codificar uma sequência lógica de um procedimento em uma determinada linguagem de programação, mas que existem métodos que auxiliam e estabelecem modelos para que possamos alcançar um resultado mais aderente e satisfatório junto ao cliente. Tudo que estamos estudando nessa disciplina é para fazer com que entendamos bem do problema, da sistemática já ou se existente - quem está contratando, além de estabelecer um elo entre o que se espera e o que será entregue. Na aula de hoje, estaremos avançando no quesito de comunicação e documentação, mais especificamente no aspecto do registro de todo o conteúdo extraído no levantamento de requisitos, ou seja, será um local cujo teor é uma consignação que retrata as especificações a serem seguidas no desenvolvimento de software. Este é o que denominamos que documento de requisitos de software. De acordo com Sommerville (2009), “o documento de requisitos de software, às vezes chamado de Especificação de Requisitos de Software (SRS – do inglês Software Requeriments Specification), é uma declaração oficial do que os desenvolvedores do sistema devem implementar”. Enfim, como sabemos que a área de requisitos de sistemas tem total ligação com o fator qualidade para o desenvolvimento de software, o documento de requisitos trata então de indicar e detalhar sobre os componentes a serem inseridos no sistema que está sendo construído. Uma vez concluído, se comportar
como uma bússola que detalha quais as ferramentas a serem estabelecidas ao término do projeto. Como tudo o que vimos até agora, não seria diferente com este documento. Enfim, não é simplesmente criar um documento no editor de texto e digitar os itens e seus respectivos conceitos. É preciso ter disciplina e orientação para alcançar um documento que seja acessível e entendido pelos diversos participantes do projeto, evitando que ele seja o primeiro recurso de desentendimento e dificuldade para a compreensão do que está sendo desenvolvido. Portanto, vamos então conhecer sobre o documento de requisitos de software! A primeira necessidade é ter em mente que este não é apenas um documento técnico, que será lido apenas pelos analistas de sistemas e os programadores. Sommerville (2009) esclarece sobre tal realidade, tratando claramente sobre a diversidade do perfil de usuários, que vão desde a cúpula organizacional até aqueles vinculados à tecnologia da informação e comunicação. Ele então chama a atenção referenciando que “a diversidade de possíveis usuários é um indicativo de que o documento de requisitos precisa ser um compromisso com a comunicação dos requisitos para o cliente, a definição dos requisitos em detalhes precisos para os desenvolvedores e testadores e a inclusão de informações sobre a possível evolução do sistema”. Portanto, a premissa “compreensível” deve ser uma tônica para o grupo que está responsável por gerar o documento de requisitos. Conforme mencionado, o documento é referência tanto no presente (quanto se está em pleno desenvolvimento), bem como no futuro, quando na fase de manutenção. No tocante a compreensão, também deve-se observar o texto utilizado, o qual precisa organizado e com nível adequado aos respectivos leitores. Veja o exemplo abaixo, retirado do livro do PFLEEGER (Engenharia de Software – Teoria e Prátíca – 2ª Edição, pág. 140): Em 1995, a Organização Australiana de Defesa e Tecnologia relatou os resultados de uma pesquisa sobre problemas com especificação de requisitos na Marinha. Um dos problemas destacados foi a disparidade no nível das especificações. Isto é, alguns requisitos foram especificados em um nível alto e outros em um nível muito baixo. A disparidade era composta de diversas situações: • Algumas vezes, os analistas de requisitos utilizaram diferentes estilos de escrita, especialmente em área diferentes do sistema. • A diferença de experiência entre os analistas levou a diferentes níveis de detalhes nos requisitos. • Na tentativa de reutilizar os requisitos a partir de sistemas anteriores, os analistas empregaram diferentes formatos e estilos de escrita. • Os analistas, algumas vezes, mesclaram requisitos com soluções parciais, levando a sérios problemas para o projeto de uma solução com boa relação custo-benefício. • Frequentemente, os requisitos foram excessivamente especificados, quando os analistas identificaram tipos específicos de computadores e linguagens de programação assumiram uma solução específica ou impuseram processos e protocolos não apropriados. • Algumas vezes, os requisitos foram pouco especificados, especialmente ao descreverem o ambiente de operação,
manutenção, simulção para treinamento, computação administrativa e tolerância a falhas. Conforme apontando em Sommerville (2009) na Figura 1, são estes exemplos de usuários de um documento de requisitos de software:
Glossário
Definição de requisitos de usuário
Da mesma particularidade que existe em um projeto de software, tornando-o único em algum(ns) ponto(s), toda a informação a ser disposta no documento de requisitos tem total vínculo com o perfil do sistema a ser desenvolvido. Portanto, podemos encontrar documentos com o foco será sobre a definição de requisitos de usuários e os requisitos não funcionais, ou que envolva requisitos de sistemas e requisitos funcionais, bem como outras combinações entre eles. Ainda sob o aspecto de fatos particulares, outro aspecto que deve também ser definido é o nível de detalhamento a ser utilizado para descrição dos requisitos no documento.
Então agora, mais contextualizados sobre o perfil de um documento de requisitos, passaremos para uma nova etapa, na qual iremos aprender detalhes sobre a sua estrutura, conhecendo o que pode ser considerado para a sua criação. Para tal finalidade, utilizaremos a composição definido por Sommerville (2009) – bibliografia básica de nossa disciplina, a qual está disposta na tabela abaixo: Capítulo Prefácio
Introdução
Descrição Deve definir os possíveis leitores do documento e descrever seu histórico de versões, incluindo uma justificativa para a criação de uma nova versão e um resumo das mudanças feitas em cada versão. Deve descrever a necessidade para o sistema. Deve descrever brevemente as funções do sistema e explicar como ele vai funciona com outros sistemas. Também deve descrever como o
Modelos sistema
do
Evolução sistema
do
Apêndices
Índice
sistema atende aos objetivos globais do negócio ou estratégicos da organização que encomendou o software. Deve definir os termos técnicos usados no documento. Não deve conter suposições sobre o conhecimento ou experiência do leitor. Deve descrever os serviços oferecidos ao usuário. Os requisitos não funcionais do sistema também devem ser descritos nessa seção. Essa descrição pode usar linguagem natural, diagramas ou outras notações compreensíveis para os clientes. Normas produtos que devem ser seguidos devem sem especificados. Pode incluir modelos gráficos do sistema que mostram relacionamentos entre os componentes do sistema, o sistema e seu ambiente. Deve descrever os pressupostos fundamentais em que o sistema se baseia, bem como quaisquer mudanças previstas, em decorrência da evolução do hardware, de mudanças nas necessidades do usuário, etc. Essa seção é útil para projetistas de sistemas, pois pode ajudá-los a evitar decisões capazes de restringir possíveis mudanças futuras no sistema. Deve fornecer informações detalhadas e especificas em relação à aplicação em desenvolvimento, além das descrições de hardware e banco de dados, por exemplo. Os requisitos de hardware definem as configurações mínimas do sistema. Requisitos de banco de dados, definem a organização lógica dos dados usados pelo sistema e os relacionamentos entre esses dados. Vários índices podem ser incluídos no documento. Pode haver, além de um índice alfabético normal, um índice de diagramas, de funções, dentre outros que sejam pertinentes.
A seguir, teremos então exposição de um modelo de documento de requisito, a partir da estrutura citada e suas respectivas descrições, a qual propiciará uma visão mais prática do teor de um documento como tal finalidade. Para fins didáticos, separaremos com seção em um quadro diferente. Lembre-se que essa proposta não é única e definitiva, podendo sofrer adaptações, inclusões e exclusões, a depender da necessidade do cliente dos responsáveis pela sua criação. Fonte: Guisa para criação de documentos de requisitos. Acessível pela URL: http://www.google.com.br/url?sa=t&rct=j&q=documento %20de %20requisitos&source=web&cd=4&sqi=2&ved=0CDoQF jAD&url=http%3A%2F%2Fwww.fernandoans.site50.net %2Fcurso %2Fcurso04%2FDocumentoDeRequisitos.pdf&ei=berUTt
m8AqfX0QGrydn8AQ&usg=AFQjCNFY3KwpGcWNoD F0fg5SEDB407Ht9Q.
Ficha Técnica Introdução <Este espaço deve ser usado para descrever os objetivos deste documento e o público ao qual ele se destina. Complete e/ou adapte o texto abaixo para fornecer essas informações.> Este documento especifica o sistema <Nome do sistema>, fornecendo aos desenvolvedores as informações necessárias para o projeto e implementação, assim como para a realização dos testes e homologação do sistema. Visão geral deste documento <Esta seção fornece uma breve descrição de como o resto deste documento está organizado. Complete e/ou adapte o texto abaixo para fornecer essa informação.> Contemple com as informações necessárias para fazer um bom uso deste documento, abrangendo a maioria dos objetivos e das convenções a serem adotadas no texto, bem como uma lista de referências para outros documentos relacionados. Para as demais seções, siga orientação como descrito abaixo. • Seção 2 – Descrição geral do sistema: apresenta uma visão geral do sistema, caracterizando qual é o seu escopo e descrevendo seus usuários. • Seção 3 – Requisitos funcionais (casos de uso): especifica todos os requisitos funcionais do sistema, descrevendo os fluxos de eventos, prioridades, atores, entradas e saídas de cada caso de uso a ser implementado. • Seção 4 – Requisitos não funcionais: especifica todos os requisitos não funcionais do sistema, divididos em requisitos de usabilidade, confiabilidade, desempenho, segurança, distribuição, adequação a padrões e requisitos de hardware e software. • Seção 5 – Descrição da interface com o usuário: apresenta desenhos, figuras ou rascunhos de telas do sistema.
Equipe Responsável pela Elaboração <nome> <identificação: carga, setor, divisão, região> <nome> <identificação: carga, setor, divisão, região> <nome> <identificação: carga, setor, divisão, região> <nome> <identificação: carga, setor, divisão, região> Público Alvo Este manual destina-se a <especifique o público alvo deste documento>
Versão <x.y> - <local>, <mês> de <ano> Dúvidas, críticas e sugestões devem ser encaminhadas por escrito para o seguinte endereço postal: <especifique o endereço para correspondência> Ou para o seguinte endereço eletrônico: <especifique o e-mail para contato> Recomendamos que o assunto seja identificado com o título desta obra. Alertamos ainda para a importância de se identificar o endereço e o nome completos do remetente para que seja possível o envio de respostas.
Sumário
INTRODUÇÃO............................................................................................16 Visão geral deste documento..............................................................................16 Convenções, termos e abreviações....................................................................19 Identificação dos Requisitos ........................................................................19 Prioridades dos Requisitos...........................................................................19
DESCRIÇÃO GERAL DO SISTEMA.........................................................19 Abrangência e sistemas relacionados................................................................19 Descrição dos usuários.......................................................................................19 <Opcional> <Nome de um tipo específico de usuário>................................19 <Opcional> <Nome de outro tipo específico de usuário >............................19
REQUISITOS FUNCIONAIS......................................................................20 <Nome de subseção para agrupar casos de uso correlacionados>................20 [RF001] <Nome do caso de uso>................................................................20 Fluxo de eventos principal.........................................................................................................20 <Opcional> Fluxos secundários (alternativos e de exceção)....................................................20 [RF…] <Nome de outro caso de uso>.........................................................20 <Nome de outra subseção para agrupar outros casos de uso correlacionados>.................................................................................................. 20
REQUISITOS NÃO FUNCIONAIS.............................................................21 Usabilidade............................................................................................................ 21 [NF001] <Nome do requisito>.......................................................................21 [NF…] <Nome do requisito>........................................................................21 Confiabilidade....................................................................................................... 21 [NF…] <Nome do requisito>.........................................................................21 Desempenho......................................................................................................... 21 [NF…] <Nome do requisito>.........................................................................21 Segurança.............................................................................................................. 21 [NF…] <Nome do requisito>.........................................................................21 Distribuição........................................................................................................... 21 [NF…] <Nome do requisito>.........................................................................21 Padrões.................................................................................................................. 21 [NF…] <Nome do requisito>.........................................................................21 Hardware e software............................................................................................. 21 [NF…] <Nome do requisito>.........................................................................21
<OPCIONAL> DESCRIÇÃO DA INTERFACE COM O USUÁRIO...........21 <Identificador de uma interface>.........................................................................21 <Opcional> Críticas da interface..................................................................21
Convenções, termos e abreviações <Esta subseção deve descrever as convenções, termos e abreviações necessários para interpretar apropriadamente este documento. As explicações necessárias podem ser fornecidas diretamente nesta seção ou através de referências para outros documentos ou para apêndices deste documento. Complete e/ou adapte o texto abaixo para fornecer essas informações.> A correta interpretação deste documento exige o conhecimento de algumas convenções e termos específicos, que são descritos a seguir. Identificação dos Requisitos Por convenção, a referência a requisitos é feita através do nome da subseção onde eles estão descritos, seguido do identificador do requisito, de acordo com o esquema abaixo: [nome da subseção.identificador do requisito] Por exemplo, o requisito [Recuperação de dados.RF016] está descrito em uma subseção chamada “Recuperação de dados”, em um bloco identificado pelo número [RF016]. Já o requisito não funcional [Confiabilidade.NF008] está descrito na seção de requisitos não funcionais de Confiabilidade, em um bloco identificado por [NF008]. Prioridades dos Requisitos Para estabelecer a prioridade dos requisitos foram adotadas as denominações “essencial”, “importante” e “desejável”. • Essencial é o requisito sem o qual o sistema não entra em funcionamento. Requisitos essenciais são requisitos imprescindíveis, que têm que ser implementados impreterivelmente. • Importante é o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim. • Desejável é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são requisitos que podem ser deixados para versões posteriores do sistema, caso não haja tempo hábil para implementá-los na versão que está sendo especificada
Descrição geral do sistema <Descreva aqui, em linhas gerais, os objetivos do sistema, comunicando o propósito da aplicação e a importância do projeto para todas as pessoas envolvidas. Se for necessário apresentar detalhes mais técnicos sobre o sistema, você também pode usar esta seção para descrever em linhas gerais a arquitetura do sistema, indicando seus módulos principais, o uso (se existir) da Internet ou outra rede de comunicação, componentes on-line e off-line, e a interação (se existir) com outros sistemas. Use um diagrama se achar conveniente.> Abrangência e sistemas relacionados <Nesta seção, descreva em linhas gerais o que o sistema irá fazer (suas principais funcionalidades) e o que ele não irá fazer (escopo negativo), deixando claro se o sistema irá interagir com outros sistemas relacionados ou se ele é independente e totalmente auto-contido. As funcionalidades principais do sistema devem ser apenas citadas, para dar uma idéia geral ao leitor dos serviços que serão fornecidos pelo sistema. Os detalhes serão fornecidos posteriormente, na seção 3 deste documento. Funcionalidades que a princípio seriam da alçada do sistema e que não serão implementadas também devem ser listadas, registrando-se o motivo pela qual elas não serão contempladas (porque serão fornecidas por outros sistemas relacionados, por exemplo, ou porque serão implementadas apenas em projetos futuros). Se o sistema for independente e totalmente auto-contido diga isso explicitamente, caso contrário, liste e descreva brevemente os outros sistemas com os quais este sistema deve interagir, explicando, de maneira geral, quais os papéis de cada um e o meio de comunicação entre eles.> Descrição dos usuários <Para efetivamente prover produtos e serviços que atendam às necessidades dos usuários, é necessário entender os desafios que eles enfrentam para executar suas funções. Esta seção deve descrever os futuros usuários do sistema e os principais problemas que limitam sua produtividade. Descreva os aspectos gerais, relacionados a todos os usuários, aqui. Depois, se for necessário, descreva nas subseções abaixo as características específicas de cada usuário.> <Opcional> <Nome de um tipo específico de usuário> <Se for conveniente fornecer mais detalhes sobre um tipo específico de usuário, use esta subseção para descrevê-lo.> <Opcional> <Nome de outro tipo específico de usuário > <Prossiga no detalhamento das características dos usuários, descrevendo todos os tipos de usuário que for necessário, cada um em uma subseção.> …
Requisitos funcionais <Nesta seção, apresente todos os requisitos funcionais, ou casos de uso, do sistema. Em sistemas grandes é comum haver muitos casos de uso e, para facilitar a visualização deste documento, você pode agrupá-los em subseções de casos de uso correlacionados. Os nomes das subseções devem ser únicos e pequenos (3 palavras no máximo) e podem ser formados por palavras, números e/ou abreviações. Cada um dos casos de uso deve ser descrito em um bloco específico, seguindo o modelo descrito abaixo. O identificador do bloco deve conter o número do caso de uso (por exemplo, [RF001]) e o seu nome. Se os casos de uso forem agrupados em subseções específicas, a numeração deles deve ser reiniciada a cada subseção (dentro de uma mesma subseção, todo caso de uso deve ter um número de identificação único). Quando a primeira versão deste documento for disponibilizada para a equipe de desenvolvimento, os nomes das subseções e os números dos casos de uso não devem ser modificados ou reaproveitados, para não invalidar referências externas feitas a eles.> <Nome de subseção para agrupar casos de uso correlacionados> <Utilize este espaço para descrever características comuns dos casos de uso desta seção, explicitando o motivo do seu agrupamento em uma seção única. Se todos os casos de uso desta seção estiverem relacionados com o mesmo ator você pode informar isso aqui, especificando qual é o ator em questão, e eliminar o campo “Ator:” das descrições dos casos de uso feitas nos blocos a seguir.> [RF001] <Nome do caso de uso> <Opcional – forneça uma pequena explicação do propósito do caso de uso (útil quando o nome do caso de uso não deixa suficientemente claro qual é o seu objetivo) e o(s) seu(s) respectivo(s) ator(es). Em seguida, substitua um dos símbolos abaixo por , para indicar a prioridade do caso de uso.> Ator: <informe o(s) ator(es) do caso de uso > Essencial Prioridade: <Opcional> Interface(s) associada(s): <inclua aqui o(s) identificador(es) da(s) respectiva(s) interface(s) do caso de uso (descrita(s) na Seção 5).> Entradas e pré condições: <Liste aqui todas as entradas e/ou pré condições do caso de uso. Pré condição de um caso de uso é o estado em que o sistema deve estar para realizar o caso de uso.> Saídas e pós condições: <Liste aqui todas as saídas e/ou pós condições do caso de uso. Pós condição de um caso de uso é a lista de possíveis estados em que o sistema pode estar imediatamente após o término da realização do caso de uso.> Fluxo de eventos principal <Descreva aqui o fluxo de eventos principal que ocorre durante a execução do caso de uso.> <Opcional> Fluxos secundários (alternativos e de exceção) <Fluxo secundário XXX> <Use este espaço para descrever o fluxo secundário XXX do caso de uso.> <Fluxo secundário YYY> <Prossiga na descrição dos fluxos secundários do caso de uso, descrevendo cada um deles separadamente.> [RF…] <Nome de outro caso de uso> <Utilize os mesmos campos mostrados no bloco anterior
Requisitos não funcionais <Esta seção deve conter os requisitos não funcionais do sistema. Para uma melhor organização deste documento, <Opcional> Descrição da interface com o usuário utilize as subseções abaixo para agrupar os requisitos não <Esta seção deve conter desenhos ou rascunhos das telas funcionais relacionados. Naturalmente, o número e tipo de do sistema que forem necessários ou convenientes para subseções utilizadas depende do sistema que está sendo esclarecer algum dos requisitos do sistema. Para sistemas especificado e não é preciso utilizar todas elas. que possuem protótipos ou versões já desenvolvidas é Simplesmente elimine as subseções para as quais não for possível capturar as telas e apresentar figuras das mesmas. encontrado nenhum requisito. Use nomes e/ou números para identificar cada interface e Os requisitos não funcionais devem ser identificados com um descreva-as em seções independentes.> identificador único, da mesma maneira que os requisitos <Identificador de uma interface> funcionais (casos de uso). Inicie a numeração com o <Descreva a interface em questão, através de figuras, identificador NF001 e prossiga incrementando os números a diagramas e/ou texto. medida que forem surgindo novos requisitos não funcionais. <Opcional> Críticas da interface Reinicie a numeração em cada subseção. Forneça também um <Você pode fazer aqui a descrição de críticas simples de nome para o requisito, como foi feito para os requisitos interface, como o tamanho e máscara de campos, funcionais. simplificando assim a descrição dos fluxos de exceção.> Descreva o requisito, assinale a sua prioridade e, em seguida, <Identificador de outra interface> caso o requisito esteja relacionado a um caso de uso ou a um <Prossiga no detalhamento das interfaces do sistema, grupo de casos de uso específicos, utilize o campo “Caso(s) descrevendo todas que for necessário, cada uma em uma de uso associado(s):” para identificar o(s) caso(s) de uso subseção.> correspondente(s). Se for um requisito não funcional do sistema como um todo, esse campo não precisa ser utilizado.> Usabilidade Aula 06: ENGENHARIA DE REQUISITOS E ESTUDOS Esta seção descreve os requisitos não funcionais associados à DE VIABILIDADE facilidade de uso da interface com o usuário, material de treinamento e documentação do sistema. Introdução da aula [NF001] <Nome do requisito> <Descreva o requisito não funcional e substitua um dos Quando nos referimos a atividade de estudo de símbolos abaixo por , para indicar a sua prioridade.> viabilidade, estamos concentrados, no contexto da fase inicial a Essencial Importante Prioridade: qualquer projeto de software, na realização de um “checklist” <Opcional> Caso(s) de uso associado(s): <use este campo sobre os problemas identificados e que deverão ser para identificar a que caso(s) de uso o requisito de usabilidade solucionados. está relacionado.> [NF…] <Nome do requisito> Portanto, como resultado do estudo de viabilidade, é possível <Utilize os mesmos campos mostrados no bloco anterior para determinar pontos críticos do projeto, o que se tem de descrever este e os demais requisitos não funcionais de diferentes alternativas de soluções para o problema e, até usabilidade.> mesmo, a conclusão de que o projeto tem realmente condições Confiabilidade de ser finalizado, ou seja, será levado adiante ou não. Esta seção descreve os requisitos não funcionais associados à freqüência, severidade de falhas do sistema e habilidade de De maneira pagmática, na atividade vinculada ao estudo de recuperação das mesmas, bem como à corretude do sistema. viabilidade incide de um documento com formato previamente [NF…] <Nome do requisito> definido e que tem a importante missão de descrever,de <Utilize os mesmos campos mostrados na seção 4.1 para maneira geral: o problema a ser tratado; a proposta e o plano do descrever este e os demais requisitos não funcionais de projeto; e as soluções acompanhadas de análises comparativas confiabilidade.> entre elas. Desempenho Esta seção descreve os requisitos não funcionais associados à eficiência, uso de recursos e tempo de resposta do sistema. Livro: SOMMERVILLE, I., Engenharia de [NF…] <Nome do requisito> Software, 9ª Edição. Pearson, 2011. Capítulo 4: <Utilize os mesmos campos mostrados na seção 4.1 para Engenharia de Requisitos. descrever este e os demais requisitos não funcionais de desempenho.> - Aprendeu o conceito de engenharia de requisitos. Segurança - Compreendeu o conceito de estudos de viabilidade. Esta seção descreve os requisitos não funcionais associados à - Aprendeu a importância da atividade de estudos de integridade, privacidade e autenticidade dos dados do sistema. viabilidade. [NF…] <Nome do requisito> - Analisou o que deve ser tratado em um documento de <Utilize os mesmos campos mostrados na seção 4.1 para estudos de viabilidade.. descrever este e os demais requisitos não funcionais de segurança.> exercicios Distribuição Esta seção descreve os requisitos não funcionais associados à 1) Qual a premissa básica para a engenharia de requisitos: distribuição da versão executável do sistema. a. Como fazer e o que fazer? [NF…] <Nome do requisito> b. Como fazer? <Utilize os mesmos campos mostrados na seção 4.1 para c. O que fazer? (resposta certa) descrever este e os demais requisitos não funcionais de
d. Definir o stakeholder. e. Definir uma estrutura de software. f. 2) É processo da engenharia de requisitos: a. Definir stakeholders. b. Analisar requisitos. (resposta certa) c. Definir uma estrutura de software. d. Definir arquitetura de rede. e. Definir sistema gerenciador de banco de dados. f. 3) Qual o objetivo da análise de viabilidade sobre um determinado projeto? a. Gerar um relatório sócio-ambiental do projeto. b. Gerar um relatório técnico da área de TI. c. Gerar um relatório para os fornecedores envolvidos no projeto. d. Gerar um relatório sobre os custos, prazos e benefícios do projeto. (resposta certa) e. Gerar um relatório de financeiro do projeto. Engenharia de Requisitos Engenharia é uma palavra que costuma sempre nos lembrar sobre processos relacionados a criação, ampliação e/ou reforma. Também é comum pensarmos em criação – mediante a engenharia civil. Então, quando pensamos em um engenheiro, estamos pensando em algum tipo de construção. Pois bem, existem várias variáveis que o profissional da área de atentar-se antes de simplesmente, por exemplo, estudar as composições físicas ou químicas mais apropriadas. Para isso, ele precisa averiguar! Portanto, quando falamos em engenharia de requisitos, estamos a tratar de um processo que define atividades para uma produção e manutenção adequada (lembrando que esse documento serve para todos os envolvidos, necessitando cobrir as necessidades tanto em termos técnicos como de áreas comuns), do documento de requisitos de software, o qual foi estudado na unidade anterior. Este importante documento para direcionamento do sistema a ser desenvolvidos. Para atingir esse objetivo, temos uma sistematização de um processo para definir o perfil do software. A premissa básica então para a engenharia de requisitos de software é definir o que deve ser feito; ou seja, é um trabalho de interpretação. Ela não se preocupa no como deve fazer feito. Com isso, questões tecnológicas como linguagem de programação, sistema gerenciador de banco de dados, topologias de redes de computadores, não representam o cerne a ser detalhado, mas sim todas as necessidades que os “humanos” esperam da “máquina”. Na figura 1, temos a definição do processo de engenharia de requisitos:
Figura 1 - Processo da Engenharia de Requisitos Conforme citado no início de nossa aula, teremos uma aula para tratar cada um dos componente do processo. Por enquanto, trataremos apenas de explicar o modelo de maneira geral. O estudo de viabilidade aponta então se o projeto está adequado para responder a contento ao que a empresa quer, e que esteja apoiado nas condições dos recursos disponíveis. Este gera então um relatório a qual aponta as conclusões e devidas justificativas. Ou seja, o projeto pode ser cancelado antes mesmo de qualquer digitação de linha de código. Na análise de requisitos, segundo passo do processo, que busca identificar entre os stakeholders as funcionalidades ideais e fundamentais para o software. Definição dos requisitos, como o nome já sugere, é responsável em receber todas as informações referente a análise de requisitos e promover então o que será especificado como requisito para o sistema que será definido. Por fim, a fim de consolidar o processo com o nível de detalhe e especificidade necessários, são descritos todos os requisitos que já estão definidos. Importante observar que a partir do 2º passo (análise de requisitos), temos setas bidirecionais, que estabelecem que pode haver um retorno dentre as atividades, principalmente mediante a identificação de um erro na fase anterior àquela que está sendo executada no momento. Lembre-se que ao término do processo, tudo que estiver contido no documento de requisito de software deve ser atendido plenamente; portanto, o lapso culminará em um sistema sem qualidade. No contexto Na figura 2 está disposta um modelo mais completo, em espiral, do processo de engenharia de requisitos, segundo proposta por Sommerville (2011):
É possível a integração com os outros sistemas da organização (de um ponto de vista tecnológico)? Com que facilidade é que se consegue partilhar informação entre estes sistemas? Analisando dos itens supracitados, percebemos que a questão mais crítica é a primeira, já que um sistema que não contribua para os objetivos da organização não lhe traz qualquer valor acrescentado e como tal a sua existência não se justifica. Apesar de parecer óbvio, frequentemente constata-se que um determinado software não contribuem para os objetivos das respectivas organizações, quer seja por interesses externos (políticos ou organizacionais) ou por falta de clareza na definição dos objetivos da organização, porém ele foi desenvolvido ou até mesmo já adquirido. Figura 2 - Processo de Engenharia de Software em Espiral (Sommerville, 2011) Estudos de Viabilidade Para todo projeto que estimamos realizar, seja ele para nós ou para a empresa a qual colaboramos, uma pergunta muito básica e fundamental sempre deve ser respondida: Será que contribui para os meus objetivos? Fonte da figura: http://t0.gstatic.com/images? q=tbn:ANd9GcRj9f_AdCSgYjjlkWPB6T7ejCJ6pfbxJBnL Uma estimativa realizada para verificar se as necessidades do usuário podem ser satisfeitas usando correntes de software e hardware, à custo e prazo efetivo. A partir então do resultado alcançado da reflexão a partir desse questionamento, é que No tocante a área da tecnologia da informação e que estamos estudando, vamos então adicionar os seguintes questionamentos: 1. Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o sistema pode ser implementado? 2. Caso haja necessidade de internação entre diferentes sistemas, será que esta é possível? Conforme o nome sugere, pretende-se com este estudo avaliar se, de um ponto de vista tecnológico e organizacional, se o projeto é viável e se representará uma solução capaz de ser executada e de agregar valor. Portanto, muito antes de pensarmos em requisitos, temos que saber se o sistema pode ser concluído e/ou mantido, por exemplo. São outros exemplos de questões que devem ser avaliadas: De que forma é que o sistema irá contribuir diretamente para os objetivos da organização? Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização? Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas falhas?
No estudo de viabilidade, é comum termos várias fontes de informações. Tipicamente, temos os seguintes stakeholders: a) Quem poderá fornecer esta informação serão os utilizadores dos sistemas atuais e do sistema a implementar. b) Os responsáveis pelos departamentos nos quais o sistema será usado. c) Técnicos que estejam familiarizados com as tecnologias envolvidas (do novo sistema e dos sistemas existentes). d) Responsáveis pela manutenção futura do sistema a implementar e, de um modo geral, todos aqueles que terão qualquer tipo de interação com o novo sistema (ou que sejam por ele afetados). Deve, portanto identificar-se que informação é necessária para responder a estas questões e quem possui esta informação, procedendo-se de seguida a escolha de todos os dados disponíveis para permitir mais exatidão e visões no âmbito do projeto, permitindo realmente avaliar a sua viabilidade. A partir das conclusões obtidas, outra atividade no processo de estudo de viabilidade é a produção de um relatório e deverá determinar a continuação do desenvolvimento do projeto, tornando mais claras as restrições (econômicas, temporais e organizacionais) do projeto e definindo mesmo alguns requisitos de alto nível. Acompanhe abaixo um exemplo resumido de um relatório referente a um estudo de viabilidade Fonte: (http://fatecsjc1.wordpress.com/relatorio-deviabilidade/) Relatório de viabilidade Objetivos Gerais da organização Hoje o número de pessoas que acessam à Internet é muito grande, principalmente entre os jovens. Eles passam horas em bate papos on-line, sites de relacionamentos como o Orkut, jogos on-line e fazem tudo que podem pela Internet, até namorar. A facilidade com que se compra on-line hoje também é muito grande, a segurança está bem maior, e para um maníaco por Internet esta facilidade seria muito bem vinda.
Para a empresa, iria abranger um nicho de mercado ainda inexplorado na nossa região, um mercado aberto com clientes em potencial. O fato de ele receber os dados em seu micro e imprimi-lo, praticamente zera os erros tão freqüentes em ligações, como endereço errado, troco errado, esquecimento de detalhes, como não colocar cebola… Outra facilidade é que o pagamento por cartão de débito e crédito minimiza o problema dos trocos tão raros hoje, e assalto em relação ao moto-boy, já que na entrega não haveria transporte de dinheiro, e também o gerente não tem que se preocupar se vai receber ou não, porque o dinheiro já foi depositado na conta da empresa. Mais uma vantagem é o fato do software gerar um relatório, com a quantidade de pizzas vendidas por dia semana ou mês, valor, pizzas mais pedidas, locais mais pedidos, clientes mais fiéis, etc. Tecnologias, Custos e Prazos A implementação é bem simples, já que toda pizzaria hoje em dia já tem um computador, e que caso não tenha os requisitos mínimos de hardware e software para o sistema, é bem leve, não necessitando de um alto investimento nesse ponto, o acesso à Internet nos centros da cidade não é um problema e hoje em dia a tendência é melhorar cada vez mais, o conhecimento exigido para o uso do software é bem pequeno, mas há um treinamento para o usuário já contemplado neste projeto. Os custos para implementação são bem baixos em relação a um novo mercado ainda inexplorado, e levando-se em consideração que não é necessário a compra de equipamentos sofisticados, e que a evolução da tecnologia não afeta negativamente o funcionamento do site. O prazo para implementação é bem reduzido, com acompanhamento da evolução por parte do cliente o que torna o custo do projeto acessível. Caso a empresa já tenha um site, não há problema nenhum porque podemos colocar um link nesse site para direcionar para o pizza on-line. Em relação ao software de controle interno da pizzaria, também não afetará já que o sistema pode gerar relatórios tanto para impressão ou até comunicação com o software existente, para isso no entanto precisará de um estudo prévio do software para verificar a compatibilidade. Mediante o disposto no texto do relatório, percebemos que trata-se de um software para venda de pizza através da internet. Acompanhe alguns pontos da apresentação do sistema: 1) É proposto o desenvolvimento de um sistema para Pizzaria online que inclui cadastros de clientes e um cadastro de produtos (Cardápio da Pizzaria) divulgados no site. 2) O objetivo do sistema consiste em aperfeiçoar os serviços prestados pela pizzaria evitando diminuir falhas humanas (Ex.: Eu não pedi pizza com cebola) e reduzir o tempo de entrega, economizar em custos telefônicos e rapidez no atendimento ao cliente. 3) A PO possui propriedades emergentes funcionais como o controle e organização de cadastro de clientes e não funcionais como a usabilidade e acessibilidade do mesmo. Analisando então o teor do relatório, percebemos que é necessário contextualizar a empresa em todo o seu negócio, analisar então custos e prazos nas necessidades vinculadas para uma solução; por fim, demonstrar a rentabilidade do projeto, principalmente mediante o que será agregado para a empresa. Disciplina: REQUISITOS DE SISTEMAS Aula 07: ELICITAÇÃO DE REQUISITOS
Conforme tratamos no início do estudo da disciplina, é preciso saber e fazer saber a(s) finalidade(s) de um software. Portanto, um fundamental questionamento que precisa ficar bem esclarecido para todos os envolvidos é: O QUE REALMENTE QUEREMOS?
Figura 1. Fonte: http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/intro/pr ocesso.htm A figura 1 demonstra um cenário que envolve dois fatores: céu com nuvens e uma grama verde. Apenas estes são substancialmente suficientes para diferentes interpretações, sujeitando a diversas soluções que não compreende a resolução efetiva do que se queria. Importante ver que nem mesmo o próprio cliente soube explicar com exatidão o que ele queria. Podemos então rapidamente transferir ao cliente a responsabilidade pela não conformidade do produto entregue; destituindo-nos de qualquer culpa, então friamente nos posicionamos: “lhe entregamos o que foi pedido!”
Fonte: http://ogerente.com.br/rede/carreira/o-que-e-umproblema Seria então esse o perfil mais adequado? Certamente que se queremos ser uma empresa de referência para segmentos de software e/ou engenharia de requisitos, definitivamente, NÃO! Vamos então imaginar um cenário em que o cliente esteja apresentando suas necessidades e seus objetivos para um sistema computacional. Lá estão alguns diretores e representantes da empresa contratada: - Queremos que o sistema faça: isso, isso, aquilo, isso juntamente com aquilo... - Também podemos então adicionar aquilo outro que vi no do meu colega, que pertence aquela empresa (detalhe: a empresa é de outro segmento comercial).
Então, quando do uso da palavra (de terno e gravata), fala de maneira convincente: - Tudo anotado e esclarecido. Tenho certeza que ficará muito satisfeito com o que lhe entregaremos. A diretoria reúne os usuários que serão “beneficiados” com o sistema; fala sobre como a vida deles mudará – inclusive já está levantando quantos deverão permanecer na empresa. Faz o convite para o representante da contratada prestar esclarecimento. Novamente (ainda com terno e gravata), ela faz uma apresentação do seu currículo e em quer resultará o projeto. Detalhe: alguns funcionários começam a especular perigo de demissão em massa. Então soa a pergunta: - Alguém tem alguma sugestão? O genro de um dos diretores levanta-se na platéia e saúda a iniciativa como sendo de tempos modernos para a organização, pedindo aos presentes uma salva de palmas.
Depois de algum tempo de espera eis que o documento de requisitos de software está pronto. E é remetido para análise. Depois de 18 meses de trabalho, eis então o feedback: após a análise de um documento que julgamos muito difícil, chegamos a conclusão que NÃO FOMOS CORRETAMENTE ENTENDIDOS! ´´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 ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em questão. Sob o escopo do analista de negócios, a elicitação (em inglês, “Elicitation”) é a atividade responsável em compreender as necessidades e preocupações das partes interessadas e os ambientes no qual elas trabalham ou operam. Portanto, é preciso saber que existe uma distinção entre “elicitar” e “levantar”, uma vez que o primeiro termo é mais abrangente é o foco na extração das necessidades verdadeiras, que podem ou não estar explícitas. A atividade da elicitação dos requisitos não é habitualmente desenvolvida forma isolada, visto que a identificação de requisitos costuma aparecer de forma cíclica durante sessões tanto de levantamento quando de validação, portanto requer uma combinação de técnicas para que seja completa. Conforme estudamos na primeira unidade, as técnicas de levantamento de requisitos são: brainstorming, análise documental, entrevistas, observação, prototipagem, workshops de requisitos e pesquisa/questionários. No tocante as tarefas inerentes ao processo da elicitação dos requisitos, temos: a preparação, condução, documentação e confirmação dos resultados da elicitação.
A elicitação de requisitos envolve o processo de identificar junto aos stakeholders, frente ao sistema ou produto, os seguintes pontos: 1. Os alvos a serem alcançados; 2. Os pontos a serem acompanhados; 3. Como se encaixa no contexto das necessidades do negócio; e 4. O comportamento ou operacionalização da solução rotina da solução na rotina da empresa. Mas então porque se apresenta como um processo extremamente complexo? Vejam: Problemas de escopo: excesso ou falta de detalhamento. Os clientes/usuários desconhecem o que é importante (ou até mesmo quer ocultar), inibindo os limites do sistema, o que dificulta uma definição completa. Problemas de compreensão: omitem informações que julgam óbvias; clientes/usuários desconhecem ou estão em dúvidas sobre as necessidades e como seu papel é fundamental; é leigo ou limitado no conhecimento de seu ambiente computacional ou do domínio do seu negócio e etc. Problemas de volatilidade: mudanças constantes nos requisitos. A partir deste cenário, algumas ações são sugeridas para superar estes problemas, a fim de uma abordagem organizada para o processo da elicitação. São eles: Considerar a viabilidade técnica e de negócio para o sistema proposto; Identificar as pessoas que vão auxiliar a especificar os requisitos e incluir seus preconceitos organizacionais; Definir o ambiente técnico no qual o sistema será instalado; Ter domínio sobre o que é o sistema e o que ele realmente representa; Envolver um ou mais métodos de elicitação de requisitos; Sempre incentivar a participação de várias pessoas, possibilitando a concepção dos com a contribuição de diversos pontos de vista; Independente do tamanho do que esteja sendo construído, os produtos da utilização dos passos trabalho incluem: Ter totalmente bem estruturadas as necessidades e viabilidade; bem como, a definição do limite de escopo do sistema ou produtos; A relação de clientes, usuários e outros stakeholders que participaram da atividade de elicitação de requisitos; Conhecimento descritivo do ambiente técnico do sistema; A lista de requisitos e suas respectivas aplicações regras de domínio. Cenários de uso que promovem uma concepção do uso do sistema sob diferentes condições de operação; Informação de um modelo que eventualmente tenha sido desenvolvido para melhor definir os requisitos.
Revisões realizadas por todas as pessoas que tenham participado da elicitação de requisitos. Leiam a matéria abaixo e observem algumas características importantes em um analista de negócios, a qual aponta adjetivos importantes para o responsável em atuar em qualquer uma das etapas da elicitação de requisitos (Fonte: http://imasters.com.br/artigo/17785/carreira/softskills_do_analista_de_negocios/): De acordo com o Babok, Análise de Negócios é: O conjunto de atividades e técnicas utilizadas para servir como ligação entre partes interessadas no intuito de compreender a estrutura, políticas e operações de uma organização e para recomendar soluções que permitam que a organização alcance seus objetivos. Recentemente tive que pensar, por motivos profissionais, sobre os skills necessários para um Analista de Negócios. Após muita pesquisa e conversas com colegas que já estão há um tempo trabalhando com isso, em suas diversas denominações (Além de Analista de Negócios, também Analista de Sistemas, de Requisitos, Funcional, entre outros), ficou claro que os soft skills necessários são: Ser bom ouvinte Ser um bom ouvinte é de extrema importância. Ajuda a evitar distrações enquanto o cliente está lhe explicando alguma funcionalidade/necessidade, a manter uma boa postura e contato visual diretamente com o cliente. Afinal, você precisa entender e tirar dúvidas sobre o que ele está dizendo. Sem ser um bom ouvinte, muitas coisas passarão despercebidas e seu levantamento poderá ter furos que só serão detectados em outro momento. Ser um bom questionador As maiorias dos requisitos saem de discussões com o cliente. É frequente a conversa com pessoas e até um grande grupo de pessoas para conseguirmos mais detalhes sobre determinado requisito. Estar atento e fazer perguntas-chave são de extrema importância para o levantamento de requisitos. É normal que, com o tempo, a experiência lhe proporcione a sabedoria necessária para fazer as perguntas corretas no momento certo. Ser observador Um analista observador percebe, em comentários e em outras situações junto ao cliente, sua real necessidade (cliente que, muitas vezes, não sabe do que está precisando), vê um novo requisito, vê uma nova oportunidade de negócio. Além disso, consegue oferecer um algo a mais no produto final, garantindo, além do real valor ao negócio do cliente, a satisfação e uma boa imagem junto aos usuários finais do sistema. Escrever bem Com certeza, um dos skills mais importantes, senão, o mais importante, é um analista que escreva bem, que consiga comunicar as necessidades do cliente em texto, em um formato que tanto os clientes, quanto a equipe de desenvolvimento, entendam sem dificuldade. Dominar o idioma na qual o requisito é escrito é de extrema importância. Infelizmente, muitas pessoas têm dificuldades com seu próprio idioma. Para aprimorar essa habilidade é preciso ler mais - livros, revistas, jornais - e também praticar, escrevendo. Ser organizado Como um analista trabalha com muitas informações ao mesmo tempo, ele deve ser organizado para que consiga passá-las de maneira correta. Saber estruturar muito bem suas informações, mesmo antes de serem passadas para o papel, é muito importante, pois elas podem ser solicitadas a qualquer momento por um gerente, ou por um cliente. Ser organizado também quer dizer organizar bem os e-mails. Afinal,
recebemos vários e-mails dos mais variados assuntos. Montar uma estrutura básica, mesmo que apenas você vá cuidar dessas informações, ajudará em sua organização. Ser criativo "O melhor analista de requisitos inventa requisitos" (Robertson - 2002). Durante as conversas com o cliente, o analista descobre valores para o projeto que às vezes nem o próprio cliente conhece. Esse skill está muito relacionado com o terceiro, "ser observador". Um analista que é um bom observador, com certeza visualizará novos requisitos, mesmo sem a descrição direta, e conseguirá oferecer melhores soluções para seu cliente. Perguntei aos meus colegas, se existiam todos esses skills em um único profissional. A resposta, obviamente, foi negativa, mas uma coisa foi unanimidade: o profissional deve identificar quais são seus principais gaps, seus pontos a melhorar e ir atrás desses skills. Sei que todas as profissões têm suas dificuldades e seus méritos, porém há muitas atribuições que podem ser aprendidas através de cursos e estudo em livros, além de certificações. Porém, esses skills são características pessoais, que ou nascemos com elas e vamos aprimorando durante nosso crescimento, ou que não nos são natas e que precisamos nos esforçar muito para mudar e adquiri-las quando adultos. O melhor é que a maioria das características que listei trarão benefícios também para a sua vida como um todo, não apenas profissionalmente. Cientes que não é tão trivial e simples como demonstra ser, elicitar requisitos detém boa parte do tempo e considerável esforço, mas é uma etapa estratégica e fundamental para o desenvolvimento de um projeto tenha efetividade.
Aula 08: VALIDAÇÃO DE REQUISITOS O processo de validação de requisitos é também uma fase importante na elaboração de um documento de requisitos. Mesmo atendendo as etapas de elicitação, pode incorrer que erros passem despercebidos na etapa, pode criar certos problemas quando esses erros forem detectados numa fase posterior, ou seja, o documento de requisitos já terá sido validado pelo cliente. Na etapa de elicitação aprendemos que vamos levantar e evidenciar o requisito. Agora, vamos DEMONSTRAR que conseguimos compreender e definir bem as características a serem incorporadas no software. Para este momento, o contatado é quem assume o papel principal, sendo o foco da comunicação; o contratante acompanha e avalia. Esse processo da engenharia de requisitos trata em especial dos critérios relacionados à consistência, precisão, contextualização de requisitos levantados no processo de identificação e descoberta e de análise e negociação de requisitos. Segue uma relação de propriedades que são avaliadas no tocante ao documento de requisitos de software pela equipe responsável na validação: 1. 2. 3. 4. 5.
Completude e consistência Conformidade com os padrões Conflitos de requisitos Erros técnicos Requisitos ambíguos
Sommerville (Engenharia de Software, 2009) destaca que “o custo para consertar um problema de requisitos por meio de uma mudança no sistema é geralmente muito maior do que o custo para consertar erros de projetos ou codificação. A razão para isso é que a ocorrência de mudança dos requisitos normalmente significa que o projeto e a implementação do sistema devem ser alterados.” Daí então a característica crítica nessa atividade, e o destaque como sendo um dos mais importantes na engenharia de requisitos. Tendo em visto que um documento de requisitos bem definido permite aos envolvidos atuar de maneira consistente nas incoerências e inconformidades no desenvolvimento de um produto de software. Perceba que também o contexto da validação nos permite a identificação destas mesmas incoerências na fase anterior à versão final do relatório de requisitos, o que proporciona um nível de acerto maior, e minimiza consideravelmente uma detecção vindoura destas incoerências numa fase posterior, ou, pior ainda, até mesmo na finalização do sistema. Sommerville (Engenharia de Software, 2009) enfatiza ser possível afirmar que o processo de validação de requisitos está para o documento de requisitos assim como a fase de testes unitários e de sistema está para a fase de desenvolvimento de um projecto de software. É encontrado e provado pela literatura que detectar um erro em fases finalistas de um projeto, pode chegar a ser danoso a ponto de incompatibilizar a continuidade, visto que pode ser tão custosa que não existe recursos para comportá-la. Por isso, a atenção deve ser constante e minuciosa. São exemplos dos problemas que o processo de validação pode solucionar: Não conforme as normas de qualidade do projeto e da empresa. Descrição pouco clara dos requisitos. Ambiguidade entre requisitos. Falhas na modelagem dos requisitos. Conflitos entre requisitos. Requisitos não realistas. Ausência de informação. Na figura abaixo, segue uma síntese no tocante aos insumos e produtos gerados pela atividade da validação de requisitos. Fonte: http://www.cin.ufpe.br/~if119/aulas/cap4.PDF A partir da compreensão do que na figura acima está disposto, claramente conseguimos ter a percepção de um sistema da informação, contendo: entrada, processamento e saída. Com base nesse modelo, então define-se que o processo de validação de requisitos têm como entrada o arcabouço oriundo dos processo de: (a) análise e elicitação de requisitos; (b) das normas de qualidade da organização; (c) conhecimento empírico obtido contido na empresa, principalmente vindo de outros projetos ou de skateholders experientes no assunto. Na etapa de processamento temos a validação dos requisitos, que gera como saída uma lista de problemas que devem ser resolvidos e ações que são combinadas. Passaremos então a estudar sobre as técnicas existentes para o processo de validação.
Técnicas no Processo de Validação Revisão dos Requisitos É uma técnica, como o nome já sugere, a qual são analisados e revisados sistematicamente todos os requisitos elicitados, executando um checagem no tocante a erros e inconsistências. É uma boa prática para esta técnica uma reunião formal com representantes ou especialistas de todas as áreas, tanto do contratante como do contratado. Portanto, todas as equipes deverão ter representação. São recomendadas as seguintes providências: 1. Planejamento do que será revisado. 2. Estabelecer e convidar os envolvidos. 3. Definir local e tempo para a reunião. 4. Escolher para condução alguém “livre de vícios”, ou seja, que não estava integrado à equipe desenvolveu o documento de requisito. 5. Realizar procedimento de checklists para os requisitos e nas relações entre eles. 6. Distribuir previamente todos os documentos a serem utilizados na reunião. 7. Apresentar cada requisitos individualmente. 8. Discutir e anotar comentários para cada requisito que apresenta erro ou inconsistência. 9. Estabelecer um período de soluções após todo o término dos relatos apurados nas análises. 10. Apurar a qualidade final do documento de requisitos.
Se os requisitos fazem referência a outras facilidade, isso está descrito algures no documento?
Questões
Atributo de Qualidade
Questões atributo de qualidade
rastreabilidade, conformidade com normas
Os termos especializados aparecem no glossário
compreensibilidade
No tocante ao item 10, segue na tabela abaixo questões e respectivos atributos de qualidade que devem ser considerados na apuração (Fonte: http://pt.wikipedia.org/wiki/Valida %C3%A7%C3%A3o_de_requisitos):
O requisito depende de outros para se compreender o seu significado?
compreensibilidade, completude
Prototipagem
Há requisitos que usam omesmo termo com senti Ambigüidade dos diferentes?
Completude
Os requisitos relacionados estão agrupados? Se não como organização, rastreabilidade se referenciam mutuamente?
A fim de estabelecer uma demonstração mais didática sobre o projeto, desenvolve-se um protótipo para que os stakeholders possam compreender de maneira mais exata o funcionamento do sistema. “Nessa abordagem para avaliação, um modelo executável do sistema é demonstrado para os usuários finais e clientes.” (Sommerville, 2009). O objetivo é tornar mais fácil a fase de validação de requisitos, visto que, através da demonstração visual, tornar-se mais intuitivo detectar inconsistências e problemas nos requisitos. Experientes nessa técnica evidenciam algumas preocupações para sua adoção: 1. A qualidade do protótipo poderá levar a desilusões para os utilizadores finais, visto do ambiente projetado para os testes não ser aprazível aos usuários, principalmente no tocante as telas do sistema (as interfaces). 2. Mediante a anuência do que foi apresentado com teste, incentivar os programadores a uma baixa qualidade nas interfaces 3. O tempo gasto no desenvolvimento do protótipo em detrimento dos prazos estabelecidos para o projeto. Testes de Requisitos Uma propriedade importante para cada requisito é o de ser testável. Para cada requisito funcional deve ser possível definir um ou mais testes a serem realizados no sistema final para ser possível verificar se o sistema cumpre o requisito na integra. Caso tal propriedade não esteja presente, ou até mesmo se for muito difícil testá-lo; tal circunstância indica a necessidade de uma retificação. A realidade implica em uma probabilidade considerável para que todo o requisito que não pode ser testado muito provavelmente será instituidor de problemas. Deve-s então reconsiderar a presença deste, buscando por alternativas testáveis.
O mesmo serviço é solicitado em vários requisitos? Há contradições nestas solicitações?
consistência, redundância
Então quando da realização dos testes, deve-se tomar nota das características observadas quanto ao requisitos em si (identificador, requisitos relacionados), como aqueles relacionados aos testes (descrição, problemas, comentários, recomendações, etc.). Disciplina: REQUISITOS DE SISTEMAS Aula 09: GERENCIAMENTO DE REQUISITOS Apesar de toda preocupação no cumprimento das atividades referente a engenharia de requisitos, tem-se como verdade que uma incômoda realidade: não importa o quão cauteloso seja sobre a definição dos seus requisitos, sempre haverá mudanças. Mas não precisa então achar de tudo o que aprendemos deve ser desconsiderado, porque, sem ele, o prejuízo poderá ser muito maior. Sommerville (2011) destaca: Os requisitos para sistemas de software de grande porte estão sempre mudando. Uma razão para isso é que esses sistemas geralmente são desenvolvidos para enfrentar os problemas “maus” – problemas que não podem ser definidos. Porque os problemas não podem ser definidos, os requisitos de software são obrigados a ser incompletos. Durante o processo de software, o entendimento dos stakeholders a respeito do problema está em constante mutação. “Logo, os requisitos de sistema devem evoluir para refletir essas novas percepções do problema.” Conforme disposto na figura 1, o stakeholder, por exemplo, aponta uma determinada direção para a problemática e suas compreensões iniciais. A partir desse cenário são elicitados os requisitos que serão a Bse para a resolução. A medida em que o tempo vai passando, é normal um amadurecimento do que fora proposta e novas compreensões são visualizadas, fazendo com que os requisitos tenham que então suprir uma nova ou mais acertada concepção, portanto, alterando-os.
estabelecer um processo formal para fazer propostas de mudanças e a ligação destas às exigências do sistema. O processo formal de gerenciamento de requisitos deve começar assim que uma versão preliminar do documento de requisitos estiver disponível. No entanto, você deve começar a planejar como gerenciar mudanças de requisidtos durante o processo de elicitação de requisitos.” Sommerville (2011, pag. 76). Planejamento de gerenciamento de requisitos E toda alteração em um ambiente aonde os recursos utilizados são alterados, requer uma análise geral dos impactos a serem gerados pela alteração a ser aplicada. E justamente nesse escopo é que temos as maiores dificuldades. Portanto, o que torna complexo o gerenciamento dos requisitos variáveis não se trata especificamente na circunstância que um requisito mudado provocará mais ou menos tempo gasto na aplicação no sistema de um atributo novo, mas também que a mudança em um requisito propiciará impacto em outros requisitos, gerando uma cadeia de acontecimentos que devem ser avaliados.
Portanto, nosso passo inicial está em planejar e definir bem qual será o nível do detalhamento pretendido no gerenciamento de requisitos. São exemplos de atributos que devem ser avaliados:
Uma realidade muito comum também é uma vez que o sistema venha a ser implantado, sua utilização regular proporciona levantamento de novos requisitos. Humanamente é difícil que usuários e clientes do sistema consigam antecipar todos efeitos que o novo sistema terá sobre seus processos de negócio e sobre a forma que o trabalho é realizado. Quando os usuários finais tiverem experiência de um sistema, descobrirão novas necessidades e prioridades. São fusões entre empresas, mudanças no negócio, questões técnicas (utilização de software livre, por exemplo), novo hardware que deve ser introduzido, interoperabilidade, as prioridades do negócio podem mudar (com conseqüentes alterações necessárias no apoio do sistema), novas legislações e regulamentos os quais o sistema deve necessariamente respeitar, dentre outros.
2. Processo de gerenciamento de mudanças. Política que define conjunto de atividades cujo objetivo está em avaliar o impacto causado e o referenciar o(s) custo(s) inerente(s) a(s) mudança(s).
Então, é fato que no tocante a engenharia de software, é preciso ter a preocupação de compor uma estrutura de requisitos que tenha adaptabilidade a mudanças, além de usar vínculos de rastreabilidade que possam representar as dependências existentes entre os requisitos e outros artefatos do ciclo de vida do desenvolvimento. O gerenciamento de mudança inclui atividades como: 1. Estabelecer uma linha de base (baseline), aonde seja registrado aquele estado atual dos requisitos, principalmente se houverem mudanças. Costumamos dizer que é como tirar uma foto; ou seja, saberemos quais as características dos requisitos de acordo com alguma escala de tempo. 2. Determinar quais dependências são importantes de serem rastreadas, entendendo os requisitos mais importantes e suas ligações. 3. Estabelecer a rastreabilidade entre itens correlatos, trata-se de definir os “link” entre os requisitos, permitindo saber as ligações entre eles. 4. Controle de mudança. É necessário manter a informação do requisito original, ou seja, antes da mudança; o que foi mudado; as alterações estabelecidas e o requisitos alterado. “O gerenciamento de requisitos é o processo de compreensão e controle das mudanças nos requisitos do sistema. Você precisa se manter a par das necessidades individuais e manter as ligações entre as necessidades dependentes para conseguir avaliar o impacto das mudanças nos requisitos. Você precisa
1. Identificação de requisitos. Cada requisito deve possuir um identificador, ou melhor, pode ser definida uma política para compor cada identificação. Ela precisa ser única e mesmo que o requisito deixe de ser utilizado, deve mantê-la para fins de histórico.
3. Políticas de rastreabilidade. Definem os relacionamentos entre cada requisito e o projeto de sistema que deve ser registrado. A política de rastreabilidade também deve definir como esses registros serão mantidos. 4. Ferramenta de apoio. Não existe implicação direta em fazer o controle via formulários, contudo, gerenciar requisito abarca sempre grandes volumes de informações. É uma boa prática a utilização de ferramentas tecnológicas, que podem ser desde sistemas especializados em gerenciamento de requisitos até planilhas e sistemas de banco de dados simples. Sommervile (2011) é bem incisivo no tocante ao desenvolvimento da atividade de gerenciamento de requisitos. Ele afirma que “o gerenciamento de requisitos precisa de apoio automatizado, e as ferramentas de software para esse gerenciamento devem ser escolhidas durante a fase de planejamento.” Ele dispor de três necessidades macros para apoiar sua afirmação. São elas: 1. Armazenamento de requisitos. Os requisitos devem ser mantidos em um repositório de dados gerenciado e seguro, acessível a todos os envolvidos no processo de engenharia de requisitos. 2. Gerenciamento de mudanças. O processo de gerenciamento de mudanças (figura 2) é simplificado quando as ferramentas ativas de apoio estão disponíveis. 3. Gerenciamento de rastreabilidade. Como discutido anteriormente, as ferramentas de apoio para rastreabilidade permitem descobrir requisitos relacionados. Algumas ferramentas estão disponíveis, as quais usam técnicas de processamento de linguagem natural para ajudar a descobrir as possíveis relações entre os requisitos.”
cenário quase inevitável: a especificação de requisitos e a implementação do sistema fiquem defasadas. Confiar na mente humana e/ou no “bom senso” representa péssimo modelo de gerenciamento. Quase que na maioria das vezes as mudanças no sistema são feitas, e é esquecido de incluir, acrescentar, atualizar tais alterações no documento de requisitos. Contudo, é preciso contemplar o tamanho da empresa, porque tais ferramentas não podem ser mais caras do que o próprio sistema. Portanto, para sistemas de menor porte, outras alternativas podem (e devem) ser avaliadas, podendo não apenas ser necessárias ferramentas especializadas no gerenciamento de requisitos. Bancos de dados ou planilhas elaboradas em softwares comuns podem gerar um ótimo resultado, apoiando o processo de gerenciamento de requisitos. Gerenciamento de mudança de requisitos
Disciplina: REQUISITOS DE SISTEMAS Aula 10: CASOS DE USO Uma modelagem de um determinado sistema é um processo que consiste na representação de uma visão (ou perspectiva) do que se espera do sistema, no tocante ao seu funcionamento e resultado(s). É um consenso que ter uma representação visual de seu sistema antes que ele entre na etapa de implementação é de fundamental importância.
Existem três estágios principais em um processo de gerenciamento de mudanças (Sommerville, 2011): 1. Análise de problema e especificação de mudanças. Tudo começa com a identificação de um problema de requisitos. Uma segunda necessidade também pode ser com uma proposta específica de mudança. Nessa etapa, é realizada a análise do problema ou a proposta de mudança a fim de se verificar sua validade. Como boa prática, o resultado dessa análise é transmitido àquele que propôs mudança, a fim de definir: maiores detalhes ou retirar a solicitação. 2. Análise de mudança de requisitos. O efeito da mudança proposta é avaliado por meio de informações de rastreabilidade e conhecimentos gerais dos requisitos do sistema. O custo de ser fazer a mudança é estimado em termos de modificações no documento de requisito e, se apropriado, no projeto e implementação do sistema. Uma vez que essa análise é concluída, decide-se prosseguir ou não com a mudança de requisitos. 3. Implementação de mudanças. Deve ocorrer tanto no documento de requisitos e, se necessário, no projeto e, por último, na atualização do sistema, pelo resultado da implementação da modificação. Você deve organizar o documento de requisitos para poder fazer alterações sem ampla reformulação ou reorganização. Uma vez que houve a aprovação do documento de requisitos, o gerenciamento de mudanças de requisitos (figura 2) deve ser aplicado a todas as mudanças propostas aos requisitos de um sistema. A importância no gerenciamento de mudanças é fundamental, pois é necessário decidir se os benefícios da implementação de novos requisitos justificam os custos de implementação, ou seja, “os fins justificam os meios”. Sommerville (2011) destaca: “a vantagem de se usar um processo formal de gerenciamento de mudanças é que todas as propostas de mudanças são tratadas de forma consistente, e as alterações nos documentos de requisitos são feitas de forma controlada.” E quando da ocorrência de casos de urgência, há sempre a tentação de mudar o sistema e, em seguida, retrospectivamente modificar o documento de requisitos. Desnecessário afirmar que esse procedimento deve ser evitado, pois produz um
Desde meados da década de 80, o CASO DE USO estabelece uma metodologia que institui regras para a modelagem de sistemas. É como se fosse a planta baixa de uma residência. Antes que venhamos a construí-la, precisamos observar o desenho e demais informações, para evitarmos desagradáveis surpresas no o produto depois de terminado, ou seja, de nossa casa, por exemplo. Representados por diagramas, os Casos de Uso tem o objetivo de auxiliar a comunicação entre os analistas e o cliente. Ele então expõe uma espécie de cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. Enfim, o cliente deve ter acesso através do diagrama de Casos de Uso a identificação das principais funcionalidades de seu sistema. A partir dessa análise, conseguimos então perceber se estamos no caminho correto, portanto iremos atender os requisitos do sistema. Isso porque não estamos falando de uma conversa técnica (“bits e bytes”), mas com uma linguagem entendível por todos os integrantes da equipe, principalmente do solicitante, facilitando grandemente a comunicação. Podemos também citar sobre uma segunda característica dessa modelagem, é que ela independe do tipo de plataforma tecnológica; ou seja, qual a linguagem de programação, qual o banco de dados etc. Lembra-se que falamos sobre isso no início da disciplina. Pois então, o Caso de Uso é uma estratégia muito peculiar a engenharia de requisitos. Vamos agora aprender sobre sua estrutura.
Mediante o que sugere o diagrama, temos as seguintes ações do atores: O diagrama de Caso de Uso é compostos basicamente por 3 elementos. São eles: 1. Atores; 2. Casos de uso; 3. Relacionamentos entre estes elementos.
1. Ator “Cliente” poderá executar os casos de uso “realizar saque” e “consultar saldo”; 2. Ator “Gerente” poderá executar os casos de uso “abrir conta” e “vender seguro”. Relacionamentos entre casos de uso Mediante aspectos inerente a necessidade de fazer uso de casos de uso por outro caso de uso, estes podem se relacionar de duas formas:
1. Atores
1. include: Quando um caso de uso “A” inclui (include) outro Um ator é representado por um boneco e um rótulo com o nome do ator. Um ator identifica um usuário do sistema, seja ele humano ou outro sistema.
2. Caso de uso Um caso de uso é representado por uma elipse e um rótulo com o nome do caso de uso. Um caso de uso define uma grande função do sistema. A implicação é que uma função pode ser estruturada em outras funções e, portanto, um caso de uso pode ser estruturado.
caso de uso “B”. Isto implica que ao executar o caso de uso “A” executa-se também o caso de uso “B”.
Neste exemplo, o ator “Vendedor” pode executar o caso de uso “Processar Pedido”, e também o caso de uso “Emitir nota Fiscal”, visto que os casos de uso possuem relacionamento. Contudo, o ator não pode executar o caso de uso “Emitir nota Fiscal” sem executar “Processar Pedido”.
2. extends: Quando um caso de uso “A” tem um relacionamento do tipo extends com outro caso de uso “B”. Implica que ao executar o caso de uso “A” não necessariamente “B” será executado.
Vamos a exemplos: Representação do requisito “CADASTRAR CLIENTE”:
Lembre-se que usamos a figura de “ator” para representar quaisquer entidades que interagem com o sistema. Um ator representa um papel no sistema, mas um papel pode ser representando por vários atores.
Neste cenário, o vendedor pode fazer uso de quaisquer um dos casos de uso de maneira independente. Ele executa o caso de uso “Consultar Serasa” e/ou “Solicitar Entrega”. Portanto, a diferença é que no include existe uma dependência do uso do caso de uso, o que não acontece quando o relacionamento é extend.
Relacionamento entre Atores O ator pode herdar as funcionalidades (casos de uso) de outro ator.
Exemplo 2
Aqui temos os Atores “usuário” e “Cliente. Ao ator “usuário” está liberado o acesso ao caso de uso “Fazer Login”. No caso do ator “Cliente”, ele pode executar o caso de uso “Realizar saque”, bem como “Fazer Login”, visto que ele possui também o privilégio de executar todos os casos de uso disponíveis ao ator “usuário”. Neste exemplo, é importante verificar o sentido da seta, a qual indica que o sentido é do ator “Cliente” para o ator “usuário”. Representação do Sistema No tocante ao sistema como um todo, ou seja, a representatividade global do funcionamento é feito através de mais dois elementos: 1. Nome do sistema: Localizado dentro do retângulo. 2. Limites do sistema: representado por um retângulo envolvendo os casos de uso que compõem o sistema. Acompanhe os dois exemplos a seguir (visto do conhecimento já adquirido, descreva sua interpretação para cada cenário apresentado e remeta ao seu tutor):
Exemplo 1
Fonte das imagens (todas): http://celodemelo.wordpress.com/2007/03/17/entendedo-odiagrama-de-casos-de-uso/ A UML – Unified Modeling Language A UML surgiu a partir de um incentivo (inclusive financeiro) da Rational Software na união entre outras três metodologias de modelagem. Foram eles: (a) o método do americano Grady Booch; (b) o método OMT (Object Modeling Technique) do sueco Ivar Jacobson; e (c) o método OOSE (Object-Oriented Software Engineering) do americano James Rumbaugh. O esforço inicial do projeto começou com a união do método de Booch com o método OMT de Jacobson, o que resultou no lançamento do Método Unificado no final de 1995. Logo em seguida, Rumbaugh juntou-se a Booch e Jacobson na Rational Software e seu método OOSE começou a ser incorporado à nova metodologia. O trabalho de Booch, Jacobson e Rumbaugh conhecidos popularmente como "Os Três Amigos", resultou no lançamento, em 1996, da primeira versão da UML propriamente dita. Assim que a primeira versão foi lançada, diversas grandes empresas atuantes na área de software passaram a contribuir com o projeto, fornecendo sugestões para melhorar e ampliar a linguagem. Finalmente a UML foi adotada pela OMG (Object Management Group) em 1997, como a linguagem padrão de modelagem. Hoje, em 2007, a UML está na versão 2.0. Com uma modelagem, seu propósito é para permitir o entendimento e não para documentação. Ela então é parte do processo do desenvolvimento do sistema. Portanto, podemos utilizar os Casos de Usos para disseminação do conhecimento referente ao software a ser entregue. Além do Caso de Uso que estudamos anteriormente, os seguintes tipos de diagramas são suportados pelo Umbrello UML Modeller: • Diagrama de Classe mostra classes e os relacionamentos entre elas • Diagrama de Sequência mostra objetos e uma sequência das chamadas do método feitas para outros objetos.
• Diagrama de Colaboração mostra objetos e seus relacionamentos, colocando ênfase nos objetos que participam na troca de mensagens • Diagrama de Estado mostra estados, mudanças de estado e eventos num objeto ou uma parte do sistema • Diagrama de Atividade mostra atividades e as mudanças de uma atividade para outra com os eventos ocorridos em alguma parte do sistema • Diagrama de Componente mostra os componentes de programação de alto nível (como KParts ou Java Beans). • Diagrama de Distribuição mostra as instâncias dos componentes e seus relacionamentos. • Os Diagramas de Entidade-Associação mostram os dados e as relações e as restrições entre os dados. Vale uma consulta ao livro base dessa disciplina, e fazer uma verificação dos detalhes sobre cada um deles, bem como identificar suas diferenças, principalmente no tocante ao Caso de Uso - o qual foi detalhado em nossa aula de hoje! Bons estudos!
engenharia de requisitos (no contexto da engenharia de software) é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo. Este processo deve ser precedido de estudos de viabilidade que, a partir das restrições do projeto, determinam se este é ou não viável e se deve prosseguir para a identificação dos requisitos. O processo de engenharia de requisitos é composto por quatro atividades de alto nível (Soares, 2005): Identificação. Análise e negociação. Especificação e documentação. Validação. Uma outra atividade que se pode considerar que faz também parte deste processo, se incluirmos a fase posterior à produção do documento (isto é, a sua "manutenção"), é a gestão dos requisitos (change management, sendo que as alterações podem ser causadas pelos mais diversos fatores desde inovações tecnológicas a mudanças na natureza do negócio (e consequentemente nos requisitos), entre outras. Estudos de viabilidade Antes de se avançar com uma análise mais detalhada dos requisitos de um projeto, deve ser feito um estudo de viabilidade. Tal como o nome sugere, pretende-se com este estudo avaliar se, de um ponto de vista tecnológico e organizacional, se o projeto é viável. Uma forma de avaliar a viabilidade de um projeto é obter, através da interação com "as partes interessadas" (ou stakeholder em inglês) do projeto (em reuniões ou entrevistas, por exemplo), a resposta às seguintes questões: Será que o sistema contribui para os objetivos da organização? Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o sistema pode ser implementado? Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível?
A questão mais crítica é a primeira, já que um sistema que não contribua para os objetivos da organização não lhe traz qualquer valor acrescentado e como tal a sua existência não se justifica. Apesar de parecer óbvia, são frequentemente desenvolvidos sistemas que não contribuem para os objetivos das respectivas organizações, quer seja por interesses externos (políticos ou organizacionais) ou por falta de clareza na definição dos objetivos da organização. Deve portanto identificar-se que informação é necessária para responder a estas questões e quem possui esta informação, procedendo-se de seguida à recolha de todos os dados disponíveis para clarificar ao máximo o âmbito do projeto e avaliar a sua viabilidade. Tipicamente, quem poderá fornecer esta informação serão os utilizadores dos sistemas atuais e do sistema a implementar, os responsáveis pelos departamentos nos quais o sistema será usado, técnicos que estejam familiarizados com as tecnologias envolvidas (do novo sistema e dos sistemas existentes), responsáveis pela manutenção futura do sistema a implementar e, de um modo geral, todos aqueles que terão qualquer tipo de interação com o novo sistema (ou que sejam por ele afetados). Algumas das questões que podem ser postas nesta coleta de informações são, por exemplo: Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização? Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas falhas? De que forma é que o sistema irá contribuir diretamente para os objetivos da organização? É possível a integração com os outros sistemas da organização (de um ponto de vista tecnológico)? Com que facilidade é que se consegue partilhar informação entre estes sistemas? O estudo de viabilidade deverá culminar com a produção de um relatório e deverá determinar a continuação do desenvolvimento do projeto, tornando mais claras as restrições (econômicas, temporais e organizacionais) do projeto e definindo mesmo alguns requisitos de alto nível. Identificação Caso se determine que o projeto é viável, o passo seguinte é a identificação dos requisitos. Atividades envolvidas Algumas das atividades envolvidas nesta fase incluem: Compreensão do domínio: é muito importante para o analista compreender o domínio no qual a organização e o projeto se inserem; quanto maior for o conhecimento acerca do domínio, mais eficaz será a comunicação entre o analista e as partes interessadas. Identificação das partes interessadas: estes já deverão ter sido identificados nos estudos de viabilidade, porém para efeitos de identificação de requisitos convém concentrar as atenções nos utilizadores do sistema. Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não-funcionais) pretendidos para o sistema. Identificação e análise de problemas: os problemas devem ser identificados (e a sua definição deve ser consensual) e devem ser propostas soluções em conjunto com as partes interessadas. Dificuldades Esta fase não é trivial, sendo que existem algumas dificuldades típicas que lhe estão associadas:
O cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo mas não conseguir articulá-lo (o que é bastante comum). Os requisitos identificados podem não ser realistas (do ponto de vista econômico ou tecnológico, por exemplo). Cada parte interessada pode expressar os mesmos requisitos de formas diferentes, sendo necessário - através de um bom conhecimento do domínio - identificar estas situações. Técnicas para levantamento de requisitos Existem diversas técnicas de identificação de requisitos, e que são adequadas a diferentes situações, entre as quais podemos citar: Entrevistas e Questionários Entrevistas e Questionários é talvez a técnica mais simples de utilizar. Ainda que seja bastante eficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de algumas dúvidas), está condicionada a alguns fatores: Influência do entrevistador nas respostas do cliente: 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. 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). Workshops de requisitos O 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[1], para então obter um conjunto de requisitos bem definidos. Ao contrário das reuniões, promove-se a interação entre todos os elementos presentes no workshop fomentando momentos de descontraçã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 idéias) 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 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. 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. Prototipagem O uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos (por exemplo na identificação, análise e validação). Trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis. Neste tipo de abordagem apenas são desenvolvidas algumas funcionalidades sendo normalmente desenvolvidas primeiro aquelas que são mais fáceis de compreender por parte do utilizador e que lhe podem trazer maior valor acrescentado (principalmente na prototipificação evolutiva, isto é, aquela que mais tarde é evoluída para a fase de desenvolvimento). O uso de protótipos deve ser considerado apenas mediante uma análise custo-benefí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. Estudo etnográfico Os Estudos Etnográficos são uma análise de componente social das tarefas desempenhadas numa dada organização. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de se esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo. Através de uma observação direta das atividades realizadas durante um período de trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais. Esta observação pode ser acompanhada de registros áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para os processar pode ser demasiado. Nesta técnica assume-se que o representante do cliente observado desempenha as suas funções "corretamente", pelo que convém ter algum cuidado na escolha do mesmo. Análise e negociação dos requisitos Após a identificação dos requisitos do sistema, segue-se à etapa de análise dos requisitos e negociação. Atividades envolvidas Algumas das atividades envolvidas na análise de requisitos incluem: Classificação: agrupamento de requisitos em "módulos" para facilitar a visão global do funcionamento pretendido para o sistema. Resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura e análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é importante resolver estes conflitos o mais breve possível. Priorização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa); obviamente, este pode ser um fator gerador de conflitos. Confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade (de acordo com o que se pretende do sistema).
Estas fases não são independentes entre si, pois uma informação obtida numa delas pode servir para as demais fases. A identificação e análise de requisitos é um processo iterativo que se inicia com a familiarização do domínio do futuro sistema e termina na confirmação dos requisitos, aumentando o grau de compreendimento do sistema a cada ciclo de trabalho. Dificuldades As dificuldades encontradas na análise são de diversas naturezas: Fatores externos (políticos) podem influenciar os requisitos (alguma parte interessada, com poder de decisão, pode exigir requisitos específicos que sirvam aos seus interesses e não aos da organização, ou forçar o seu ponto de vista em detrimento dos demais interessados que irão operar o sistema). O ambiente (econômico e/ou organizacional) em que a análise é feita possui fatores dinâmicos, e como tal, os requisitos estão sujeitos a alterações em decorrência destes (por exemplo: novas partes interessadas são envolvidas no projeto, ou alterações em prazos e orçamentos disponíveis). Negociações Na fase de negociação, tornam-se necessários alguns cuidados para que esta decorra sem problemas, chegando-se logo a consensos. Algumas sugestões são: Saber lidar com ataques pessoais (evitando-os sempre que possível, remetendo a sua resolução para mais tarde, fora de reunião), de preferência nunca tomando partidos. Fomentar a justificação das posições (negativas) tomadas pelos intervenientes na negociação. Salientar (e procurar encontrar) os benefícios que uma solução apresenta para todos os envolvidos. Relaxar restrições, quando se torna óbvio que as atuais não levarão a um consenso. Especificação e documentação É nesta fase que se dá a produção propriamente dita do documento de especificação de requisitos. Em todos os tipos de especificação há 2 tipos de requisitos a considerar: Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido. Requisitos não-funcionais: referem-se a aspectos nãofuncionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança, Desempenho, Suporte e Escalabilidade. Pode-se também considerar os requisitos do domínio, que tal como o nome indica derivam do domínio e não de necessidades específicas dos utilizadores, podendo depois ser classificados como funcionais ou não-funcionais. A documentação produzida poderá ter diferentes destinatários e como tal diferentes objetivos. Podem-se distinguir três tipos de especificação: Especificação de requisitos do utilizador. Especificação de requisitos do sistema. Especificação do design da aplicação. A vantagem de conceber mais do que uma especificação para um dado sistema é a de em cada especificação se comunicar apenas um determinado tipo de informação adequado ao leitor a que se destina (usando "linguagens" que o utilizador conheça). Por exemplo, enquanto que nos requisitos do utilizador apenas é feita uma abordagem de alto nível das
funcionalidades do sistema e suas restrições, usando linguagem natural e eventualmente diagramas (esquemas), nos requisitos do sistema cada requisito é descrito com mais detalhe introduzindo já alguns conceitos relativos à arquitetura do sistema, fazendo-se uso de linguagens estruturadas (notações gráficos como diagramas de casos de uso). Requisitos do utilizador Os requisitos do utilizador destinam-se portanto aos vários níveis hierárquicos da organização na qual o sistema será implementado (desde gestores a utilizadores), pelo que são descritos usando apenas (conforme já foi referido) linguagem natural, formulários e diagramas muito simples. Obviamente, neste nível de especificação surgem algumas dificuldades: Ambiguidade: torna-se difícil descrever os requisitos de uma forma inequívoca sem tornar a sua descrição muito longa ou de difícil compreensão. Confusão: ainda que possa não ser tão relevante do ponto de vista do cliente, a distinção entre requisitos funcionais/nãofuncionais e objetivos do sistema torna-se difícil. Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode tornar-se difícil separar claramente os requisitos, o que leva a que vários requisitos sejam expressos como sendo apenas um. Algumas considerações úteis a ter em conta ao escrever uma especificação de requisitos do utilizador: Usar o mesmo formato em todos os requisitos (evitam-se omissões e facilita-se a verificação dos requisitos). Distinguir claramente entre comportamentos esperados e desejáveis do sistema através do uso de expressões como "O sistema permitirá criar (...)" ou "Deverá ser possível criar (...)" respectivamente. É importante deixar claro o que o sistema tem de fazer e sugestões de como o deve fazer e, acima de tudo, usar este tipo de expressões de forma consistente ao longo de todo o documento. Usar formatação de texto para salientar determinados aspectos do documento (usando negrito, por exemplo). Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, identificando-os e definindo-os de uma forma clara quando for absolutamente necessário usá-los. Requisitos do sistema Os requisitos do sistema têm um carácter mais técnico, consistindo numa descrição detalhada dos requisitos do utilizador correspondentes recorrendo ao uso, para além da linguagem natural, de linguagens estruturadas e notações gráficas. Estes requisitos destinam-se ainda aos utilizadores do sistema (e particularmente aos engenheiros que trabalhem nessa organização) e destinam-se também às equipes de especificação de arquitetura do sistema e de desenvolvimento. Tal como nos requisitos do utilizador, o uso de linguagem natural levanta problemas, embora alguns deles sejam ligeiramente diferentes: As mesmas palavras podem, de acordo com a interpretação de cada pessoa, designar conceitos diferentes. O mesmo requisito pode ser descrito de formas diferentes, o que leva a que cada pessoa tenha de saber quando é que descrições diferentes se referem ou não a requisitos diferentes. Design da aplicação Por fim, a especificação do design da aplicação consiste num documento usado pela equipe de desenvolvimento do sistema no qual estão definidos pormenores, em um nível mais técnico, acerca da implementação do sistema e sua arquitetura. A partir deste documento, um elemento que entre para a equipe de desenvolvimento no meio do projeto deverá ser capaz de "se situar" quando precisar de começar a codificar, compreendendo a forma como a implementação, em um nível global, está a ser
feita, mas sem conhecer necessariamente os detalhes de implementação aprofundados. Não convém cair na tentação de deixar toda a implementação detalhada, uma vez que convém que os desenvolvedores tenham alguma margem de manobra tanto para inovar como para resolver problemas encontrados em sub-sistemas de formas que uma especificação inicial da arquitetura não consegue prever. Documento de Especificação de Requisitos Apesar da existência dos 3 tipos de especificação vistos nos itens anteriores, 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 utilizador e do sistema e tem diferentes utilidades para diferentes pessoas (Kotonya e Sommerville, 1998): 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 IEEEque é talvez a mais usada é o IEEE/ANSI 830-1993 (Thayer e Dorfman, 1993). Validação Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende. À semelhança do que sucede na análise dos requisitos, pretende-se encontrar problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida com uma especificação completa dos requisitos. A validação é especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitos têm repercussões proporcionais à dimensão do projeto. Uma vez que alterações em requisitos já consolidados têm um custo muito superior a alterações no código ou design, este tipo de erros traduz-se em elevados custos e necessidade de refazer muito do trabalho que se julgava já concluído. Durante a fase de validação dos requisitos, devem ser verificados (através de checklists) os seguintes atributos dos requisitos: Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas. Como tal, requisitos identificados individualmente (isto é, junto de cada parte interessada) podem diferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada cliente compreenda e aceite a especificação final obtida. Consistência: não devem existir conflitos entre os requisitos identificados. Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas. Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema.
Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável. Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos requisitos especificados, estes devem ser descritos de modo a que seja possível verificar se foram ou não concretizados, isto é, se o sistema final corresponde à especificação inicial. Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos. Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua especificação deve obedecer às normas usadas ao longo de todo o documento. Técnicas de validação Para tornar a validação mais eficaz, existe um conjunto de técnicas que podem ser empregues: Revisões dos requisitos Uma equipe de revisores pode analisar sistematicamente a especificação produzida de forma a garantir que esta corresponde ao sistema pretendido; em revisões informais, a equipe de revisores pode simplesmente ter uma conversa, envolvendo o maior número possível de representantes das partes interessadas, acerca dos requisitos produzidos; em revisões formais, a equipe de revisores deve confirmar junto do cliente um conjunto de critérios que todos os requisitos devem cumprir, nomeadamente: verificabilidade, compreensibilidade (por parte dos utilizadores finais), rastreabilidade (a origem dos requisitos deve ser identificável) e adaptabilidade (capacidade de sofrer alterações sem produzir efeitos em todos os outros requisitos). Prototipificação (Ou prototipação) A implementação de um protótipo (por exemplo, da interface do sistema) pode ser útil para os utilizadores finais (e demais interessados), já que se trata do elemento do sistema final com o qual terão mais contacto quando o sistema estiver operacional; esta técnica também é eficaz, embora tenha desvantagens: o tempo gasto na sua implementação pode não justificar o seu uso, pode enviesar os utilizadores (levando a desilusões com a versão final do sistema, no caso de esta ser muito diferente do protótipo) e pode ainda levar os programadores a cair na tentação de usar o protótipo para continuar o desenvolvimento do sistema (pelo que, idealmente, o protótipo deva ser implementado noutra linguagem que não aquela usada pelo sistema, eliminando por completo esta tentação). Geração de casos de teste Uma vez que cada requisito deve ser testável, deveria ser possível criar (desenhar) os respectivos testes desde a fase de validação de requisitos; se isto não for possível, é sinónimo de que a implementação deste requisito será difícil e que este poderá ter de ser reconsiderado. Análise de consistência automática Através da especificação formal de modelos para o sistema é possível, recorrendo a ferramentas adequadas (como as ferramentas CASE), testar de forma automática a consistência dos modelos criados; apenas a consistência é testada nesta técnica, pelo que tem de ser complementada com uma das outras técnicas referidas. Recomendações A fase de validação não deve ser encarada de ânimo leve: tratase de uma fase muito importante na engenharia de requisitos e da qual dependem elevados custos a médio e longo prazo.
Por depender bastante dos retornos transmitidos pelos clientes (que não são peritos em validação de requisitos) é bastante falível e regra geral há erros que não são encontrados num primeiro momento, o que leva inevitavelmente a discordâncias numa fase posterior, já com o documento validado e o projeto em desenvolvimento ou concluído. Quando isto sucede, tornase necessário negociar e chegar a um acordo quanto à forma de corrigir o erro detectado. Gestão de requisitos Os requisitos de um sistema, em especial em sistemas minimamente grandes, estão em evolução constante. De um modo geral, isto pode suceder em razão do problema abordado não conseguir ficar completamente definido antes da produção do documento de requisitos (ou mesmo antes de o sistema ser implementado) ou, por outro lado, pode também acontecer por os próprios requisitos se alterarem no decorrer do projeto (reflectindo evoluções tecnológicas ou alterações na organização na qual é usado). É natural que surjam requisitos por parte dos utilizadores por diversos motivos: Conforme já foi referido, a resolução de conflitos entre requisitos resulta num compromisso que procura equilibrar as necessidades das diferentes partes interessadas. Este equilíbrio pode ter de ser modificado e só com o uso do sistema é que é possível avaliá-lo convenientemente. Para além de conflitos entre requisitos de diferentes utilizadores do sistema, há ainda a considerar os conflitos entre utilizadores e "elementos executivos" da organização, isto é, aqueles que têm o poder de decisão e que podem impôr requisitos perante os analistas (que podem não contribuir para os objetivos da organização). A orientação do negócio da organização pode-se alterar, nova legislação ou regulamentação pode pôr em causa alguns dos requisitos do sistema, alterações a nível tecnológico podem surgir na organização (afetando particularmente, no caso de alterações de hardware, os requisitos não-funcionais), podem surgir novos sistemas que precisem de suporte, a nível de interação, por parte do sistema implementado, e toda uma série de alterações imprevisíveis pode surgir levando a que o sistema tenha de se adaptar a todo este tipo de requisitos. Existem requisitos que, tipicamente, são mais voláteis do que outros (como por exemplo requisitos que dependam da entidade política governante num dado momento), enquanto que outros são relativamente estáveis (os que se referem à natureza do negócio (domínio) propriamente dita). Na prática, a gestão de requisitos acaba por coincidir com o início de novos processos de engenharia de requisitos (para os "novos" requisitos, isto é, os "antigos" que sofreram alterações). Como tal, o planejamento é uma parte importante da gestão de requisitos. Devem estar definidas desde o início da gestão de requisitos políticas para: Identificação de requisitos: identificação unívoca em especial para facilitar a rastreabilidade. Processo de gestão de mudanças a utilizar: conjunto de atividades que permitem avaliar o custo e impacto das alterações. Rastreabilidade: relações entre os requisitos e relações entre requisitos e design; estas podem precisar de manter associada a cada requisito informação como a parte interessada que a propôs, dependências de outros requisitos e associação a módulos específicos do design do sistema. Ferramentas a utilizar: para sistemas grandes, a quantidade de informação a processar pode ser elevada, sendo o uso de ferramentas CASE aconselhado.
Para manter a consistência entre as várias alterações pedidas (e para estas serem feitas de um modo controlado), é importante que o processo de gestão de mudanças esteja definido de um modo formal, sendo que deverá incluir as seguintes três fases: Análise do problema e especificação da alteração a fazer: identificação do problema existente nos requisitos originais e proposta de alteração a fazer aos requisitos do sistema. Análise da alteração e seu impacto: através das políticas de rastreabilidade definidas previamente, avaliação do impacto da alteração no sistema. Implementação da alteração: alteração no documento de requisitos e, conforme seja necessário, no design e implementação. É importante seguir este processo conforme foi enunciado já que cair na tentação de implementar a alteração directamente e só depois, retrospectivamente, actualizar os requisitos pode levar a dessincronização entre requisitos e implementação. Notas
1. ↑ este grupo deve ser escolhido levando-se em conta a organização e o contexto em que o sistema será usado Referências Kotonya e Sommerville (1998). Requirements Engineering: Processes and Techniques. Gerald Kotonya, Ian Sommerville. Wiley. 1998. Sommerville (2001). Software Engineering. Ian Sommerville. Addison Wesley. 2001. Thayer e Dorfman (1993). Software Requirements Engineering. R. H. Thayer, M. Dorfman. IEEE Computer Society Press. 1993. Soares (2005). Introdução, Identificação e Análise em Engenharia de Requisitos. António Lucas Soares. 2005. Ferramentas Projeto SER::Sistema de Engenharia de Requisitos Controlle - Gerência e Desenvolvimento de Requisitos Abordagem Na imensa " selva " que se tornou a área de Tecnologia da Informação com o predomínio das novas tecnologias induzindo as empresas a um consumismo imediatista " das novidades ", a capacidade de pensar do analista de sistemas parece estar sendo colocada em segundo plano. A tendência de tornar as coisas mais fáceis, mais práticas, mais produtivas e mais amigáveis, acaba pressionando um processo nem sempre consistente de transformação do modelo convencional de análise para um modelo de desenvolvimento baseado em ferramentas automatizadas. O livro procura abordar esse tema de uma forma crítica, porém simples e com um leve toque de humor para tornar a leitura menos árida e mais descontraída. Versa sobre a pretensão de que softwares, tecnologicamente sofisticados, possam substituir a imprescindível contribuição intelectual do analista de sistemas na elaboração de um projeto. Ao mesmo tempo em que sugere uma visão crítica da utilização da metodologia na empresa, isenta de interesses comerciais, procura passar ao leitor os aspectos fundamentais que determinam a eficácia de uma metodologia de desenvolvimento de sistemas. Ao colocar em primeiro plano interesses comerciais, fornecedores de hardware e software contribuem para uma excessiva volatilidade das soluções de tecnologia, muitas vezes inconsistentes entre si. Este livro nos convida a refletir, com senso crítico, sobre a influência da Indústria da Informação na Metodologia de Desenvolvimento de Sistemas, ao desmistificar o principal argumento dos " vendedores de solução ": " o atraso dos projetos de software. "
A indústria da informação, baseada no conhecido argumento do? atraso nos prazos do projeto?, fatura bilhões de dólares por ano, produzindo equipamentos e softwares, levando às empresas a um permanente estado de adaptação de seus processos de desenvolvimento; enquanto que as empresas, empurradas para a necessidade de uma constante adaptação e atualização as novas plataformas e aos novos padrões de mercado, não conseguem atingir um estágio ideal de amadurecimento em seus processos de construção de software. Longe de resolver os problemas propostos, tais soluções contribuem para o surgimento de novos problemas, com a introdução da? novidade?; até que o novo processo torne-se suficientemente maduro, surgem novas falhas no desenvolvimento dos sistemas, e, paradoxalmente:? novos atrasos em projetos?. O risco, para empresas e profissionais de sistemas, é que os softwares de hoje, estarão obsoletos amanhã, e esse movimento vai se tornar cada vez mais rápido e a idade de obsolescência dos profissionais vai reduzir cada vez mais, aumentando a dependência das empresas por novas tecnologias, aumentando a dependência dos profissionais de novas certificações em ferramentas e softwares especializados e perpetuando o mercado dos vendedores de solução. Especificação de Requisitos O objetivo da Especificação Preliminar ou Anteprojeto é transmitir uma idéia global e genérica do projeto a ser desenvolvido segundo a visão dos usuários. É elaborado para compreender a real necessidade dos usuários e suas expectativas, dimensionar a sua abrangência e delimitar o seu escopo. A principal característica do Anteprojeto é a sua natureza de estudo de viabilidade, de algo desejado, mas que ainda não foi devidamente analisado, permitindo dessa forma explorar alternativas para verificação de sua eficácia como solução. É fundamental o estabelecimento das Premissas Básicas que nortearão o desenvolvimento do sistema, atendo-se ao que o sistema? deve? fazer para cumprir a sua finalidade. Compreende aspectos como: • Levantamento Inicial? Onde se busca encontrar, embora em termos genéricos, o máximo de informações relacionadas à área do Negócio, que sejam relevantes aos objetivos do projeto ou que possam impactar o seu desenvolvimento. • Estudo Preliminar? Identificação de todas as áreas envolvidas na solução e os grandes módulos de processamento, bem como o seu inter-relacionamento, sendo desejável a elaboração de um desenho macro onde o usuário possa identificar cada componente da solução pretendida. Nessa especificação não deverá haver a preocupação com a solução técnica que será adotada, poderá, no entanto, descrever as opções já verificadas ou desejadas pelos usuários no que se refere à tecnologia pretendida. A solução tecnológica propriamente dita será objeto da fase de Projeto. Como todo relatório deverá zelar pela clareza e objetividade das informações, seus dados devem ser precisos e suas estimativas e projeções deverão ser realistas, sem exageros ou omissões, dando base a conclusões sobre Custos e Benefícios com a implantação do sistema. A apresentação deverá ser organizada em tópicos coerentes favorecendo a compreensão e a seqüência do raciocínio. Resumindo, trata-se de uma peça importante e que merece total cuidado na preparação, pois além de possibilitar que seja dado aprovação ao prosseguimento do projeto, a apresentação criará expectativas nos futuros usuários e servirá de base ao detalhamento das fases seguintes do desenvolvimento. Uma verificação dos documentos obrigatórios da nossa metodologia
vai permitir encontrar alguns itens que poderão ou deverão compor o relatório de Especificação de Projetos, de modo genérico, lembrando que quanto mais precisa for a especificação original, maior será a chance de sucesso na implementação. Requisitos do Sistema: Mas afinal o que são requisitos? Requisito pode ser descrito como: Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo; Condição necessária para a obtenção de certo objetivo, ou para o preenchimento de certo fim; Uma condição ou capacidade que deve ser suprida por um sistema para satisfazer um contrato ou um padrão; Enfim, tudo o que o sistema deve fazer para implementar uma necessidade de automação requerida pela solução. Na prática, requisito é o que o sistema tem que ter para atender plenamente ao propósito para o qual foi criado. Para garantir a aderência aos requisitos é fundamental que a Metodologia implemente e gerencie eficazmente o documento: Especificação dos Requisitos de Software, que tem como objetivos: • Descrever cuidadosamente, quais os requisitos do sistema e como o sistema deverá implementar tais requisitos. • Descrever objetivamente, como essa implementação poderá ser testada e verificada pelo usuário. Os requisitos podem ser classificados em: • Requisitos Funcionais? Funcionalidade a ser implementada no software para atender a uma necessidade de automação. • Requisitos Operacionais? Especificação de características relacionadas com o processamento do software, tais como: volume, freqüência, disponibilidade, performance, localização física etc. • Requisitos de Contingência? Tarefas alternativas para o caso de não funcionamento ou indisponibilidade eventual do software. • Requisitos Técnicos? Premissas e restrições quanto à arquitetura tecnológica, aos padrões, à comunicação, às ferramentas, às linguagens etc. Exemplo: Projeto: ABC • Objetivo do Projeto; • Público Alvo; • Políticas Internas; • Premissas Básicas que regem o negócio; • Definição do Produto; • Condições de operacionalização; • Aspectos envolvendo processamento e comunicação com o Cliente; • Fatores que deram origem ao projeto; • Limitações ou Restrições Operacionais; • Benefícios Esperados pelos Usuários com a implantação do Sistema; • Principais necessidades que deverão ser atendidas pelo projeto; • Alternativas de Solução; • Necessidade de Integração com Sistemas Corporativos; • Padrões de Qualidade e Performance a serem obtidos; • Atribuição de Responsabilidades; • Fatores de Risco; • Aspectos Contábeis e Financeiros; • Aspectos Legais e Jurídicos; • Gerenciamento das Informações do Sistema. Além desses requisitos que definem objetivos e funcionalidades do sistema, devemos lembrar que qualquer sistema deve estar aderente às políticas da organização em relação à qualidade e segurança das informações; deve rodar
em um ambiente produtivo em que rodam os outros sistemas da empresa, portanto deve estar em compatibilidade com todas as características operacionais desse ambiente sem impactar ou causar distúrbios nesses processamentos; deve estar em conformidade com os padrões de mercado em termos de tempo de resposta, desempenho e performance em máquina, minimizando a utilização dos recursos computacionais. A indústria de software vem demonstrando crescente interesse em engenharia de requisitos, isto é, entender o que se deseja construir antes de começar a fazê-lo. Felizmente já há uma percepção de que o tempo utilizado no entendimento do problema é um excelente investimento. Os requisitos de software são a base a partir da qual a qualidade é medida. Desta forma, a falta de conformidade aos requisitos significa falta de qualidade. O modelo de avaliação de maturidade do processo de desenvolvimento CMM (Capability Maturity Model) considera o gerenciamento de requisitos como sendo uma das primeiras etapas para alcançar a maturidade organizacional, e para haver o gerenciamento é preciso que o processo de desenvolvimento de requisitos esteja implantado na empresa. Desta forma, para se alcançar a gerência de requisitos é necessário que os requisitos tenham sido definidos, e é importante que a empresa também possua seus processos de desenvolvimento de requisitos definidos. A cada dia, as empresas tornam-se mais dependentes dos seus sistemas de informações. Construir esses sistemas, em tempo hábil para serem úteis aos negócios, com a qualidade e custos adequados à sua importância para a organização, é o desafio que todos os desenvolvedores estão enfrentando. Pressman define qualidade de software como? conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido?. Requisitos Não-Funcionais A Norma ISO / IEC 9126 define seis características de qualidade de software que devem ser avaliadas: • Funcionalidade (finalidade do produto); • Usabilidade (esforço para utilizar, aprender o produto); • Confiabilidade (freqüência de falhas, recuperabilidade); • Eficiência (característica relacionada ao desempenho); • Manutenibilidade (esforço necessário para modificar); • Portabilidade (capacidade de transferir o produto para outros ambientes). Pressman define Requisitos Não-Funcionais como: Fatores de qualidade de software que podem ser medidos de forma indireta?, ou como:? Características implícitas que são esperadas de todo software profissionalmente desenvolvido?. • Reusabilidade (Capacidade de reutilização de módulos do sistema em outras aplicações). Este requisito está relacionado a outros fatores tais como: o Modularidade: independência funcional dos componentes; o Generalidade: amplitude do potencial de aplicação; o Encapsulação; o Abstração; • Portabilidade (Esforço exigido para transferir um sistema de um ambiente de hardware e / ou software para outro). Fator diretamente relacionado a reusabilidade e às linguagens de programação e ferramentas utilizadas; • Manutenibilidade (Esforço exigido para localizar e reparar erros em um sistema ou para modificá-lo com o propósito de
adaptá-lo a um novo ambiente, a novas funcionalidades ou a outras metas de qualidade). Este requisito está relacionado a outros fatores, tais como: o Boa documentação; o Legibilidade; o Reusabilidade; o Portabilidade • Multimodalidade (Uso de diferentes mecanismos para representação ou apresentação da informação e para a interação com o usuário). Este requisito está relacionado ao uso de diversos canais de comunicação: o Visual; o Tátil; o Auditiva; o Motora. • Eficiência e Desempenho (Eficiência: quantidade de recursos de computação e de código exigida para que o programa execute a sua função - Desempenho: é medido avaliando-se a velocidade de processamento, o tempo de resposta, o consumo de recursos) Outros requisitos ou outras definições para o mesmo tipo de requisito ainda podem ser encontrados em diversas literaturas sobre o assunto: • Usabilidade (Refere-se ao grau de facilidade oferecido para que um usuário aprenda a operar, fornecer entradas e interpretar saídas de um componente ou sistema). A usabilidade de um sistema é um conceito que se refere à qualidade da interação de sistemas com os usuários e depende de vários aspectos. Alguns destes fatores são: o Facilidade de aprendizado do sistema: Tempo e esforço necessários para que os usuários atinjam um determinado nível de desempenho; o Facilidade de uso: Avalia o esforço físico e cognitivo do usuário durante o processo de interação, medindo a velocidade de uso e o número de erros cometidos durante a execução de uma determinada tarefa; Pressupõe a existência de Help, manuais de usuário e boa documentação; o Satisfação do usuário: Avalia se o usuário gosta e sente prazer em trabalhar com este sistema; o Flexibilidade e Nível de Parametrização: Avalia a possibilidade de o usuário acrescentar e modificar as funções e o ambiente iniciais do sistema. Assim, este fator mede também a capacidade do usuário utilizar o sistema de maneira inteligente e criativa, realizando novas tarefas que não estavam previstas pelos desenvolvedores; o Produtividade: Avalia se o uso do sistema permite ao usuário ser mais produtivo do que seria se não o utilizasse; o Consistência de interface; o Cuidado com a navegabilidade; o Tolerância a erros. • Rastreabilidade (Capacidade de manutenção de histórico das ações dos usuários tais como: número de acessos ao sistema e material consultado ou do comportamento do sistema); • Extensibilidade (Capacidade de ampliar o sistema, pela incorporação de novas funcionalidades, pelo aumento da capacidade de armazenamento etc, e a Medida do esforço necessária para isso). • Escalabilidade (Capacidade de um componente ou de um software manter o mesmo desempenho (tempo de resposta) quando há um aumento no número de usuários e / ou de requisições simultâneas). Este requisito está relacionado aos fatores: o Pool de conexões;
o Cuidado com operações de I / O. • Configurabilidade (Capacidade de organizar e controlar elementos da configuração do sistema ou Capacidade de gerar diferentes configurações ou visões do sistema). Este requisito está relacionado a outros fatores tais como: o Habilitação ou omissão de conteúdos e serviços; o Parametrização; o Personalização e customização do sistema ou componente de acordo com o contexto ou com o perfil de usuário. • Variabilidade (Está associada à variação de componentes de uma arquitetura). Pode haver variações: o De funcionalidade; o De dados; o De fluxo de controle; o De tecnologia; o De ambiente; o De metas de qualidade. • Segurança (Premissas e Restrições para o controle e segurança do software além da disponibilidade de mecanismos que controlam ou projetam programas e dados). Este requisito está relacionado aos fatores como: necessidade de criptografia, autenticação de usuários etc. o Controle de acesso e manipulação de recursos; o Autenticação; o Autorização / permissão; o Integridade dos dados e confiabilidade; o Privacidade e confidencialidade. • Tolerância à Falha (Capacidade do sistema de manter o seu funcionamento normal dada a ocorrência de uma falha de hardware ou software). Este requisito está relacionado aos fatores: o Disponibilidade; o Confiabilidade; o Freqüência e gravidade das falhas; o Acurácia dos resultados; o Capacidade de recuperação; o Redundância. Entre outros como: • Interoperabilidade; • Testabilidade; • Correção; • Consistência; • Compatibilidade; • Complexidade; • Internacionalização (capacidade do sistema para suportar diferentes línguas (Português, Inglês, Espanhol etc.) sem a necessidade de recodificação) Conhecer e dominar uma linguagem de programação é bom mas não é tudo. Para criar sistemas robustos e que com qualidade é preciso mais do que uma boa linguagem e um bom programador. A princípio todo o sistema tem um objetivo e uma necessidade de criação. Não se cria um sistema que não tem utilidade e que ninguém vai usar , não é mesmo. Assim, um sistema deve ser criado para atender as expectativas de um cliente. A análise e especificação de requisitos de software envolve as atividades de determinar os objetivos de um sistema de software e as restrições associadas a ele. Ela deve também estabelecer o relacionamento entre estes objetivos e restrições e a especificação precisa do software
A maior parte dos problemas no desenvolvimento de software são originados nas etapas iniciais do desenvolvimento justamente na etapa de levantamento e definição dos requisitos do sistema onde as principais atividades são : elicitação, análise, especificação, gerenciamento e validação de requisitos. Havendo falhas na realização das atividades acima citadas haverá inconsistência nos documentos de requisitos e o que acarretará um software de baixa qualidade com um custo elevado. Mas o que é um requisito de software ? Os requisitos expressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do usuário, 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. Requisitos são objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema. Os requisitos de software são, obviamente, aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software. 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. Tradicionalmente, os requisitos de software são separados em requisitos funcionais e não-funcionais. Os requisitos funcionais são a descrição das diversas funções que clientes e usuários querem ou precisam que o software faça. Eles definem a funcionalidade desejada do software. O termo função é usado no sentido genérico de operação que pode ser realizada pelo sistema, seja através comandos dos usuários ou seja pela ocorrência de eventos internos ou externos ao sistema. São exemplos de requisitos funcionais: • "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 design do software. No design do software deve-se tomar a decisão de quais a funções o sistema efetivamente terá para satisfazer àquilo que os usuários querem. Requisitos não-funcionais são as qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente estes requisitos são descritos de maneira informal, de maneira controversa (por exemplo, o gerente que segurança mas
os usuários querem facilidade de uso) e são difíceis de validar. São exemplos de requisitos não-funcionais: • "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" • "o tempo de desenvolvimento não deve ultrapassar seis meses". A necessidade de se estabelecer os requisitos de maneira de forma precisa é crítica na medida que o tamanho e a complexidade do software aumentam. Os requisitos exercem influência uns sobre os outros. Por exemplo, o requisito de que o 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ão-ambígua • Completa • Correta • Compreensível • Consistente • Concisa • Confiável De acordo com Farley, um documento de especificação de requisitos deve possui as seguintes seções: • Visão geral do produto e Sumário • Ambientes de desenvolvimento, operação e manutenção • Interfaces Externas e Fluxo de Dados • Requisitos Funcionais • Requisitos de Desempenho • Tratamento de Exceções • Prioridades de Implementação • Antecipação de mudanças e extensões • Dicas e diretrizes de Design • Critérios de aceitação • Índice Remissivo • Glossário Construir um sistema de software com base em requisitos inconsistentes e mal definidos é como construir uma casa sem alicerce na areia... <iframe width="420" height="315" src="http://www.youtube.com/embed/UZfpUdYLsao" frameborder="0" allowfullscreen></iframe> <iframe width="420" height="315" src="http://www.youtube.com/embed/9wAsGcVSyZE" frameborder="0" allowfullscreen></iframe> EXERCICIOS 1) Em um DFD não é permitido conectar, por meio de um fluxo de dados, (A) um depósito de dados dirigido a um processo. (B)) uma entidade externa dirigida a um depósito de dados. (C) um processo dirigido a outro processo.
(D) uma entidade externa dirigida a um processo. (E) um processo dirigido a um depósito de dados. 2) Considere os requisitos: I. Os valores das faturas devem ser totalizados por cliente e por data de vencimento igual à fornecida pela área de contas a pagar. II. O software deve ser processável tanto em alta quanto em baixa plataforma. III. A data de vencimento constante dos boletos de pagamento deve ser igual à data de registro de entrada do documento no cadastro, mais 30 dias corridos. Exemplo de requisito não funcional consta APENAS em (A) I. (B) II. (C) III. (D) I e II. (E) II e III. 3). Considere os requisitos: I. Os valores das faturas devem ser totalizados por cliente e por data de vencimento igual à fornecida pela área de contas a pagar. II. O software deve ser processável tanto em alta quanto em baixa plataforma. III. A data de vencimento constante dos boletos de pagamento deve ser igual à data de registro de entrada do documento no cadastro, mais 30 dias corridos. Exemplo de requisito não funcional consta APENAS em (A) I. (B) II. (C) III. (D) I e II. (E) II e III. 024 – B 04) O método de modelagem de requisitos que utiliza diagramas de fluxo de dados e de controle como base, divide em partições as funções que transformam os fluxos, cria um modelo comportamental utilizando o diagrama de transição de estados e um modelo de conteúdo de dados através de um dicionário de requisitos, em que o sistema é representado como uma transformação de informação, sendo sua função global representada por uma bolha, é a análise: A) comportamental; B) dos requisitos; C) orientada a objetos; D) de tempo real; E) estruturada. 07-E] 05) Os métodos de análise de requisitos de software orientados a objeto possibilitam que o analista modele um problema representando: A) classes, objetos, entidades e operações; B) classes, objetos, entidades e relacionamentos; C) objetos, atributos, entidades e relacionamentos; D) classes, objetos, atributos e relacionamentos; E) classes, objetos, atributos e operações. [26-E] 06). Um analista se insere no ambiente de trabalho onde o sistema será usado. Ele observa o trabalho rotineiro e anota as tarefas reais nas quais os participantes
estão envolvidos. Trata-se da técnica de elicitação e análise de requisitos denominada (A) Workshop. (B) Casos de uso. (C) Validação de requisitos. (D) Etnografia. (E) Entrevista. 025 - D 07) O método de modelagem de requisitos que utiliza diagramas de fluxo de dados e de controle como base, divide em partições as funções que transformam os fluxos, cria um modelo comportamental utilizando o diagrama de transição de estados e um modelo de conteúdo de dados através de um dicionário de requisitos, em que o sistema é representado como uma transformação de informação, sendo sua função global representada por uma bolha, é a análise: A) comportamental; B) dos requisitos; C) orientada a objetos; D) de tempo real; E) estruturada.
(B) as entrevistas realizadas. (C) os questionários aplicados. (D) as apresentações dos fornecedores. (E)) as análises do sistema atual. 058 - E 12) Segundo a dimensão X o objetivo do processo de requisitos é levar de um entendimento vago e esparso do sistema, em sua fase inicial, a um entendimento completo e detalhado no final do processo. A dimensão Y objetiva expressar o conhecimento adquirido sobre o sistema durante o processo de requisitos e leva de descrições informais a descrições formais. Segundo a dimensão Z, o processo de requisitos visa levar os stakeholders de sua percepção individual sobre os requisitos a uma visão única e que reflita o acordo a que chegaram durante o processo de requisitos. As três dimensões X, Y e Z mencionadas no texto conceituam, respectivamente, (A) interoperabilidade, representação e concepção. (B) domínio, funcionalidade e testabilidade. (C) gradução, domínio e conectividade. (D) especificação, representação e consenso. (E) conectividade, estabilidade e especialização 042 - D
[07-E] 08) A infra-estrutura para garantir um melhor aproveitamento de reunião, com a técnica JAD-Joint Application Design, deve ser concebida de modo a (A) documentar a reunião com ferramentas específicas. (B) manter a pontualidade e a objetividade da reunião. (C) conduzir a apresentação dos processos modelados. (D)) colocar todos os participantes “cara-a-cara”. (E) executar follow-up e acompanhar as pendências. 033 - D
13) Inicialmente os stakeholders participam ativamente da fase de especificação de requisitos descrevendo as ações do sistema e os agentes que com elas interagem usando o modelo UML (A) de Objetos. (B) de Classes. (C) Funcional. (D) de Casos de Uso. (E) de Máquina de Estados. 025 D
09) As necessidades de informação automatizadas devem ser expressas, principalmente, na forma de requisitos (A) funcionais, somente. (B) de qualidade, somente. (C) de segurança, somente. (D) de hardware e software, somente. (E)) funcionais e não funcionais. 034 - E 10) Em um DFD, os processos funcionais primitivos normalmente devem ser detalhados utilizando-se a ferramenta (A) diagrama de transição de estado. (B) diagrama hierárquico de funções. (C) diagrama de entidades e relacionamentos. (D)) português estruturado. (E) diagrama de fluxo de dados. 057 - D 11) No processo de desenvolvimento de sistemas, NÃO se trata de uma técnica de coleta de dados, (A) as visitas às instalações usuárias.