DOCUMENTO DE REQUISITO DE SOFTWARE <<nome do projeto>> PARTICIPANTES <<Nome do aluno 1>> <<Nome do aluno 2>> <<Nome do aluno 3>> <<Nome do aluno 4>> <<Nome do aluno 4>> Belo Horizonte - <<mês/ano>> 1
<<Os principais objetivos de um controle de versão são: criar um histórico das revisões; auxiliar no trabalho em equipe; possibilitar a divisão segura do projeto e a divisão segura das atividades das partes envolvidas>> CONTROLE DE VERSÃO (Histórico das alterações) Versão Responsável Descrição Data <<versão>> <<Nome do responável>> <<Descrição da alteração>> <<Data da alteração>> 1.0 Mônica 1.0 Magali Descrever uma introdução sobre o sistema. A sua situação atual. Breve comentário sobre a situação proposta. Definição dos Stakeholders. Identificação inicial dos requisitos funcionais. 04/052009 11/05/2009 2
Conteúdo 1 - INTRODUÇÃO... 4 2 - VISÃO GERAL... 4 3 CONVENÇÕES E NOMENCLATURAS... 5 4 - PARTES INTERESSADAS (STAKEHOLDERS)... 6 5 REQUISITOS FUNCIONAIS... 7 5.1 DIAGRAMA DE CASO DE USO... 7 5.2 REQF001 ATENDER PACIENTE... 7 5.3 REQF002 EMITIR RELATÓRIO DE FLUXO DE CAIXA... 8 5.4 REQF003 AGENDAR CONSULTA... 8 6 REQUISITOS NÃO FUNCIONAIS... 9 6.1 - USABILIDADE... 9 6.2 - DESEMPENHO... 9 6.3 SOFTWARE E HARDWARE... 9 6.4 - SEGURANÇA... 10 6.4 - CONFIABILIDADE... 10 6.5 - DISTRIBUIÇÃO... 10 7 - INTERFACE SUGERIDA (IHM) - PROTOTIPAÇÃO... 11 3
1 - INTRODUÇÃO <<Breve introdução, incluindo objetivos e a motivação>> Este documento servirá de base para a definição dos requisitos de um software que será desenvolvido para realizar a gestão de um consultório médico. 2 - VISÃO GERAL <<No máximo dois parágrafos o processo atual. EXEMPLO:>> Atualmente o processo de marcação de consulta e atendimento são realizados através de um sistema elaborado a partir de regras de negócio que já não atendem às necessidades atuais. O sistema atual foi desenvolvido em linguagem Clipper versão 5 e utiliza o padrão de armazenamento.dbf (arquitetura ISAM). O sistema possui os seguintes módulos em funcionamento: marcação de consultas, atendimento (anamnese completa), controle do caixa, relatórios operacionais (contas a pagar, receber e fluxo de caixa) e relatórios gerenciais. <<Um parágrafo sobre os problemas atuais do sistema. EXEMPLO: >> Há problemas de constantes interrupções no sistema, uma vez que a base de dados não suporta adequadamente o volume de dados (corrupções de arquivos). O sistema não oferece uma interface WEB para possibilitar a consulta on-line das marcações e acompanhamento por parte do paciente de alguns processos. Além dos problemas acima, a empresa tem dificuldades em encontrar pessoal qualificado para realizar manutenções preventivas e corretivas no sistema. <<Um parágrafo sobre o que será feito em linhas gerais. EXEMPLO: >> Diante dos problemas apresentados, será desenvolvido uma solução completa para consultório médico, incluindo as funcionalidades já presentes no sistema atual, abordando uma visão de sistemas distribuídos na WEB atendendo aos principais requisitos funcionais e não funcionais especificados pelo cliente nos trabalhos de análise de requisitos descritos a seguir. 4
3 CONVENÇÕES E NOMENCLATURAS <<auxiliar o entendimento das abreviações usadas no documento>> Será utilizada a seguinte convenção de nomenclatura para identificação dos requisitos funcionais e não funcionais do sistema: REQUISITO DESCRIÇÃO REQF999 Requisito Funcional + Número do Requisito DESCRIÇÃO PARA O REQUISITO FUNCIONAL Módulo de manutenção dos dados do paciente. REQNF999 Requisito NÃO Funcional + Número do Requisito DESCRIÇÃO PARA O REQUISITO NÃO FUNCIONAL Tempo de emissão do relatório de fatura semanal não deve ser superior a 2 minutos PRIORIDADE PRIORIDADE DO REQUISITO FUNCIONAL. Média PRIORIDADE DO REQUISITO NÃO FUNCIONAL. Alta PRIORIDADE: Alta: São requisitos essenciais, imprescindíveis, devem ser implementados impreterivelmente. Média: Sem esse requisito o sistema pode entrar em funcionamento, porém de forma pouco satisfatória. Baixa: Esse requisito não compromete o funcionamento do sistema, ou seja, o sistema pode funcionar de forma satisfatória sem ele. 5
4 - PARTES INTERESSADAS (STAKEHOLDERS) <<Stakeholder (em português, partes interessadas), são as pessoas que afetam ou são afetadas pelo sistema e que por sua vez terão influência sobre os requisitos desse sistema. Trata-se de um termo usado inicialmente na administração de empresas, o sucesso de um projeto, sistema ou empresa depende diretamente da efetiva participação dos Stakeholders. EXEMPLO:>> Os Stakeholders do Sistema de Consultório Médico estão divididos basicamente nos seguintes grupos: Gerência, Sistemas, Usuários Finais, Usuário Externos. O quadro a seguir apresenta a divisão dos grupos de Stakeholders, uma descrição de cada um e suas respectivas responsabilidades: Grupo Stakeholder Descrição Responsável Gerência Gerencia de Sistemas Gerenciar as atividades relativas ao desenvolvimento e implementação do sistema. Administrador Administrar as atividades administrativas e técnicas do consultório, incluindo antendimento, marcação de consultas e financeiro. Gerência de Gerenciar as atividades do atendimento do Atendimento consultório. Sistemas Analista Responsável pelo levantamento, análise dos resultados e projetos do sistema. Responsável pela especificação de programas. DBA Responsável pelo projeto do banco de dados e alterações que interferem na estrutura das tabelas do sistema. Programador Responsável pela codificação do sistema a partir das especificações realizadas pelo analista. Documentador Responsável pela documentação do sistema, documentação das reuniões e documentação de usuário. Roseli Dr. Carlos Alberto Arlete Luiz Augusto Juliana João Bosco Vinícius Usuários Médico Atendimento ao paciente. Dr.Carlos Alberto, Dr. Regina Coeli, Dr. Osmar Prado. Auxiliares Atendimento auxiliar consultório. Glória e Ana Paula. Secretária Agendamento, controle internos. Arlete e Bernadete. Paciente Usuário do sistema (acesso WEB). Usuário secundário (no atendimento). Pacientes da clínica/consultório 6
5 REQUISITOS FUNCIONAIS <<São os Casos de Uso. Deve-se descrever os seguintes itens: nome do caso de uso; descrição resumida (objetivo); ator principal; ator secundário; cenário principal; cenário alternativo; pré-condição; pós-condição;fluxo de exceção. O diagrama de caso de uso deve ser representado. VEJA O EXEMPLO:>> 5.1 DIAGRAMA DE CASO DE USO 5.2 REQF001 ATENDER PACIENTE Objetivo: Realizar o atendimento do paciente. Este processo consiste em armazenar os principais objetos do atendimento (anamnese) como por exemplo: a Queixa Principal (QP), Histórico da Doença Atual (HDA), História Médica Pregressa (HMP), Atendimento Cirúrgico (AC), Resultado dos Exames (RE), Doenças Relacionadas (DR). 7
Ator principal: Médico. Ator secundário: Paciente. Cenário Principal: 01 Acessar o módulo de Atendimento. 02 Informar Login e Senha (Somente para usuários com perfil médico). 03 Informar o nome do Paciente. 04 - Preencher itens da Queixa Principal. 05 Preencher itens do Histórico da Doença Atual 06 Preencher itens da História Médica Pregressa. 07 Preencher itens do Atendimento Cirúrgico. 08 Preencher itens do Resultado de Exame. 09 Associar as doenças relacionadas ao atendimento. 10 Gravar as alterações. Cenário Alternativo: Não se aplica. Pré-Condição: Deve existir um agendamento prévio do paciente. Pós-Condição: O sistema deverá ser capaz de emitir prontuário do atendimento e/ou receita e/ou atestado médico. Fluxo de Exceção: Não se aplica. <<Fazer a descrição para os demais Casos de Uso>> 5.3 REQF002 EMITIR RELATÓRIO DE FLUXO DE CAIXA Objetivo:... Ator principal:... Ator secundário:... Cenário Principal:... Cenário Alternativo:... Pré-Condição:... Pós-Condição:... Fluxo de Exceção:... 5.4 REQF003 AGENDAR CONSULTA <<... >> 8
6 REQUISITOS NÃO FUNCIONAIS <<São os requisitos relativos a: desempenho, segurança, usabilidade, confiabilidade e distribuição. Deve-se ainda mencionar os requisitos de hardware e software para o desenvolvimento e execução do projeto. VEJA O EXEMPLO:.>> 6.1 - USABILIDADE <<Requisitos não funcionais relativos à distribuição dos dados e dos arquivos de chamadas do sistema (módulo executável)>> Exemplos: REQNF001: O sistema deverá ser capaz de funcionar nos navegadores Internet Explorer e Firefox. REQNF002: O sistema deverá possibilitar o uso de teclas de atalho para as principais opções. REQNF003: O Sistema deverá apresentar o recurso "look and feel", no mínimo para as interfaces Linux, Motif e Windows. 6.2 - DESEMPENHO <<Requisitos não funcionais relativos ao desempenho do sistema, como por exemplo tempo de resposta da abertura de telas do sistema, tempo necessário para emissão de um relatório de fatura>> Exemplos: REQNF004: Todas as telas do sistema não deverão demorar mais que 5 (cinco) segundos para abertura. REQNF005: O banco de dados relativo às informações gerenciais deve ser atualizado em tempo real. 6.3 SOFTWARE E HARDWARE <<Requisitos não funcionais relativos ao software e hardware usados para as operações de desenvolvimento ou execução do sistema>> REQNF006: Deverá ser adotado como linguagem de desenvolvimento principal a linguagem JAVA, com aplicação das diretivas orientadas a objetos. Deverão ser 9
abordados durante a modelagem das classes do sistema os principais padrões de projetos, em cada situação específica, como por exemplo: Strategy, Observer, Singleton, Decorator e Factory Method. 6.4 - SEGURANÇA <<Requisitos não funcionais relativos à integridade e privacidade dos dados armazenados pelo sistema>> REQNF007: O sistema deverá restringir o acesso às informações financeiras relativas ao grupo. REQNF008: Somente usuários autorizados com perfil Gerência poderão acessar o módulo de contas de usuário e definição dos parâmetros globais do sistema. 6.4 - CONFIABILIDADE <<Requisitos não funcionais relativos à freqüência de ocorrência de falhas do sistema e à capacidade de recuperação dessas falhas pelo próprio sistema>> REQNF009: O tempo médio entre falhas (MTBF) para as operações referentes ao relatórios que necessitam de processamento intensivo não poderá exceder a NN meses (ou NN dias ou NN anos). REQNF010: A exatidão das informações numéricas referentes aos resultados dos exames deverão possuir a precisão de 3 dígitos decimais. 6.5 - DISTRIBUIÇÃO <<Requisitos não funcionais relativos à distribuição dos dados e dos arquivos de chamadas do sistema (módulo executável)>> REQNF011: O sistema deverá ser acessado no atendimento (marcação), consultório, administração e disponibilizado na WEB. Os dados deverão ser igualmente distribuídos em cada um desses setores e acessados mediante o perfil de cada usuário. 10
7 - INTERFACE SUGERIDA (IHM) - PROTOTIPAÇÃO <<O desenho de uma interface parcialmente funcional para o sistema, é muito importante à medida que auxilia na validação dos requisitos funcionais. O protótipo pode ou não ser utilizado na continuação do desenvolvimento, isso dependerá da linguagem de programação usada e de uma metodologia bem definida de modo a permitir uma migração natural do protótipo para versão final.>> 11