Especificação de Software: Levantamento e Análise de Requisitos

Prévia do material em texto

[Type text]	[Type text]	[Type text]
	Especificação do Software	 PDS – 23/08/2012
ESPECIFICAÇÃO DO SOFTWARE
Agosto/2012
Fábio Guedes, Renato Saulo & Simone Netto
Professor Antonio Junior
Campus Akxe – Curso: Sistemas de Informação
Turma: 3004
Sumário
Introdução
Fase da Engenharia de Software conhecida também como Engenharia de Requisitos e pode ser entendida como um conjunto de técnicas de levantamento, documentação e análise de requisitos de software.
“Quando este levantamento é bem feito, os requisitos implícitos são minimizados. Quando a documentação é bem feita, os requisitos documentados têm maiores chances de serem corretamente entendidos pelos desenvolvedores. Algumas técnicas de análise dos requisitos ajudam a produzir especificações mais precisas e inteligíveis.”			
			(PAULA FILHO, Wilson de Pádua. 2009)
Pesquisa em mais de 350 empresas sobre os seus mais de 8.000 projetos de software – 30 % dos projetos foram cancelados. Dos concluídos, 9% entregues dentro do prazo e do valor estimado (Standish Group –1994).
Fatores principais relatados como causas das falhas:
1. Requisitos incompletos (13.1%)
2. Falta de envolvimento por parte do usuário (12.4%)
3. Falta de recursos (10.6%)
4. Expectativas não realistas (9.9%)
5. Falta de apoio dos executivos (9.3%)
6. Modificações nos requisitos e nas especificações (8.7%)
7. Falta de planejamento (8.1%)
8. O sistema não era mais necessário (7.5%)
A imprecisão na especificação do software pode ter como exemplos de consequências negativas:
- Construção de um software que resolve o problema de maneira errada
- O software não funcionar como o esperado
- O software ser difícil para os usuários entenderem e utilizarem
- O software ter um alto custo ao final do desenvolvimento
Levantamento dos Requisitos do Software
Determinação do Contexto 
Levanta os aspectos dos processos de negócios ou de um sistema maior, que sejam relevantes para a determinação dos requisitos do produto. Esta atividade é a mais variada de todas. Dependendo de sua complexidade, pode ser resolvida numa simples conversa informal ou requerer a execução de um complicado processo.
Definição do Escopo 
Delimita os problemas que o produto se propõe a resolver e que valor ele acrescenta ao usuário. A determinação do Contexto e a Definição do Escopo são realizadas, principalmente, na fase de concepção. Seus resultados também podem ser revistos posteriormente se necessário.
Definição dos Requisitos 
Neste ponto são identificados os grupos de usuários do produto e outros sistemas que interajam com o produto (atores), e as representações de funções do produto (casos de uso).
Detalhamento dos Requisitos de Interface
Levanta os aspectos do produto que os usuários consideram como requisitos. Normalmente, é feito um esboço das interfaces do usuário, levantado através de um protótipo executável. Os esboços apenas facilitam a visualização dos verdadeiros requisitos.
Detalhamento dos Requisitos Funcionais 
Descreve as funções que um produto deverá realizar em benefício dos usuários. Utiliza a notação de casos de uso. Cada caso de uso representa uma fatia da funcionalidade do produto.
Detalhamento dos requisitos Não Funcionais 
Descreve os requisitos de desempenho e outros aspectos considerados como necessários para que o produto atinja a qualidade desejada.
Revisão do Requisitos 
Determina se todos os passos satisfazem aos critérios de qualidade de requisitos. Deve fornecer informações suficientes para o desenho do produto.
Análise de Viabilidade
Objetivos:
O fluxo de análise via os seguintes objetivos:
- Verificar a qualidade dos requisitos dos obtidos através do fluxo de requisitos.
- Detalhar estes requisitos o suficiente para que atinjam o nível de detalhe adequado aos desenvolvedores
Os casos de uso descrevem o comportamento esperado do produto como um todo. Os
diagramas de casos de uso descrevem os relacionamentos dos casos de uso entre si e com os
atores, enquanto que os fluxos descrevem os detalhes de cada caso de uso.
As classes representam os conceitos do mundo da aplicação que sejam relevantes para a
descrição mais precisa dos requisitos. Os diagramas de classes mostram os relacionamentos
entre estas, e as especificações das classes descrevem os respectivos detalhes.
As realizações dos casos de uso mostram como objetos das classes descritas colaboram entre si
para realizar os principais roteiros que podem ser percorridos dentro de cada caso de uso.
Características de Qualidade dos Requisitos
Para servir de base a um produto de boa qualidade, a própria Especificação de Requisitos deve satisfazer uma série de características de qualidade. As características mais importantes são as seguintes:
Correção
Uma Especificação dos Requisitos é correta se todo requisito presente nela realmente é um requisito do produto a ser construído. Não existe ferramenta que garanta a correção de uma Especificação dos Requisitos. Para verificá-la, deve-se checar a coerência da Especificação dos Requisitos do Software com outros documentos da aplicação, tais como a Proposta de Especificação do Software, a Especificação dos Requisitos do Sistema e outros padrões referentes à área de aplicação. Deve-se ainda solicitar a aprovação formal da Especificação dos Requisitos do Software por parte do cliente, sem a qual o projeto não poderá prosseguir.
Precisão
Uma Especificação dos Requisitos é precisa se todo requisito presente possuir apenas uma única interpretação, aceita tanto pelos desenvolvedores quanto pelos usuários chaves. Em particular, uma Especificação dos Requisitos deve ser compreensível para todo o seu público alvo, e deve ser suficiente para o desenho dos testes de aceitação. Recomenda-se a inclusão no glossário da Especificação dos Requisitos de todos os termos contidos no documento que possam causar ambiguidades em sua interpretação.
Os seguintes meios devem ser usados para garantir maior precisão da Especificação dos Requisitos:
- Revisões técnicas;
uso de notações e ferramentas de análise, orientadas a objetos no caso do Praxis.
Completeza
Uma Especificação dos Requisitos é completa se reflete todas as decisões de especificação que foram tomadas, não contendo cláusulas de pendências. Uma Especificação dos Requisitos completa deve:
- conter todos os requisitos significativos relativos a funcionalidade, desempenho, restrições de desenho, atributos e interfaces externas;
- definir as respostas do software para todas as entradas possíveis, válidas e inválidas, em todas as situações possíveis;
- conter um glossário de todos os termos técnicos e unidades de medida, assim como referências completas a todos os diagramas, figuras e tabelas.
Consistência
Uma Especificação dos Requisitos é consistente se não há conflitos entre nenhum dos subconjuntos de requisitos presentes. Existem três tipos comuns de conflitos entre requisitos:
- conflito entre características de objetos do mundo real - por exemplo, formatos de relatórios ou cores de sinalização);
- conflito lógico ou temporal entre ações - por exemplo, um requisito diz que a ação A deve ser realizada antes da ação B, e outro diz o contrário;
- uso de termos diferentes para designar o mesmo objeto do mundo real - por exemplo, “lembrete” versus “mensagem”.
Priorização
Uma Especificação dos Requisitos é priorizada se cada requisito é classificado de acordo com a respectiva importância e estabilidade. A estabilidade estima a probabilidade de que o requisito venha a ser alterado no decorrer do projeto, com base na experiência de projetos correlatos. A priorização classifica o requisito de acordo com um dos seguintes graus:
- Requisito essencial – requisito sem cujo atendimento o produto é inaceitável;
- Requisito desejável – requisito cujo atendimento aumenta o valor do produto, mas cuja
Ausência pode ser relevada em caso de necessidade (por exemplo, de prazo);
- Requisito opcional – requisito a ser cumprido se houver disponibilidade de prazo e orçamento, depois de atendidos os demais requisitos.
VerificabilidadeUma Especificação dos Requisitos é verificável se todos os seus requisitos são verificáveis. Um requisito é verificável se existir um processo finito, com custo compensador, que possa ser executado por uma pessoa ou máquina, e que mostre a conformidade do produto final com o requisito. Em geral requisitos ambíguos não são verificáveis, assim como requisitos definidos em termos qualitativos, ou contrários a fatos técnicos e científicos.
Modificabilidade
Uma Especificação dos Requisitos é modificável se sua estrutura e estilo permitirem a mudança de qualquer requisito, de forma fácil, completa e consistente. A modificabilidade geralmente requer:
- organização coerente, com índices e referências cruzadas; ausência de redundância entre requisitos;
definição separada de cada requisito.
Rastreabilidade
Uma Especificação dos Requisitos é rastreável se permite a fácil determinação dos antecedentes e consequências de todos os Requisitos. Dois tipos de rastreabilidade devem ser observados.
- Rastreabilidade para trás - deve ser possível localizar a origem de cada requisito. Deve- se sempre saber porque existe cada requisito, e quem ou o que o originou. Isto é importante para que se possa avaliar o impacto da mudança daquele requisito, e dirimir dúvidas de interpretação. 
- Rastreabilidade para frente - deve ser possível localizar quais os resultados do desenvolvimento que serão afetados por cada requisito. Isto é importante para garantir que os itens de análise, desenho, código e testes cubram todos os requisitos, e para localizar os itens que serão afetados por uma mudança nos requisitos.
Documentação dos Requisitos do Software
“A Especificação dos Requisitos do Software deve ser escrita por membros da equipe de desenvolvimento de um projeto, com a participação obrigatória de um ou mais usuários chaves do produto.”
 (PAULA FILHO, Wilson de Pádua. 2009)
É a declaração oficial do que é exigido dos desenvolvedores de sistema. Deve incluir os requisitos de usuário e uma especificação detalhada dos requisitos do sistema.
Se houver um grande número de requisitos, pode-se separar os requisitos mais detalhados do sistema em outro documento.
Recomendações:
Deve especificar somente o comportamento externo do sistema;
Deve especificar as restrições à implementação;
Deve ser de fácil modificação;
Deve servir como referência para manutenção do sistema;
Deve registrar a estratégia sobre o ciclo de vida do sistema;
Deve caracterizar resposta aceitáveis para eventos indesejáveis.
Há um padrão para documentação de requisitos: 
Modelo IEEE/ANSI 830-1993
1. Introdução
1.1 Propósito do documento de requisitos
1.2 Escopo do produto
1.3 Definições, acrônimos e abreviações
1.4 Referências
1.5 Visão geral do restante do documento
2. Descrição Geral
 2.3 Perspectivas do produto
2.2 Funções do Produto
2.3 Características do usuário
2.4 Restrições gerais
2.5 Suposições e dependências
3. Requisitos específicos
4. Apêndices
5. Índice
Análise dos Requisitos do Software
Enquanto o Levantamento dos Requisitos focaliza a visão que cliente e usuários têm dos requisitos de um produto, a Análise dos Requisitos focaliza a visão dos desenvolvedores. Entretanto, o processo ainda está dentro do espaço de problema, e não dentro do espaço de soluções. 
O Modelo de Análise usa a notação orientada a objetos para descrever de forma mais precisa os conceitos do domínio da aplicação que sejam relevantes para o entendimento detalhado dos requisitos do produto. Esta notação é usada como notação de modelagem do problema, independentemente do uso posterior da tecnologia orientada a objetos para desenho e implementação.
As atividades iniciais de Análise dos Requisitos levam à identificação de classes que representem adequadamente os conceitos expressos nos requisitos, e à descoberta dos respectivos atributos e relacionamentos. Esta parte da análise fornece o modelo lógico de dados (equivalente a um modelo de entidades e relacionamentos), que pode corresponder ao modelo conceitual de um banco de dados usado pelo produto. Estas classes são incluídas no Cadastro dos Requisitos.
São então detalhadas as responsabilidades de cada classe, definindo-se as respectivas operações. Estas operações são usadas para produzir as realizações dos casos de uso, nas quais os fluxos dos casos de uso são descritos em termos de interações entre as classes identificadas. Geralmente o detalhamento das realizações dos casos de uso leva à descoberta de ambiguidades, omissões e inconsistências nos requisitos funcionais, contribuindo para o aperfeiçoamento destes. 
Protótipos e estudos de viabilidade podem complementar a análise; por exemplo, um protótipo implementado em um sistema de bancos de dados pode ajudar a decidir se é viável atender aos requisitos de desempenho especificados para transações com bancos de dados.
Exemplo
http://www.ime.usp.br/~edu/compugrafica/Especificacao.pdf
Conclusão
Após o levantamento, documentação e análise dos requisitos, a Especificação dos Requisitos torna-se confiável o suficiente para servir de base ao planejamento detalhado do restante do projeto, com prazos e orçamentos firmes. 
Quanto mais preciso esse processo for, menos desperdícios acontecerão ao longo do projeto, evitando aumentos excessivos de custos de desenvolvimento, trazendo maior satisfação aos clientes e permitindo um planejamento coerente e assertivo das atividades. 
	É de fundamental importância a participação direta dos clientes na Especificação de Requisitos, pois os mesmos serão os usuários do sistema e o papel da equipe técnica envolvida nesta fase é compreender as necessidades dos clientes, fazendo-as virar requisitos específicos e que retratem exatamente essa realidade.
Bibliografia
http://www.ime.usp.br/~edu/compugrafica/Especificacao.pdf
Acesso em 21/08/2012 às 15:19h
http://www.cin.ufpe.br/~gamr/FAFICA/Engenharia%20de%20Software/Aula%207%20-%20Especificacao_de_Software2.ppt
Acesso em 23/08/2012 às 01:06h
http://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/2006/aula05_Requisitos.pdf
Acesso em 23/08/2012 às 01:15h
PAULA FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. Terceira edição. Rio de Janeiro: LTC Editora. 2009
5