Especificação de Requisitos de Software

Prévia do material em texto

Módulo: Modelagem De Software
Unidade 1: ESPECIFICAÇÃO DE REQUISITOS TRADICIONAIS (DL)
Subtítulo: Especificação de Requisitos Tradicionais
Requisitos de um sistema são: descrições do que o software deve fazer, os serviços que devem ser fornecidos por esse sistema e as suas restrições operacionais. Os requisitos descrevem o que o software deve fazer e o que não deve fazer sem dizer como fazer. (SOMMERVILLE, 2011).
Dentro da área de conhecimento "requisitos de software", obtemos diferentes definições de requisitos, sendo os principais tipos: produto versus processo, funcionais versus não funcionais, e propriedades.
Requisito de software é classificado como uma AÇÃO que o software deve executar que possui características e condições próprias para automatizar um processo de negócio de cliente.
Define-se requisitos de software como:
Uma condição ou uma capacidade de que o usuário necessita para solucionar um problema ou alcançar um objetivo;
Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação ou outros documentos impostos formalmente;
Uma representação documentada de uma condição ou capacidade (on-line).
Requisitos funcionais:
 Os requisitos funcionais descrevem explicitamente as funcionalidades (funções que o sistema deve realizar) e os serviços do sistema. Segundo Sommerville (2007), são declarações de serviços que o sistema deve prover, descrevendo o que o sistema deve fazer;
Os requisitos funcionais estão relacionados às funções de negócios do dia a dia que os usuários executam no sistema, como, por exemplo, o usuário deve ser capaz de pesquisar em todo o conjunto inicial de um banco de dados.
 Exemplos:
-Cadastrar clientes;
-Fazer análise de crédito;
-Fazer uma transação com banco de dados;
-Cadastrar um registro de atendimento;
-Imprimir relatório etc.
O sistema de compras on-line deverá informar, por e-mail, o número do pedido ao comprador quando este finalizar a compra.
Exemplos detalhados:
[RF01] O software deve permitir que o atendente efetue cadastro de clientes;
[RF02] O software deve permitir que o caixa efetue o registro de itens vendidos;
[RF03] O software deve permitir que o administrador gere um relatório de vendas por mês.
Os requisitos funcionais definem as funcionalidades oferecidas pelo sistema a ser desenvolvido, ou seja, dependem dos tipos de sistemas, do usuário e de onde eles serão usados.
Esses requisitos podem ser divididos em: USUÁRIO e SISTEMA.
Requisitos não funcionais:
Os requisitos chamados de não funcionais definem propriedades e restrições de um sistema, isto é, a complexidade de um software é determinada, portanto, por sua funcionalidade (o que o sistema faz) e por requisitos gerais que são parte do desenvolvimento do software, como custo, desempenho, confiabilidade, manutenibilidade, portabilidade, custos operacionais, entre outros. 
Também conhecidos como RNF, suplementares ou de qualidade, os requisitos não funcionais declaram as características que o sistema deve possuir e que estão relacionadas às suas funcionalidades, ou seja, fixam restrições sobre como os requisitos funcionais serão implementados, o que torna difícil, muitas vezes, uma distinção clara entre eles.
Como exemplo de características que o sistema deve possuir, temos: performance, portabilidade, segurança, usabilidade, qualidade do serviço (QoS), confidencialidade, confiabilidade, portabilidade, precisão, integridade, eficiência, entre outras. 
Os requisitos não funcionais podem ser mais severos e críticos que os requisitos funcionais; isso quer dizer que, se eles não forem atendidos, então, o sistema não serve: se não satisfaz, o sistema é inútil. Esses tipos de requisitos são as causas das principais insatisfações dos usuários com relação ao software.
Também são classificados em três tipos, sendo eles: requisitos do produto final, requisitos organizacionais e requisitos externos. Os requisitos do produto final referem-se a como o produto deve se comportar, sua velocidade de execução, confiabilidade, ente outros. Os requisitos organizacionais dizem respeito à consequência de políticas e procedimentos organizacionais que devem ser seguidos. Os requisitos externos são concernentes a fatores externos ao sistema e ao processo de desenvolvimento.
Além desses três tipos, os requisitos não funcionais ainda se dividem em outros diversos tipos, conforme a taxonomia dos requisitos não funcionais vista na figura a seguir.
Abordagens orientadas a produto: avaliam o grau em que o produto final atende a determinados RNFs.
· O sistema é avaliado pelo grau em que ele atende a determinado requisito não funcional.
· Propõe o uso de métricas para medir a qualidade do sistema.
· Existem várias propostas na literatura.
Abordagens orientadas a processo: integram o esforço de descrever e atender RNFs durante o processo de desenvolvimento.
· Em vez de avaliar a qualidade do produto final, a ênfase é dada a orientar o processo de desenvolvimento do sistema em relação aos NFRs que ele precisa atender.
· As decisões tomadas durante o projeto podem afetar de forma positiva ou negativa os RNFs.
· Essas interdependências servem para explicar o motivo pelo qual o sistema atende ou não a determinado RNF.
Comparação entre as abordagens orientadas a processo e a produto: não existe uma abordagem melhor que a outra; elas são complementares e devem ser usadas para obter sistemas que, de fato, atendam aos requisitos não funcionais dos stakeholders. Durante o estágio inicial de análise de requisitos, é recomendável usar abordagens de processo. As abordagens orientadas a produto são indicadas quando os requisitos estão bem definidos e podem ser especificados em termos de funcionalidades e fatores qualitativos mensuráveis.
Requisitos não funcionais, normalmente, são escritos na forma declarativa.
Exemplo: O Sistema de Conta Corrente On-line deverá permitir que o usuário de internet acesse a sua conta corrente em menos de cinco segundos.
Os requisitos não funcionais têm origem nas necessidades dos usuários, em restrições de orçamento, em políticas organizacionais, em necessidades de interoperabilidade com outros sistemas de software ou hardware ou em fatores externos como regulamentos e legislações (SOMMERVILLE, 2007).
Eles definem qualidades desejadas do sistema a ser desenvolvido e, muitas vezes, influenciam a arquitetura do sistema mais do que os requisitos funcionais. Determinam, ainda, desempenho, disponibilidade, confiabilidade, escalabilidade ou portabilidade de um sistema (POHL; RUPP, 2012).
Principais características:
Problemas comum nos requisitos:
· Nem sempre são óbvios.
· São originados de várias fontes (conflitos de interesse).
· Nem sempre retratam um problema que é possível de ser expresso por palavras.
· Sempre mudam.
· Os usuários nem sempre sabem o que desejam.
· Os usuários têm uma tendência de privilegiar a sua área ou o seu ponto de vista.
· Os analistas pensam que entendem os problemas melhor do que os próprios usuários.
Classes de requisitos:
Segundo Sommerville (2007), os requisitos podem ser vistos em três classes distintas: essenciais, importantes e desejáveis.
Em princípio, o sistema deve resolver todos os requisitos essenciais para requisitos desejáveis.
Requisitos de domínio: 
Também chamados de restrição, os requisitos de domínio são derivados do domínio de aplicação e seus processos, podendo ser novos requisitos funcionais em si, restringir os requisitos funcionais existentes, ou estabelecer como realizar cálculos e processamentos específicos.
Os requisitos de domínio estão relacionados ao comportamento próprio do sistema numa determinada aplicação ou no contexto "funcionando" para uma empresa. Esses requisitos restringem o próprio sistema; por exemplo, o sistema deverá ser implementado utilizando os serviços da web. Além disso, esses requisitos não são implementados, mas são cumpridos, pois limitam o espaço da solução disponível durante o processo de desenvolvimento.Sem uma compreensão satisfatória desses requisitos, pode ser impossível fazer o sistema operar de forma satisfatória (PRESSMAN, 2006), concluindo-se, então, que se não forem satisfeitos, pode ser impossível fazer o sistema operar adequadamente. Sommerville (2007) afirma que eles descrevem restrições sobre os serviços ou funções oferecidas pelo sistema. Ainda, limitam as opções para criar uma solução para o problema. (PFLEEGER, 2004).
Exemplo:
· [RN1]: os campos referentes ao orçamento do projeto vinculado só estarão ativos se o tipo de projeto for vinculado;
· [RN2]: o campo valor total orçado para o projeto é calculado somando-se os valores definidos para todas as rubricas incluídas no orçamento do projeto, seja ele vinculado ou não vinculado;
· [RN3]: a soma dos percentuais a serem distribuídos entre os fundos incluídos no plano de aplicação deve ser entre 0 e 100%.
Esses requisitos são expressos com o uso de uma linguagem específica do domínio da aplicação e, geralmente, de difícil compreensão para os engenheiros de software. Os especialistas do domínio podem, por julgarem óbvio, deixar de fornecer informações importantes e, como resultado, o requisito pode não ser implementado de forma satisfatória (SOMMERVILLE, 2008), ou seja, em um sistema de Departamento de Pessoal, por exemplo, são utilizados termos e regras específicos da área, e muitas vezes, o analista de requisitos não os conhece por não trabalhar em tal área e não ter a mesma experiência que seu cliente tem no ramo.
Simplificando, trata-se de requisitos que são do conhecimento do processo, do departamento e/ou da empresa cliente. Exemplificando: em um sistema de gestão de operadora de plano de saúde, os requisitos de domínio são conhecimentos específicos desta área de atuação, os quais apenas as pessoas que estão na empresa há anos possuem e podem detalhar de forma precisa ao analista de requisitos. Por isso, é de extrema importância que o analista de requisitos faça as perguntas certas, e que se atente aos mínimos detalhes.
Documentação de Requisitos:
Um documento de requisitos, segundo a norma IEEE, deverá conter declarações não ambíguas, e ser verificável, consistente, modificável, rastreável e usável durante todas as fases do ciclo de vida do requisito (IEEE; ANSI, 1996).
Todos os requisitos de um sistema devem ser capturados, modelados e documentados.
Podemos modelar e documentar os requisitos em diversas formas, como, por exemplo, casos de uso, diagramas DFD, diagrama SADT, rede de Petri etc.
Nesta etapa, interessa-nos modelar requisitos na forma de casos de uso e na forma declarativa.
· Requisitos na forma de casos de uso são utilizados quando existe interação (diálogo) entre os atores e o sistema. Eles descrevem o objetivo do ator ao interagir com o sistema.
· Requisitos na forma declarativa são utilizados quando é necessário descrever o que o sistema deve fazer em situações em que não existe iteração (ou em que a iteração é mínima) do ator com os sistemas.
O documento de requisitos é o produto final do processo de descobrimento de requisitos que reúne necessidades e propósitos demandados pelos stakeholders. Trata-se de uma declaração formal de requisitos de clientes, usuários finais e desenvolvedores de software (SOMMERVILLE; SAWYER, 1997; KOTONYA; SOMMERVILLE, 1998). Ainda, é uma especificação do que é requerido a um software fazer (não como) (MACAULAY, 1996).
Dependendo da organização, o documento de requisitos pode ter diferentes nomes e ser de vários tipos ou níveis de detalhamento. Também, pode ter diferentes papéis e diferentes formas e conteúdo. 
A aplicação do documento de requisitos é feita para formalizar o registro das necessidades dos stakeholders em um documento que descreve os produtos e serviços para especificação do software. Segundo Ryan (1998), o documento de requisitos é o meio utilizado para descrever as restrições quanto às características do produto e quanto ao processo de desenvolvimento, à interface com outras aplicações, à informação acerca do domínio da aplicação e informações de suporte ao conhecimento do problema, tais como modelos, termos especializados do negócio, recuperação e gerenciamento de informações em mudança (RYAN, 1998).
De acordo com Kauppinen e Sulonen (1997), o documento de requisitos tem três principais objetivos: ser um acordo entre cliente e fornecedor sobre o que o software deverá fazer; prover a base de especificação de software e projeto; e servir de subsídio para a verificação e validação do software. O documento de requisitos também serve de subsídio para o gerenciamento do projeto. O esforço de estimativa preliminar pode ser feito tão logo os requisitos tenham sido definidos. Outro importante benefício é a redução do tempo total e de esforço requerido para o desenvolvimento do software.
A seguir, a organização de um modelo de especificação de requisitos. E na sequência, um arquivo contendo um exemplo real.
Exemplo de Especificação de Requisitos: 
· CAPA
· EQUIPE
· CLIENTE
Delinear o objetivo da especificação de requisitos e especificar os leitores desse documento.
Introdução 
Objetivo 
Escopo
· Identificar pelo nome o produto de software a ser produzido (por exemplo, Gerenciador Eletrônico de Documentos – GED);
· Explicar o que o produto vai e, se necessário, não vai fazer;
· Descrever a aplicação de software que está sendo especificada, incluindo seus benefícios, objetivos e metas;
· Ser consistente com outras especificações de alto nível do sistema, se elas existirem.
Definições, acrônimos e abreviações 
Esta subseção deve conter todas as definições de termos, acrônimos e abreviações necessárias para corretamente entender a especificação. Essas informações podem ser apresentadas em apêndice ou em referências a outros documentos.
Referências 
Esta subseção deve:
· conter uma lista completa de todos os documentos referenciados na especificação;
· identificar cada documento adequadamente com título, autores, data, editor etc.;
· especificar as fontes de onde as referências foram obtidas.
Visão geral
Esta subseção deve:
· descrever resumidamente o conteúdo do restante da especificação;
· explicar como a especificação está organizada.
Descrição geral
Requisitos funcionais 
Descrever as funcionalidades do software: produzir uma lista de todos os requisitos funcionais e classificá-los como obrigatórios, desejáveis ou opcionais.
Requisitos não funcionais 
Descrever os requisitos não funcionais do software: produzir uma lista de todos os requisitos não funcionais e classificá-los segundo a taxonomia dos requisitos não funcionais.
Requisitos de interface
Definir como o software interage com as pessoas, com o hardware do sistema, com outros sistemas e com outros produtos. Detalhar os aspectos das interfaces do produto (normalmente, é feito um esboço das interfaces, levantado através de um protótipo ou de estudos em papel; também são detalhadas as interfaces com outros sistemas e componentes de sistemas). É obrigatório o desenho das telas referentes às principais funcionalidades do produto.
Atributos de qualidade
Descrever os requisitos de desempenho (velocidade de processamento, tempo de resposta etc.) e outros aspectos considerados necessários para que o produto atinja a qualidade desejada (por exemplo, portabilidade, manutenibilidade, confiabilidade etc.). Finalmente, classificar e rever os requisitos, estabelecendo prioridades (obrigatório, desejável ou opcional).
Características dos usuários
Descrever as características gerais dos usuários do produto, incluindo o nível educacional, a experiência e os conhecimentos técnicos.
 Restrições
Enumerar as restrições impostas pela aplicação, tais como padrões, linguagem de implementação, ambientes operacionais e limites de recursos.
Suposições e dependências
Listar todos os fatores que afetam os requisitos da especificação. Esses fatores não são restrições ao projeto do sistema, mas sim, mudanças que podem afetar os requisitos. Por exemplo, uma suposição pode ser de que a aplicação será instalada em um sistema operacional específico;se esse sistema operacional não estiver disponível, isso poderá afetar os requisitos.
Anexo
Citar todos os recursos e técnicas utilizadas para a extração de requisitos, assim como as questões feitas, os nomes das pessoas, as empresas, os telefones e as datas de contato.
image6.png
image7.png
image8.png
image1.png
image2.png
image3.png
image4.png
image5.png