Levantamento de requisitos: diferenças entre revisões
(Há 25 edições intermédias do mesmo utilizador que não estão a ser apresentadas) | |||
Linha 1: | Linha 1: | ||
<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]]. | O levantamento de requisitos é uma [[Fases_de_um_sistema_de_informação| fase de um sistema de informação]]. | ||
Linha 5: | Linha 11: | ||
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. | 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 == | == Sub-tarefas do levantamento de requisitos ⌘ == | ||
Esta fase é, em si, um processo que implica uma série de outras tarefas: | Esta fase é, em si, um processo que implica uma série de outras tarefas: | ||
# Estabelecer objetivos: | # Estabelecer objetivos: | ||
# Compreender o contexto: | # Compreender o contexto: | ||
# Organizar o conhecimento: | |||
# Organizar o conhecimento: | |||
# Fazer o levantamento dos requisitos: | # 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. | 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. | ||
==Processos para descobrir requisitos== | == 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== | ==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. |
Edição atual desde as 16h16min de 10 de fevereiro de 2017
<slideshow style="flower" headingmark="⌘" incmark="…" scaled="true" >
- author
- Vários autores
- subfooter
- Predefinição:Date
- footer
</slideshow>
O levantamento de requisitos é uma 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 [[1]]
- 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 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: Ver Requisitos SBIS para o RES
- Normas, regulamentos, etc.
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 ⌘
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.