Mostrar código-fonte de Levantamento de requisitos

<slideshow style="flower" headingmark="⌘"  incmark="…" scaled="true" >
;author: Vários autores
;subfooter: {{date}}
;footer: 
</slideshow>

O levantamento de requisitos é uma [[Fases_de_um_sistema_de_informação| fase de um sistema de informação]].

Os requisitos podem ser descrições de como um sistema de informação se deve comportar, das suas propriedades e das suas restrições ou condicionantes do seu desenvolvimento.

A fase de levantamento de requisitos é, então, de extrema importância, pois é ela que garante que o novo sistema de informação será capaz de fazer o que é suposto fazer.

== Sub-tarefas do levantamento de requisitos ⌘ ==
Esta fase é, em si, um processo que implica uma série de outras tarefas:

# Estabelecer objetivos:
# Compreender o contexto:
# Organizar o conhecimento: 
# Fazer o levantamento dos requisitos:



=== Estabelecer objetivos ⌘ ===


* Definir objetivos do negócio;
* Definir o problema a resolver;
* Definir as restrições do sistema:
** Restrições económicas;
** Restrições políticas;
** Restrições tecnológicas;
** Restrições ambientais;
** Restrições temporais, etc.;

=== Compreender o contexto: ⌘ ===
* Compreender a estrutura organizacional;
* Compreender o domínio da aplicação;
* Identificar os sistemas existentes;

=== Organizar o conhecimento: ⌘ ===
* Identificar os stakeholders e os utilizadores:
** Compreender as necessidades dos interessados num sistema de informação é decisivo para o desenvolvimento de uma solução efetiva;
** Conhecer os interessados e as suas necessidades permite definir as fronteiras do sistema:
*** Quem são os utilizadores do SI? Quem fornece, utiliza, remove informação do SI?
*** Como é que o SI contém a informação necessária ao seu funcionamento?
*** Onde é que o SI é utilizado?
*** Quem será afetado pelas saídas que o SI produz?
*** Quem vai ficar responsável pela manutenção do SI?
*** Que outros sistemas interagem com o novo SI?
* Definir prioridades para os objetivos;
* Filtrar o domínio de conhecimento;

=== Fazer o levantamento dos requisitos: ⌘ ===
* Identificar requisitos dos stakeholders;
* Identificar requisitos do domínio;
* Identificar requisitos da organização.

O contexto no qual o sistema se vai inserir e as condições impostas ao processo, influenciam a forma como o levantamento de requisitos é feito.

== Funcionais e não funcionais ⌘ ==

=== Requisitos não-funcionais ⌘ ===
São os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas. Não é preciso o cliente dizer sobre eles, pois eles são características mínimas de um software de qualidade, ficando a cargo do desenvolvedor optar por atender esses requisitos ou não. Ver [[https://pt.wikipedia.org/wiki/Requisito_n%C3%A3o-funcional]]

* Requisitos de produtos : Requisitos que especificam o comportamento do produto.Ex. portabilidade; tempo na execução; confiabilidade,mobilidade, etc.
*Requisitos da organização: Requisitos decorrentes de políticas e procedimentos corporativos. Ex. padrões, infra-estrutura,etc.
* Requisitos externos: Requisitos decorrentes de factores externos ao sistema e ao processo de desenvolvimento. Ex. requisitos de interoperabilidade, legislação,localização geográfica etc.
* Requisitos de facilidade de uso. Ex.: usuários deverão operar o sistema após um determinado tempo de treinamento.
* Requisitos de eficiência. Ex.: o sistema deverá processar n requisições por um determinado tempo.
* Requisitos de confiabilidade. Ex.: o sistema deverá ter alta disponibilidade, p.exemplo, 99% do tempo.
* Requisitos de portabilidade. Ex.: o sistema deverá rodar em qualquer plataforma.
* Requisitos de entrega.Ex.: um relatório de acompanhamento deverá ser fornecido toda segunda-feira.
* Requisitos de implementação.: Ex.: o sistema deverá ser desenvolvido na linguagem Java.
* Requisitos de padrões.: Ex. uso de programação orientada a objeto sob a plataforma A.
* Requisitos de interoperabilidade.:Ex. o sistema deverá se comunicar com o SQL Server.
* Requisitos éticos. Ex.: o sistema não apresentará aos usuários quaisquer dados de cunho privativo.
* Requisitos legais. Ex.: o sistema deverá atender às normas legais, tais como padrões, leis, etc.
* Requisitos de Integração. Ex.: o sistema integra com outra aplicação.

=== Requisitos funcionais ⌘ ===
São os requisitos relacionados com as funções específicas que o sistema de informação é suposto executar, e que levaram à sua instalação. São exemplos de possíveis requisitos funcionais de um registo clínico electrónico:

* capacidade de recolher os dados das admissões de doentes
* capacidade de recolher os dados das altas de doentes
* capacidade de recolher os dados de prescrição

==Processos para descobrir requisitos ⌘==

# Requisitos conduzidos por políticas organizacionais - No hospital XYZ todos os diagnósticos são identificados através de código [[International_Classification_of_Deseases|ICD]];
# Requisitos iniciados por problemas:
#* Diagnóstico conduzido por eventos;
#* Análise baseada em modelos;
# Requisitos iniciados por exemplos;
# Requisitos impostos pelo ambiente externo:
#* Normas, regulamentos, etc.
#** Exemplo: Nos hospitais portugueses é obrigatória a identificação dos utentes nacionais com o número de utente existente no cartão do cidadão
#** Exemplo: [[Avaliação_Requisitos_SBIS|Ver Requisitos SBIS para o RES]]

==Instrumentos de identificação de requisitos ⌘==

# Entrevistas e questionários - técnicas simples, mas difíceis de aplicar porque:
#* Enviesamento do entrevistadores;
#* Predisposição do entrevistado; pode ser melhorada a predisposição usando linguagem apropriada e técnicas de negociação;
#* Relação pessoal;
# Workshops de requisitos - técnica de grupo para o '''debate e acordo das questões associadas à identificação de requisitos''':
#* Grupo é composto por representantes dos diversos stakeholders identificados;
#* Discussão é mediada por especialista na identificação e levantamento de requisitos;
# Brainstorming - técnica de grupo para a geração de '''novas ideias''':
#* Encoraja a participação de todos os envolvidos no processo de criação de SI;
#* Permite o aproveitamento e o refinamento de outras ideias e a criação de novas;
#* Encoraja o pensamento livre;
# Cenários - técnica que permite colocar os interessados no SI perante uma situação realista em que simulam ou antevêem a interação com o SI;
# Storyboarding - técnica que permite obter, rapidamente, reações dos utilizadores para os conceitos propostos para o SI:
#* Passivo - capturas de ecrã; regras do negócio; relatórios;
#* Ativo - slide shows; animações; simulações;
#* Interativo - demos; apresentações interativas;
# Protótipos - técnica que consiste na criação de uma versão inicial do sistema para apoio à identificação, análise e validação de requisitos
#* Baixa fidelidade - Esquema iniciais para discussão, [[Casos de uso]], [[Diagramas de Sequência]]
#* Alta fidelidade - [[Mockups]] com um aspecto muito próximo do final

== Formato dos requisitos ⌘ ==

* Numerar requisitos
* Esquemas em formato [[UML]]
* Uso de linguagem natural
* Incluir critérios de aceitação dos requisitos

==Problemas no levantamento de requisitos ⌘ ==

[[Ficheiro:Requisitos.png|thumb|400px|Ilustração cómica da dificuldade de comunicação e articulação entre os vários intervenientes no desenvolvimento de um sistema]]

Vários problemas podem surgir durante o levantamento de requisitos, nomeadamente:
# Os utilizadores '''não sabem o que querem''' ou sabem o que querem, mas não conseguem articulá-lo;
# Os utilizadores pensam que sabem o que querem '''até que''' os desenvolvedores lhes dêem o que disseram que queriam;
# Os analistas '''acham que compreendem''' os problemas dos utilizadores melhor que os mesmos.

Uma forma de minimizar os problemas é serem discutidos de forma iterativa em várias versões até à final.