Documento de Especificação de Objetivos

28/06/2019 Documento de Especificação de Objetivos e Requisitos (EOR) · DroidFoundry/DroidMetronome Wiki · GitHub
Document your code Dismiss
Every project on GitHub comes with a version-controlled wiki to give your documentation the high
level of care it deserves. It’s easy to create well-maintained, Markdown or rich text documentation
alongside your code.
Sign up for free
See pricing for teams and enterprises
Documento de Especificação de Objetivos e

Requisitos (EOR)
Jump to bottom
Julianny edited this page on 9 Jun 2015 · 17 revisions
DroidMetronome
Índice Analítico
i. Introdução
1.1 Objetivos
1.2 Público Alvo
1.3 Organização do documento
1.4 Definição de Siglas e Nomenclaturas
ii. Descrição do problema e do sistema
2.1 Identificação e missão do Sistema
2.2 Domínio do problema e contexto de sua aplicação
2.3 Descrição dos interessados do sistema
2.4 Levantamento e Avaliação dos Requisitos
iii. Requisitos e restrições não funcionais
3.1 Requisitos e Restrições de Usabilidade (RUS)
3.2 Requisitos e Restrições de Interface Homem-Computador (RHIC)
3.3 Requisitos e Restrições de Interface Externa (RIEX)
3.4 Requisitos e Restrições de Plataforma de Hardware (RPHW)
3.5 Requisitos e Restrições de Plataforma de Software (RPSW)
3.6 Requisitos e Restrições de Desempenho (RDES)
https://github.com/DroidFoundry/DroidMetronome/wiki/Documento de Especificação de Objetivos e Requisitos (EOR) 1/17
3.7 Requisitos e restrições de disponibilidade (RDIS)

3.8 Requisitos e Restrições de Segurança (RSEG)
3.9 Requisitos e Restrições de Manutenibilidade (RMAN)
3.10 Requisitos e Restrições de Documentação (RDOC)
iv. Casos de Uso e Requisitos Funcionais
4.1 Diagramas de Caso de Uso e Lista de casos de uso
4.2 Descrição de Casos de Uso
v. Requisitos Futuros (RFUT)
vi. Referências cruzadas complementares
vii. Aprovação Formal
viii. Bibliografia
1. Introdução
Este documento se refere à documentação realizada do processo de gerenciamento de

requisitos do sistema “DroidMetronome”. Visando estar realizando a especificação e
detalhamento dos requisitos coletados na atividade de elicitação do processo de gerência de
requisitos.
1.1 Objetivos
Este documento tem os seguintes objetivos:
Definir os interessados no sistema e as suas necessidades que devem ser satisfeitas pelo sistema
a ser desenvolvido;
Derivar os casos de uso e requisitos do sistema de forma a orientar a equipe de que será
responsável pelo seu desenvolvimento;
Estabelecer um contrato para negociação e concordância entre todos os interessados;
Reduzir retrabalho com projeto, codificação e teste através da especificação detalhada dos
requisitos;
Prover uma base para avaliação de prazos e custos de desenvolvimento;
Facilitar a transferência dos produtos do desenvolvimento para novos usuários, novos clientes,
novos ambientes operacionais e novas equipes de desenvolvimento e manutenção;
Prover uma base para a evolução futura do sistema a partir de uma versão aprovada (linha de
base) deste documento.
1.2 Público Alvo

O público-alvo deste documento são:
Engenheiros responsáveis pela coordenação deste projeto, podendo estes serem engenheiros de
requisitos, engenheiros de projeto, e demais engenheiros envolvidos;
Desenvolvedores e programadores envolvidos no projeto;
Usuários finais do projeto;
Possíveis futuros novos envolvidos que necessitarão compreender o sistema e suas

funcionalidades;
Demais envolvidos no projeto;
1.3 Organização do documento

Inicialmente é realizado uma breve introdução a respeito deste documento, sua função, à quem
é destinado e aos interessados que terão acesso a ele. Em seguida é gerado uma descrição do
problema e do sistema, de forma a analisar o problema a ser resolvido, a descrição dos
interessados no sistema e como está a situação atual. Logo após são apresentados os casos de
uso do sistema somado aos requisitos funcionais deste. Em seguida são apresentados os
requisitos e as restrições não funcionais do sistema. Após os requisitos do sistema, é feito uma
análise dos requisitos futuros do software. Para concluir, é realizado uma aprovação formal deste
documento pela empresa desenvolvedora deste sistema.
1.4 Definição de Siglas e Nomenclaturas

Isócrono: De duração igual;
EOR: Documento de especificações de objetivos e requisitos;
BPM: Métrica utilizada para quantificar a velocidade dos batimentos do metrônomo, sendo este
medido em x batidas por minuto.
Modo LED: Modo onde cada batimento do sistema liga e desliga a lanterna do dispositivo;
Modo vibratório: Modo onde cada batimento do sistema faz o do dispositivo vibrar;
Modo Auto-Lock: Modo onde o aparelho fica incapacitado debloquear a tela enquanto o
aplicativo estiver acionado;
Figura rítmica: As figuras rítmicas, ou figuras musicais são símbolos usados para representar uma
duração sonora que terão uma proporção na duração entre elas. As figuras rítmicas são: breve (8
tempos), semibreve (4 tempos), mínima (2 tempos), semimínima (1 tempo), colcheia (1/2 tempo),
semicolcheia (1/4 tempo), fusa (1/8 tempo), semifusa (1/16 tempo) e quartifusa (1/32 tempo);

Compasso: O compasso é uma forma de dividir quantitativamente em grupos os sons de uma

composição musical, com base em pulsos e repousos. Alguns exemplos de compassos são o 4/4
(o mais utilizado), ¾, 12/8 e outros.
2. Descrição do problema e do sistema
2.1 Identificação e missão do Sistema

Consiste em um sistema mobile para a plataforma especifica Android, ou seja, um aplicativo que
funciona como um relógio que irá produzir pulsos de durações regulares e exatas, conforme
parâmetros de velocidade dinâmica estabelecida pelos usuários. Sendo estes usuários cantores,
compositores, maestros, arranjadores e instrumentistas para determinar a velocidade de uma
música ou parte dela, a ser seguida por todos que devem executá-la.
2.2 Domínio do problema e contexto de sua aplicação

Quando um musico está preocupado com a parte técnica da execução, muitas vezes não
consegue manter as constâncias das pulsações, ou seja, os tempos que interpreta não são
isócronos. O uso deste sistema chamado DroidMetronome auxilia os estudantes e profissionais a
vencer tais dificuldades, mantendo o compasso correto. Isso também ajuda o musico a manter
concentração independente das distrações externas. Para baixistas e bateristas em particular é
importante manter a pulsação correta para mantê-los na linha com o restante do arranjo. O
DroidMetronome é extremamente importante para gravações de músicas, samplers, shows com
playback ou grooves eletrônicos.
2.3 Descrição dos interessados do sistema
Interessado(s) Descrição
O gerente de requisitos deve desenvolver este EOR buscando uma

Gerente de
melhor coerência e detalhamento deste para o compreendimento de
requisitos
todos os interessados e rastreamentos dos requisitos aqui levantados.
Com base neste EOR, será feito a compreensão dos requisitos e

Arquiteto de
restrições para tomadas de decisões na fase de design e construção do
Software
sistema.
Gerente de
Para definição do plano de projeto e estimativas de recurso.
Projetos
Os desenvolvedores se utilizam do EOR para compreender, através do

Desenvolvedores detalhamento dos requisitos, qual solução que deve ser tomada em
forma de código para atender tais requisitos.

Interessado(s) Descrição
Através deste EOR o gestor estará medindo a conformidade entre as

Gestor da
necessidades do sistema e o processo adotada para o solucionamento
Qualidade
das mesmas.
Verificador e Tais interessados, podendo ser distintos um do outro, buscarão validar

Validador este EOR juntamente com a qualidade de processo e produto.
2.4 Levantamento e Avaliação dos Requisitos

O Product Owner foi o responsável pelo levantamento dos requisitos, e o gerente de requisitos
responsavel por especificar e alterar este documento. Tal levantamento foi feito e documentado
na ata de reunião para aprovação do EOR, em que toda a equipe estava presente, garantindo
que os requisitos estivessem de acordo com a necessidade do fornecedor destes. Como
resultado deste levantamento e definição de requisitos, ao final deste documento na seção 7
consta a aprovação formal para os requisitos presentes neste documento, e os critérios para
análise dos requisitos. O monitoramento dos requisitos serão registrados via Relatório de
Monitoramento da Gerência de Projetos e este documento será revisado a cada sprint, podendo
ser alterado caso haja justificativa no relatório.
3. Requisitos e restrições não funcionais
CSU1- Executar metrônomo
CSU2- Reproduzir compasso
CSU3- Definir compasso
CSU4- Definir velocidade
CSU5- Definir som
CSU6- Definir Timer
CSU7- Escolher Figura Rítmica
CSU8- Abrir Configurações
CSU9- Visualizar Informações
CSU10- Definir Modo Vibratório
CSU11- Definir Modo LED
CSU12- Definir Modo Auto-Lock

CSU13- Integrar com Redes Sociais
3.1 Requisitos e Restrições de Usabilidade (RUS)
Caso
Ref. Descrição
de Uso
O usuário pode definir a velocidade do metrônomo dentro de um

RUS1 CSU4
intervalo de 1 a 300 bpms.
O timer de funcionamento do metrônomo pode estar dentro de 1 a 15

RUS2 CSU6
minutos.
CSU5,
Os sons das batidas, vibrações e luzes LED podem ocorrer individuais ou
RUS3 CSU10,
simultaneamente.
CS11
O numerador do compasso não pode ser maior que 16 e o

RUS4 denominador do compasso só pode ser um número exponencial de 2 CSU3
(como 1, 2, 4, 8, 16...) e não pode ser maior que 32
O sistema deve inicializar com valores padrões de compasso 4/4 e

RUS5 CSU1
velocidade 120 bpms e um som padrão.
O sistema deve inicializar com a Semimínima como figura rítmica

RUS6 CSU1
padrão.
A figura rítmica pode possuir os valores de 4 tempos (semibreve), 2

RUS7 tempos (mínimia), 1 tempo (semínimia), 1/2 tempo (colcheia) ou 1/4 CSU1
(semicolcheia).
3.2 Requisitos e Restrições de Interface Homem-Computador (RHIC)
Caso de
Ref. Descrição
Uso
Não é aceito nenhuma entrada que contenha caracteres especiais,

não possui suporte para entradas via teclado. As entradas que
RIHC1 Todos.
precisam ser fornecidas serão inseridas através de parâmetros pré-
definidos.
Deve estar visível na tela principal do sistema a velocidade do CSU1,

RIHC2
compasso e qual compasso está sendo utilizado. CSU3,CSU4
RIHC3 Deve ser utilizado “Google Material Design” para a interface. Todos
3.3 Requisitos e Restrições de Interface Externa (RIEX)

Caso
Ref. Descrição de
Uso
O software do sistema deve ser integrado com as redes sociais e publicar

RIEX1 (apenas quando emitido o comando pelo usuário) nelas a utilização do CSU13
sistema pelo usuário.
3.4 Requisitos e Restrições de Plataforma de Hardware (RPHW)
Ref. Descrição Caso de Uso
RPHW1 O aparelho deverá ter um processador acima de 1 ghz. Todos
3.5 Requisitos e Restrições de Plataforma de Software (RPSW)
Caso de
Ref. Descrição
Uso
O aparelho deve ter o sistema operacional 4.0 (Kit Kat) ou

RPSW1 Todos
superior
3.6 Requisitos e Restrições de Desempenho (RDES)
Caso de
Ref. Descrição
Uso
RDES1 O sistema não pode travar/encerrar o processo com frequência. Todos
Exceção
O compasso deve ser preciso e tocado aproximadamente
RDES2 do
simultâneo, não podendo ficar fora do ritmo do som do compasso.
compasso.
3.7 Requisitos e restrições de disponibilidade (RDIS).
RDIS1 O aplicativo deve inicializar por completo em até 3 segundos. CS1
3.8 Requisitos e Restrições de Segurança (RSEG)
Caso de
Ref. Descrição
Uso

Caso de
Ref. Descrição
Uso
Ao se conectar com as redes sociais e for ser feita alguma publicação,

RSEG1 CSU13
sempre pedir permissão.
RSEG2 Pedir permissão apenas para postar no mural. CSU13
RSEG3 Não invadir dados de aplicações que estão integradas ao metrônomo. CSU13
RSEG4 Não acessar as redes sociais sem a devida autorização. CSU13
RSEG5 Não compartilhar dados pessoais do usuário com as redes integradas. CSU13
3.9 Requisitos e Restrições de Manutenibilidade (RMAN)
Caso de
Ref. Descrição
Uso
Será utilizado a ferramenta Javadoc para padronizar e facilitar o

RMAN1 Todos
entendimento do código-fonte
3.10 Requisitos e Restrições de Documentação (RDOC)
RDOC1 Devem ser lançadas as notas de release a cada nova baseline. Não se aplica
4. Casos de Uso e Requisitos Funcionais
4.1 Diagramas de Caso de Uso e Lista de casos de uso
Cor Descrição
Amarela função primária do sistema de inicialização
Cinza primeira iteração do SCRUM
Azul segunda iteração do SCRUM
Vermelha primeira iteração do PMBOK
Verde segunda iteração do PMBOK
4.2 Descrição de Casos de Uso

CSU1- Executar Metrônomo
Ator(es): Usuário
Descrição: Neste caso de uso, o usuário inicializa o sistema DroidMetronome
Requisitos Funcionais:
Ref. Descrição Categoria Prioridade
RFUN Possibilitar ao usuário inicializar o sistema para sua

Evidente Alta
1.1 utilização.
CSU2- Reproduzir compasso
Ator(es): Usuário
Descrição: Neste caso de uso, inicia-se as batidas do metrônomo com as configurações

selecionadas pelo usuário.
RFUN Quando as configurações do metrônomo são

Evidente Alta
2.1 definidas, o usuário inicia as batidas.
CSU3- Definir compasso
Ator(es): Usuário
Descrição: Neste caso de uso, o usuário define a divisão quantitativa de pulsos e

repousos em uma composição musical.
RFUN Possibilitar ao usuário definir os padrões de pulsos e

Evidente Alta
3.1 repousos.
CSU4- Definir velocidade
Ator(es): Usuário
Descrição: Este caso de uso ocorre quando o usuário precisa modificar a velocidade dos
batimentos do metrônomo, sendo estes medidos em BPM (batidas por minuto).
RFUN Possibilitar ao usuário modificar a velocidade com que

Evidente Alta
4.1 as batidas ocorrem antes de estas serem iniciadas.
RFUN O usuário pausa os batimentos para regular o

Oculta Média
4.2 intervalo das batidas
CSU5- Definir som
Ator(es): Usuário
Descrição: O usuário tem a possibilidade de selecionar alguns sons pré-definidos. Estes

sons estarão já no “.apk”, de forma que o usuário possa selecionar o que mais lhe
agradar.
Possibilitar ao usuário selecionar uma melodia de

RFUN
batida para tocar em um loop na velocidade Evidente Alta
5.1
selecionada.
CSU6- Definir timer
Ator(es): Usuário
Descrição: O usuário tem a possibilidade de definir um tempo de duração das batidas.
RFUN Possibilitar que o usuário defina o tempo de duração

Evidente Média
6.1 das batidas, sendo este medido em minutos.
RFUN O usuário pode optar por pausar os batimentos antes

Evidente Média
6.2 do tempo pré-determinado.
CSU7- Escolher figura rítmica

Ator(es): Usuário
Descrição: A figura rítmica é uma parte fundamental para o funcionamento de um

metrônomo, sendo este uma subdivisão do compasso.
RFUN O usuário tem a opção de selecionar uma figura

Evidente Alta
7.1 rítmica para definir o compasso.
CSU8- Abrir Configurações
Ator(es): Usuário
Descrição: As configurações mais avançadas do sistema estão agrupadas nas configurações

do sistema. Estas configurações são visualizar informações, definir os modos
vibratórios, LED, auto-lock e integrar com as redes sociais.
RFUN O usuário abre a aba das configurações do sistema

Evidente Média
8.1 para personalizar mais seu uso.
CSU9- Visualizar informações
Ator(es): Usuário
Descrição: Dentro das configurações será disponibilizado para o usuário algumas

informações a respeito do sistema “DroidMetronome”, sendo estas descricao do app,
numero da versao, autores do app e homepage do app.
RFUN O usuário tem a possibilidade de consultar as

Evidente Média
9.1 informações a respeito do sistema “DroidMetronome”.
CSU10- Definir modo vibratório
Ator(es): Usuário

Descrição: O sistema contará com a possibilidade de além dos sons das batidas, o
aparelho poderá vibrar de forma a acompanhar os batimentos.
RFUN Possibilitar que o usuário ative o modo vibratório,

Evidente Baixa
10.1 onde o aparelho vibrará a cada batimento.
CSU11- Definir modo LED
Ator(es): Usuário
Descrição: Descrição: O sistema contará com a possibilidade de além dos sons das
batidas e das vibrações do aparelho, o aparelho poderá acender e desligar a luz LED do
aparelho de forma a acompanhar os batimentos.
Possibilitar que o usuário ative o modo LED, onde o

RFUN
aparelho acenderá e deligará a luz LED do aparelho a Evidente Baixa
11.1
cada batimento.
CSU12- Definir modo Auto-Lock
Ator(es): Usuário
Descrição: Durante a reprodução do aplicativo, o usuário tem a opção de bloquear o

aplicativo para que a tela não seja bloqueada.
O usuário tem a possibilidade de ativar e desativar o

RFUN
modo Auto-Lock, no qual impede que o sistema entre Evidente Média
12.1
em modo de descanso.
CSU13- Integrar com redes sociais
Ator(es): Usuário
Descrição: O usuário tem a possibilidade de divulgar que está usando o sistema

“DroidMetronome” para as redes sociais como Twitter, Facebook, Whattsapp entre outros.
RFUN O usuário pode compartilhar nas redes sociais que

Evidente Média
13.1 está utilizando o sistema “DroidMetronome”.
5. Requisitos Futuros (RFUT)
Este espaço é reservado para o surgimento de futuros requisitos.
6. Referências cruzadas complementares
Matriz de rastreabilidade
Rastreabilidade entre casos de uso e código-fonte
A rastreabilidade bidirecional entre os casos de uso e o código-fonte estão descritos nos

comentários Javadoc no código-fonte, disponível no repositório GitHub no seguinte LINK. Para
acessar o conteúdo do código-fonte é necessário ter a IDE "AndroidStudio", definida no Plano
de Gerência de Configuração disponível no seguinte LINK.
7. Aprovação Formal
Por meio deste documento, confirmo que os requisitos aqui presentes abordam todas as áreas
do sistema a ser desenvolvido e de requisitos futuros (sejam elas melhorias ou novas
funcionalidades), de forma a desenvolver um software com qualidade e segurança. Confirmo
também que este documento aborda todos os requisitos e funcionalidades de forma correta e
clara ao que foi solicitado e ao que foi dito e pedido nas entrevistas, etnografias e questionários.
Confirmo também que não há requisitos extras neste documento, todos os requisitos aqui
citados foram requeridos e atendem à alguma funcionalidade necessária.
![aprovação eor]
(https://github.com/gabrielaimeeg/DroidMetronome/blob/master/Projeto/anexos/registros de
aprovação/DroidMetronome_Aprovação do EOR.jpg)

8. Bibliografia
[1] Ronaldo Lopes de Oliveira, EOR – Modelo de Documento de Especificação de Objetivos e

Requisitos de Software, Versão 2.0, abril de 2014. Meta-Modelo usado como guia para definição
do formato e conteúdo deste documento.
Pages 93
Home
Gerência de Projeto
Planejamento
Plano de Projeto (Scrum)
Procedimentos
Relatório de Monitoramento
Relatório de Monitoramento 2
Gerência de Configuração
Planejamento
Plano de Gerência de Configuração
Procedimentos
Auditoria de Configuração 01 (Scrum Sprint 1)
Engenharia de Requisitos e Arquitetura
Planejamento
Documento de Especificação de Objetivos e Requisitos (EOR)
Documento de Arquitetura de Software (DAS)

Procedimentos
Verificação e Validação (V&V)
Planejamento
Plano de Verificação e Validação
Cronograma de atividades Ver e Val (Sprint 3)
Procedimentos
EOR
Documento de procedimentos (EOR 1)
Relatório de Resultados (EOR 1)

Casos de Uso
Documento de procedimentos (Casos de uso)
Relatório de Resultados (Casos de Uso)
Documento de procedimentos (Casos de uso 2)
Relatório de Resultados (Casos de Uso 2)
Documento de procedimentos (Casos de uso 3)
Relatório de Resultados (Casos de Uso 3)
Documento de Arquitetura
Documento de procedimentos (DAS)
Relatório de Resultados (DAS)
Documento de procedimentos (DAS 2)
Relatório de Resultados (DAS 2)
Documento de procedimentos (DAS 3)
Relatório de Resultados (DAS 3)
Diagrama de componentes
Documento de procedimentos (Diagrama de componentes)
Relatório de Resultados (Diagrama de Componentes)
Documento de procedimentos (Diagrama de Componentes 2)
Relatório de Resultados (Diagrama de Componentes 2)
Documento de procedimentos (Diagrama de Componentes 3)
Relatório de Resultados (Diagrama de Componentes 3)
Diagrama de classes
Documento de Procedimentos (Diagrama de Classes)
Relatório de Resultados (Diagrama de Classes)
Documento de Procedimentos (Diagrama de Classes 2)
Relatório de Resultados (Diagrama de Classes 2)
Documento de Procedimentos (Diagrama de Classes 3)
Relatório de Resultados (Diagrama de Classes 3)
Código fonte
Documento de Procedimentos (Código fonte)
Relatório de Resultados (Código fonte)
Documento de Procedimentos (Código fonte 3)
Relatório de Resultados (Código fonte 3)
Manutenção
Planejamento
Plano de Manutenção
Garantia da Qualidade
Planejamento
Plano de Garantia da Qualidade
Procedimentos
Relatório de Avaliação (Gerência de Projeto)
Relação de não conformidades (Gerência de Projeto)
Relação de não conformidades (Gerência de Projeto)
Relatório de Avaliação (Gerência de Configuração)
Relação de não conformidades (Gerência de Configuração)
Relatório de Avaliação (Verificação & Validação)
Relação de não conformidades (Verificação & Validação)
Relatório de Avaliação (Plano de Manutenção)
[Relação de não conformidades (Plano de Manutenção)](Relação de não conformidades (Plano de
Manutenção))
Templates
Gerência de Projeto
[TEMPLATE Plano de Projeto (SCRUM)](TEMPLATE Plano de Projeto (SCRUM))
[TEMPLATE Relatório de Monitoramento](TEMPLATE Relatório de Monitoramento)
[TEMPLATE Agenda de Reunião](TEMPLATE Agenda de Reunião)
[TEMPLATE Ata de Reunião](TEMPLATE Ata de Reunião)
Gerência de Configuração
[TEMPLATE Plano de Gerenciamento de Configuração](TEMPLATE Plano de Gerenciamento de
Configuração)
[TEMPLATE Auditoria de Configuração](TEMPLATE Auditoria de Configuração)
Engenharia de Requisitos e Arquitetura
[TEMPLATE Documento de Arquitetura de Software](TEMPLATE Documento de Arquitetura de Software)
[TEMPLATE Documento de Especificação de Objetivos e Requisitos (EOR)](TEMPLATE Documento de
Especificação de Objetivos e Requisitos (EOR))
Verificação e Validação (V&V)
[TEMPLATE Plano de Verificação e Validação](TEMPLATE Plano de Verificação e Validação)
[TEMPLATE Documento de Procedimentos](TEMPLATE Documento de Procedimentos)
[TEMPLATE Relatório de Resultados](TEMPLATE Relatório de Resultados)
Manutenção
[TEMPLATE Plano de Manutenção](TEMPLATE Plano de Manutenção)
[TEMPLATE Documento de Solicitação de Mudança](TEMPLATE Documento de Solicitação de Mudança)
[TEMPLATE Documento de Análise de Viabilidade e Riscos](TEMPLATE Documento de Análise de
Viabilidade e Riscos)
[TEMPLATE Documento de Controle e Correção](TEMPLATE Documento de Controle e Correção)
[TEMPLATE Notas de Release](TEMPLATE Notas de Release)
[TEMPLATE Documento de Migração](TEMPLATE Documento de Migração)
Garantia da Qualidade
[TEMPLATE Plano de Garantia da Qualidade](TEMPLATE Plano de Garantia da Qualidade)
[TEMPLATE Relatório de avaliação](TEMPLATE Relatório de avaliação)
[TEMPLATE Relação de não conformidades](TEMPLATE Relação de não conformidades)
Clone this wiki locally
https://github.com/DroidFoundry/DroidMetronome.wiki.git


Documento de Especificação de Objetivos

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Documento de Especificação de Objetivos

Загружено:

Авторское право:

Доступные форматы

28/06/2019 Documento de Especificação de Objetivos e Requisitos (EOR) · DroidFoundry/DroidMetronome Wiki · GitHub

Document your code Dismiss

Sign up for free

See pricing for teams and enterprises

Documento de Especificação de Objetivos e

Julianny edited this page on 9 Jun 2015 · 17 revisions

3.7 Requisitos e restrições de disponibilidade (RDIS)

Este documento se refere à documentação realizada do processo de gerenciamento de

Estabelecer um contrato para negociação e concordância entre todos os interessados;

Prover uma base para avaliação de prazos e custos de desenvolvimento;

1.2 Público Alvo

O público-alvo deste documento são:

Desenvolvedores e programadores envolvidos no projeto;

Usuários finais do projeto;

Possíveis futuros novos envolvidos que necessitarão compreender o sistema e suas

Demais envolvidos no projeto;

1.3 Organização do documento

1.4 Definição de Siglas e Nomenclaturas

EOR: Documento de especificações de objetivos e requisitos;

https://github.com/DroidFoundry/DroidMetronome/wiki/Documento de Especificação de Objetivos e Requisitos (EOR) 3/17

Compasso: O compasso é uma forma de dividir quantitativamente em grupos os sons de uma

2. Descrição do problema e do sistema

2.1 Identificação e missão do Sistema

2.2 Domínio do problema e contexto de sua aplicação

2.3 Descrição dos interessados do sistema

O gerente de requisitos deve desenvolver este EOR buscando uma

Com base neste EOR, será feito a compreensão dos requisitos e

Os desenvolvedores se utilizam do EOR para compreender, através do

https://github.com/DroidFoundry/DroidMetronome/wiki/Documento de Especificação de Objetivos e Requisitos (EOR) 4/17

Através deste EOR o gestor estará medindo a conformidade entre as

Verificador e Tais interessados, podendo ser distintos um do outro, buscarão validar

2.4 Levantamento e Avaliação dos Requisitos

3. Requisitos e restrições não funcionais

CSU1- Executar metrônomo

CSU2- Reproduzir compasso

CSU3- Definir compasso

CSU4- Definir velocidade

CSU5- Definir som

CSU6- Definir Timer

CSU7- Escolher Figura Rítmica

CSU8- Abrir Configurações

CSU9- Visualizar Informações

CSU10- Definir Modo Vibratório

CSU11- Definir Modo LED

CSU12- Definir Modo Auto-Lock

https://github.com/DroidFoundry/DroidMetronome/wiki/Documento de Especificação de Objetivos e Requisitos (EOR) 5/17

CSU13- Integrar com Redes Sociais

3.1 Requisitos e Restrições de Usabilidade (RUS)

O usuário pode definir a velocidade do metrônomo dentro de um

O timer de funcionamento do metrônomo pode estar dentro de 1 a 15

O numerador do compasso não pode ser maior que 16 e o

O sistema deve inicializar com valores padrões de compasso 4/4 e

O sistema deve inicializar com a Semimínima como figura rítmica

A figura rítmica pode possuir os valores de 4 tempos (semibreve), 2

3.2 Requisitos e Restrições de Interface Homem-Computador (RHIC)

Não é aceito nenhuma entrada que contenha caracteres especiais,

Deve estar visível na tela principal do sistema a velocidade do CSU1,

3.3 Requisitos e Restrições de Interface Externa (RIEX)

O software do sistema deve ser integrado com as redes sociais e publicar

3.4 Requisitos e Restrições de Plataforma de Hardware (RPHW)

Ref. Descrição Caso de Uso

RPHW1 O aparelho deverá ter um processador acima de 1 ghz. Todos

3.5 Requisitos e Restrições de Plataforma de Software (RPSW)