Exibir código-fonte para Requisitos de software

 Esta pesquisa foi realizada por alunos de turmas anteriores e não foi revisada, portanto
 sua missão é revisar com cuidado e alterar/complementar este post sempre anotando as 
 referëncias (fontes) na parte inferior. Náo se esqueça de que não deve ser um Copy/Paste
 e sim uma síntese das pesquisas que fizer.


= O que é? =

<br>
*'''Segundo o IEEE'''
**1-Uma condição ou uma capacidade de que o usuário necessita, para solucionar um problema ou alcançar um objetivo.
**2-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.
**3- Uma representação documentada de uma condição ou capacidade
<br>

= Tipos  =

<br>
*'''Requisito do usuário'''-Declarações, em língua natural e/ou diagramas, sobre as funções que o sistema deve fornecer e restrições sob as quais deve operar, são requisitos abstratos de alto nível.
*'''Requisitos do sistema'''-Funções e restrições do sistema, de uma forma mais detalhada. Normalmente classiﬁcados como funcionais e não funcionais.

<br>
= Estudo =

<br>
O processo de requisição de software é composto por 6 partes principais:

* Viabilidade;
* Identificação;
* Análise;
* Especificação e documentação;
* Validação;
* Gestão dos requisitos;

<br>
== Viabilidade ==
<br>
O estudo da viabilidade permite que se decida se vale a pena ou não.
Deve-se verificar se:
* O sistema contribui para os objetivos organizacionais.
* O sistema pode ser construído com a tecnologia corrente e com o orçamento disponível.
* O sistema pode ser integrado com os outros sistemas em utilização
* O sistema pode ajudar na solução 

<br>
== Identificação ==
<br>

O passo seguinte a validação da viabilidade do projeto é a identificação dos requisitos.
; Objetivo dos requisitos:
* Definir as técnicas de coleta de requisitos baseada em fatores operacionais, táticos e financeiros; 
* Identificar os documentos e procedimentos que definem as politicas de negócios ;
* Definir as fronteiras do sistema; 
* Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema;
* Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários;
<br>

== Análise ==
<br>
Análise de requisitos pode ser um processo longo e árduo. Novos sistemas mudam o ambiente e a relação entre as pessoas, então é importante identificar todos os envolvidos, levando em conta todas as suas necessidades e assegurando que eles compreenderam as implicações dos novos sistemas. Os analistas podem empregar várias técnicas para elicitar os requisitos dos clientes.
A análise é a etapa seguinte a identificação dos requisitos, inclui atividades como :
*Classificação;
*Resolução de conflitos;
*Priorização;
*Confirmação;
<br>
=== Classificação ===
A classificação dos requisitos é de extrema importância para a definição de prioridades, para a separação por níveis de importância, riscos, custos, etc e para validação por diferentes pessoas envolvidas. Podendo assim fazer um 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).
<br>
== Especificação e documentação ==
; Especificações dos requisitos de sistema:
É 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:
<br>
;Funcionais
* Descrevem a funcionalidade ou os serviços do sistema.
* Dependem do tipo de software, das expectativas dos usuários e do tipo de sistema que está sendo desenvolvido.
* Requisitos funcionais do usuário são descritos de forma bem geral, mas os requisitos funcionais de sistema descrevem a função de sistema detalhadamente.

;Não funcionais
* Definem as propriedades de sistemas e restrições, por ex: confiabilidade, tempo de resposta e espaço em disco;
* Requisitos não funcionais dizem respeito ao sistema como um todo. Alguns podem restringir o processo que é utilizado para desenvolver o sistema;
* Podem ser mais críticos que requisitos funcionais. A falha em atender um requisito não funcional de sistema pode inutilizar o sistema.
<br>
Podem-se distinguir três tipos de especificação:
;especificação de requisitos do usuário ou 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).
;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.
<br>

== Validação ==
<br>

Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende.
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
<br>
== Gestão dos requisitos ==
Para manter a consistência entre as várias alterações pedidas, é 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.
<br>

== Bibliografia ==
<br>

*Soares (2005). Introdução, Identificação e Análise em Engenharia de Requisitos. António Lucas Soares. 2005.
*http://pt.wikipedia.org/wiki/Engenharia_de_requisitos
*http://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/aula04.pdf
*http://sylverio.com.br/blog/2009/05/requisitos-de-software/