Aula 02: REQUISITOS DE SISTEMA E REQUISITOS DE USUÁRIO 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 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
imponha
da
informação
obstáculos
para
se
disposta 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
detalhadamente,
exemplo que
visam
descrito 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.
1
OBS: Fonte da imagem: Livro Engenharia de Software - Sommerville
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. 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 atingir plenamente os objetivos. Notadamente neste caso não estão sendo quaisquer
levado
em
tecnologias
consideração 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://eratas-tads.blogspot.com/2008/10/requisitos-de-usuario-2.html). O usuário realiza o seu pagamento independente da infra-estrutura 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.
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-speed-shift/). 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. 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. [editar]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ão-funcionais 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ãofuncionais. [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 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).
de
software
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; •
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) 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".