diff --git a/docs/Analise/analise.md b/docs/Analise/analise.md new file mode 100644 index 0000000..389bf72 --- /dev/null +++ b/docs/Analise/analise.md @@ -0,0 +1,12 @@ +## Análise +A análise de requisitos é uma etapa fundamental no processo de desenvolvimento de software, que envolve a compreensão e especificação das necessidades e expectativas dos stakeholders (interessados) em relação ao sistema a ser desenvolvido. O objetivo é garantir que os requisitos do sistema sejam claros, completos, consistentes, verificáveis e, o mais importante, que atendam às necessidades dos usuários e dos negócios. + +Uma análise de requisitos bem conduzida reduz o risco de falhas no projeto, garante que o sistema final atenda às expectativas, e facilita a comunicação entre desenvolvedores, stakeholders e outros envolvidos no projeto. + +[Cenário](./Analise/cenario.md) + +[Léxico](./Analise/lexico.md) + +[Backlog](./Analise/backlog.md) + +[Argumentação](./Analise/argumentacao.md) diff --git a/docs/Analise/argumentacao.md b/docs/Analise/argumentacao.md new file mode 100644 index 0000000..e6ab6d7 --- /dev/null +++ b/docs/Analise/argumentacao.md @@ -0,0 +1,112 @@ +![Argumentação](../assets/Cenarios/Grafo.jpeg) + +# Análise + +## Identificando as Proposições: +Verifica-se que cada nó do grafo identifica as proposições (P1, P2, P3, P4). Elas representam os pontos de vista ou hipóteses que estão sendo discutidas. +Identificando as Interpretações e Conclusões: +Os nós em azul no grafo representam instâncias de proposições (i). +Os nós verdes representam interpretações (It). +Os nós vermelhos representam contradições (C) ou conflitos. +Os nós amarelos representam preferências (P). + +## Análise das Relações: +Verificando como as proposições (P1, P2, P3, P4) se relacionam com as interpretações e conclusões. +Como cada interpretação ou conclusão é formada com base nas proposições. + +### Complementaridade de Proposições: +- P1 e P2 podem ser complementares, ou seja, podem fornecer informações que se completam mutuamente. Por exemplo, uma proposição pode estabelecer uma ideia inicial, enquanto a outra pode fornecer uma justificativa ou evidência adicional para a ideia. +No grafo, a junção de P1 e P2 em um nó de interpretação (It(i(P1), i(P2))) sugere que, para entender completamente o argumento ou a situação em questão, é necessário considerar ambas as proposições em conjunto. + +- P3 e P4 parecem tratar de aspectos opostos de uma mesma decisão estratégica: uma decisão simplificaria a implementação (foco apenas no transporte público), enquanto a outra aumentaria a complexidade do sistema (integração com serviços de empresas privadas). +Essas proposições são complementares na medida em que oferecem dois lados da mesma moeda — o impacto da escolha entre focar somente em transporte público versus integrar serviços privados. Portanto, analisá-las juntas ajuda a entender o trade-off entre simplicidade e complexidade. + + +### Relação de Dependência: +- P1 e P2 podem ter uma relação de dependência lógica, onde o significado ou a validade de uma delas depende da outra. Por exemplo, P1 pode ser uma +condição ou requisito para P2, ou vice-versa. + +- A interpretação conjunta dessas proposições ajuda a entender como uma pode influenciar ou ser influenciada pela outra. +Existe uma relação de dependência lógica inversa entre P3 e P4. Se a proposição P3 ("focar apenas no transporte público") for verdadeira e escolhida como uma decisão estratégica, P4 ("integrar serviços de empresas privadas") naturalmente se torna menos relevante, pois esta integração não estaria nos planos. + +- Portanto, a interpretação conjunta permite ver que a escolha de uma proposição implica a exclusão ou diminuição da relevância da outra. + + +### Construção de um Argumento Mais Forte: +- Combinar P1 e P2 pode servir para construir um argumento mais forte, no qual a interpretação considera múltiplas perspectivas ou dados que reforçam a conclusão desejada. +- Por exemplo, se P1 sugere uma ação e P2 reforça o benefício dessa ação, juntar ambas em uma interpretação cria um argumento mais convincente. + +- Juntar P3 e P4 em uma interpretação permite que o decisor ou analista veja claramente os benefícios e desvantagens de cada opção estratégica. Se um argumento quer defender a simplificação da implementação, P3 e P4, juntos, fortalecem essa visão ao contrapor simplificação versus complexidade. +- Esta abordagem constrói um argumento claro sobre os prós e contras da estratégia de foco no transporte público versus a integração de serviços privados. + +### Necessidade de Coerência: +- No grafo, ao combinar P1 e P2 em um nó de interpretação, pode-se verificar se há consistência entre elas ou se geram um conflito que precisa ser resolvido. + +- P3 e P4 representam proposições que, se analisadas separadamente, podem parecer independentes. No entanto, ao serem interpretadas juntas, revelam um conflito de interesses ou uma tensão estratégica — entre simplificação e complexidade. É essencial analisar ambas juntas para determinar a coerência da estratégia geral. +- Por exemplo, se o objetivo do projeto for simplicidade e eficiência, P3 seria coerente, enquanto P4 indicaria uma direção conflitante. Juntas, ajudam a clarificar o caminho mais coerente a seguir. + + +## Verificando as Contradições e Preferências: + - As contradições (C1, C2) indicam pontos em que duas proposições ou interpretações se contradizem. +- As preferências (P1) indicam um julgamento ou escolha sobre qual proposição é mais válida ou preferível. + +### C1(i(P4,i(P2))) +#### Objetivos e Consequências Opostos: +- P2 sugere que integrar serviços de empresas privadas é uma decisão positiva porque "pode atrair mais usuários". Essa proposição foca no benefício potencial de aumentar a base de usuários do sistema. +- P4 aponta para um lado negativo da mesma decisão, afirmando que "aumentaria a complexidade do sistema". Ou seja, enfatiza o custo ou a desvantagem da integração de serviços privados. + +#### Conflito Entre Vantagem e Desvantagem: +- P2 e P4 entram em contradição porque apresentam um conflito direto entre uma vantagem (atrair mais usuários) e uma desvantagem (aumentar a complexidade do sistema). +- Se o foco do sistema é a simplicidade, então a integração de serviços privados (P2) não seria desejável devido à complexidade adicional mencionada em P4. Por outro lado, se o objetivo é aumentar a base de usuários, a complexidade adicional mencionada em P4 pode ser vista como um preço aceitável a pagar. + +#### Impacto na Decisão Estratégica: +- P2 pode levar a uma decisão estratégica de expandir o sistema para incluir serviços privados, o que implica que o sistema deve lidar com a complexidade extra (contradizendo P4). +- P4 sugere que a decisão de não integrar serviços privados deve ser considerada para evitar complicações e complexidades adicionais, o que se opõe à ideia defendida em P2 de que essa integração é positiva para atrair mais usuários + +#### Implicações Práticas de Implementação: +- Se P2 é verdade (integrar serviços privados atrai mais usuários), pode ser um argumento a favor de aceitar a complexidade mencionada em P4 como um "mal necessário". +- No entanto, se P4 é considerada uma limitação importante (a complexidade deve ser evitada), então P2 torna-se menos desejável ou até inaceitável, pois contraria a necessidade de manter o sistema simples. +Conclusão +- P2 e P4 são contradições porque representam objetivos conflitantes: uma visa maximizar o engajamento de usuários por meio da integração de serviços privados, enquanto a outra visa minimizar a complexidade do sistema ao evitar essa integração. Portanto, elas não podem ser satisfeitas simultaneamente sem comprometer o objetivo de uma ou da outra. + +### C2(P1, C1(i(P4), i(P2))) +#### Objetivos em Conflito: +- P1 sugere a expansão do sistema para incluir suporte a serviços adicionais (como carros por aplicativos externos e locais de bicicletas/patinetes compartilhados). Isso indica uma orientação para integrar mais serviços, o que pode implicar uma maior complexidade e uma abordagem de inclusão. +- C1 (que reflete a contradição entre P4 e P2) expressa que existe uma tensão entre a complexidade adicional e o potencial de atrair mais usuários através da integração de serviços privados. Portanto, C1 sugere que aumentar a integração (como proposto em P1) pode ser visto de duas maneiras: pode ser positivo para atrair mais usuários (como sugerido por P2), mas também pode adicionar complexidade ao sistema (como sugerido por P4). + +#### Impacto na Decisão Estratégica: +- Se P1 propõe que o Moovit deve suportar carros de aplicativos externos e serviços compartilhados, isso está alinhado com a proposição P2 (integrar mais serviços para atrair usuários). +- No entanto, isso contradiz P4 porque adicionar mais serviços como suporte a aplicativos externos ou locais de bicicletas/patinetes aumentaria, inevitavelmente, a complexidade do sistema, justamente o que P4 critica. + +#### Incompatibilidade de Implementação: +- P1 requer que o sistema do Moovit suporte e integre serviços adicionais (carros de aplicativos, bicicletas, patinetes), o que claramente adiciona novas camadas de complexidade, gestão e recursos. +- C1 expressa que, enquanto adicionar esses serviços (como sugerido em P1) pode ser vantajoso para atrair usuários (P2), ele também aumenta a complexidade (P4). Assim, ao adotar P1, o argumento de que a complexidade do sistema deveria ser evitada (P4) não pode ser mantido. + +#### Conclusão do Conflito: +- A contradição entre P1 e C1 surge porque P1 está diretamente alinhada com um dos lados do conflito representado por C1 (ou seja, a integração de mais serviços), mas contrária ao outro (a necessidade de evitar complexidade). +- Portanto, se P1 for adotada, ela favorece o lado do argumento que apoia a integração de serviços para atrair mais usuários (P2) e desconsidera a preocupação com a complexidade adicional (P4). Isso cria uma contradição com o argumento equilibrado representado por C1, que leva em conta tanto o benefício quanto a desvantagem da integração de serviços. + + +## Examinando os Fluxos de Argumentação: +Seguir os fluxos entre os nós do grafo para entender a sequência lógica do argumento (tabela abaixo). + +Por exemplo, veja como "It1(P1, P2)" se relaciona com "i(P2)" e "C1(i(P4), i(P2))". + + +### Tabela +| Proposição | Representação no Grafo | Satisfeito? | Observações | +| :-: | :-: | :-: | :-: | +| P1 | i(P1), It(i(P1), i(P2)) | X | Adequadamente representada na conjunção com P2. | +| P2 | i(P2), It(i(P1), i(P2)) | X | Representada na conjunção e na contradição. | +| P3 | i(P3), It(i(P3), i(P4)) | X | Representada na conjunção com P4. | +| P4 | i(P4), C1(i(P4), i(P2)) | X | Está representada na contradição com P2. | +| C1 | C1(i(P4), i(P2)) | X | Representa a contradição entre P4 e P2, conforme esperado. | +| C2 | C2/P1, C1(i(P4), i(P2)) | X | Adequadamente representada como contradição derivada de C1. | +| Conclusão | P1(i(P2), i(P4)) | X | A conclusão está consistente com as informações representadas. | + +| Autor| Versão |Data| Descrição | +|------|-----------------|-----|---------- | +|[Marcos Castilhos](https://github.com/Marcosatc147) | 1.0 |11/09/2024 | Inclusão da Análise de Argumentação| + + + diff --git a/docs/Analise/backlog.md b/docs/Analise/backlog.md new file mode 100644 index 0000000..ad18703 --- /dev/null +++ b/docs/Analise/backlog.md @@ -0,0 +1,135 @@ + + +## Critérios de Inspeção + +* Completude do Item do Backlog +Todos os itens do backlog estão devidamente documentados? +Há uma descrição clara e concisa para cada item, explicando o que precisa ser feito? +A funcionalidade desejada ou a história do usuário está compreensível? + + + + +* Prioridade dos Itens +Os itens mais importantes para o projeto estão no topo da lista do backlog? +A priorização reflete as necessidades do negócio ou do cliente? +A priorização está alinhada com os objetivos de curto e longo prazo? + + +* Estimativas e Tamanho +Todos os itens possuem uma estimativa de esforço, seja em pontos de história, horas, ou outra unidade? +As estimativas são realistas e foram discutidas com a equipe de desenvolvimento? + + +* Critérios de Aceitação +Cada item do backlog possui critérios de aceitação claramente definidos? +Os critérios de aceitação são mensuráveis e verificáveis? + + +* Clareza e Detalhamento +Os itens do backlog estão suficientemente detalhados para a equipe entender o trabalho a ser feito? +Há uma distinção clara entre tarefas menores e grandes funcionalidades que precisam ser decompostas em itens menores? + + +* Alinhamento com a Visão do Produto +Os itens do backlog estão alinhados com a visão do produto ou as metas do projeto? +Cada item contribui para o objetivo final do projeto? + + +* Revisão e Atualização +O backlog é revisado e atualizado regularmente com base no feedback do cliente e da equipe? +Há itens obsoletos ou desnecessários que precisam ser removidos? + + +* Definição de Pronto (DoR) +Os itens do backlog atendem à "Definição de Pronto" (DoR) acordada pela equipe, indicando que estão prontos para serem desenvolvidos? +Todos os requisitos, dependências e informações relevantes estão disponíveis? + + +* Dependências e Riscos +Os itens com dependências externas (outras equipes, terceiros, ferramentas) estão identificados no backlog? +Os riscos potenciais associados a cada item foram discutidos e documentados? + + +* Preparação para a Sprint +Os itens de alta prioridade estão prontos para serem puxados para a próxima sprint? +A equipe de desenvolvimento participou da discussão sobre os itens a serem trabalhados na próxima iteração? + +### Análise de Backlog + +## Primeira Tabela +| ID da US | Tipo | Prioridade | Completude da US | Critérios de Aceitação | Clareza e Detalhamento | Viabilidade Técnica | Alinhamento com Produto | Dependências | Definição de Pronto | Observações Gerais | +|----------|------|------------|------------------|------------------------|------------------------|---------------------|--------------------------|--------------|--------------------|--------------------| +| 1.1.1 | RF | Alta | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Nenhuma dependência. | +| 1.1.2 | RF | Alta | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | ( ) Sim (x) Não | (x) Sim ( ) Não | Verificar possíveis dependências. | +| 1.1.3 | RF | Alta | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Nenhuma dependência crítica. | +| 1.1.4 | RF | Média | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Dependências controladas. | +| 1.2.1 | RF | Média | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Completude aceitável. | +| 1.2.2 | RF | Alta | (x) Sim ( ) Não | ( ) Sim (x) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Necessário melhorar os critérios de aceitação. | +| 2.1.1 | RF | Alta | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | Revisão necessária. | +| 2.1.2 | RF | Alta | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | Requer mais detalhamento. | +| 2.2.1 | RF | Alta | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | Pendências importantes. | +| 2.2.2 | RF | Média | (x) Sim ( ) Não | ( ) Sim (x) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Critérios de aceitação precisam de ajustes. | +| 3.1.1 | RF | Alta | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | Requer maior revisão. | +| 3.1.2 | RF | Média | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | Requer maior revisão. | +| 3.2.1 | RF | Alta | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | Dependências críticas. | +| 3.2.2 | RF | Média | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | Requer maior revisão. | +| 4.1.1 | RF | Alta | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | Pendências não resolvidas. | +| 4.1.2 | RF | Média | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Completo. | +| 4.2.1 | RF | Alta | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Nenhuma dependência crítica. | +| 4.2.2 | RF | Média | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Nenhuma dependência crítica. | +| 5.1.1 | RF | Alta | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | Requer mais detalhamento. | +| 5.2.1 | RF | Média | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Completo. | +| 5.3.1 | RF | Alta | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | ( ) Sim (x) Não | Requer ajustes técnicos. | +| 7.1.1 | RF | Alta | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Nenhuma dependência crítica. | +| RNF01 | RNF | Alta | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Completo. | +| RNF02 | RNF | Alta | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Nenhuma pendência crítica. | +| RNF03 | RNF | Alta | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Nenhuma pendência crítica. | +| RNF04 | RNF | Média | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Nenhuma dependência crítica. | +| RNF05 | RNF | Alta | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | (x) Sim ( ) Não | Completo. | + + + + +## Segunda Tabela + +| ID da US | Tipo | Prioridade | Completude da US | Critérios de Aceitação | Clareza e Detalhamento | Viabilidade Técnica | Alinhamento com Produto | Dependências | Definição de Pronto | Observações Gerais | +|----------|------|------------|------------------|------------------------|------------------------|---------------------|--------------------------|--------------|--------------------|--------------------| +| 1.1.1 | RF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não | Nenhuma dependência.| +| 1.1.2 | RF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Nenhuma dependência.| +| 1.1.3 | RF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Nenhuma dependência.| +| 1.1.4 | RF | Média | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Nenhuma dependência| +| 1.2.1 | RF | Média | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | (x) Sim ( ) Não |Necessário uma atenção nos Critérios de Aceitação.| +| 1.2.2 | RF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Necessário uma melhoria na Viabilidade Técnica.| +| 2.1.1 | RF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( ) Sim (x) Não |Revisão necessária.| +| 2.1.2 | RF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | ( ) Sim (x) Não |Requer uma boa revisão.| +| 2.2.1 | RF | Alta | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( ) Sim ( x ) Não | ( ) Sim ( x ) Não | ( ) Sim (x) Não |Requer uma revisão geral.| +| 2.2.2 | RF | Média | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Necessário ajustes.| +| 3.1.1 | RF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( ) Sim (x) Não |Verificar algumas dependências.| +| 3.1.2 | RF | Média | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( ) Sim ( x ) Não | ( ) Sim ( x ) Não | ( ) Sim (x) Não |Necessário ser melhor detalhado.| +| 3.2.1 | RF | Alta | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( ) Sim ( x ) Não | ( ) Sim ( x ) Não | ( ) Sim (x) Não |Requer uma revisão geral.| +| 3.2.2 | RF | Média | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( ) Sim ( x ) Não | ( ) Sim ( x ) Não | ( ) Sim (x) Não |Requer uma revisão geral.| +| 4.1.1 | RF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( ) Sim (x) Não |Verificar possíveis dependências.| +| 4.1.2 | RF | Média | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Nenhuma dependência.| +| 4.2.1 | RF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Nenhuma dependência.| +| 4.2.2 | RF | Média | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Necessário revisar Viabilidade Técnica.| +| 5.1.1 | RF | Alta | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( ) Sim (x) Não |Necessário verificar ajustes técnicos.| +| 5.2.1 | RF | Média | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Completo.| +| 5.3.1 | RF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( ) Sim (x) Não |Necessário verificar dependência.| +| 7.1.1 | RF | Alta | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | ( ) Sim ( x ) Não | ( ) Sim ( x ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Analisar Viabilidade Técnica.| +| RNF01 | RNF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Nenhuma pendência.| +| RNF02 | RNF | Média | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Nenhuma pendência.| +| RNF03 | RNF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Nenhuma pendência.| +| RNF04 | RNF | Média | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Nenhuma pendência.| +| RNF05 | RNF | Alta | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | ( x ) Sim ( ) Não | (x) Sim ( ) Não |Nenhuma pendência.| + +### Explicação +- Para requisitos funcionais (RF), as US com maior completude foram marcadas como "Sim". +- Dependências e critérios de aceitação para alguns itens ainda precisam ser melhorados. +- Requisitos não funcionais (RNF) estão bem detalhados, e a maioria está completa. + + +|Autor | Versão |Data| +|-------|-----------------|----| +|Márcio Henrique| 1ª |10/09/2024| +|[Pedro Paulo](https://github.com/Pedrin0030)|1ª |10/09/2024| \ No newline at end of file diff --git a/docs/Analise/cenario.md b/docs/Analise/cenario.md new file mode 100644 index 0000000..2eb0ad3 --- /dev/null +++ b/docs/Analise/cenario.md @@ -0,0 +1,225 @@ +# Análise dos Cenários +## Verificação: + +### 1. Identificação de Domínios Comuns +Os cenários apresentados estão relacionados ao domínio de transporte público e serviços associados, mais especificamente no contexto de uso do aplicativo Moovit. As funcionalidades descritas nos cenários incluem: + +- Consulta e Planejamento de Rotas: CN1, CN4, CN5, CN8. +- Interação com Outros Serviços de Mobilidade: CN2, CN4. +- Gerenciamento de Preferências e Informação: CN6, CN7, CN10, CN11. +- Assinaturas e Benefícios Premium: CN3, CN12. +- Relato e Atualização de Problemas: CN9, CN11. + +### 2. Reutilização de Domínios e Estruturas + +Ao verificar os requisitos, podemos identificar áreas onde os cenários compartilham funcionalidades ou informações que podem ser reutilizadas: + +#### a. Reutilização de Recursos Comuns: + +- `Conexão à internet, localização ativada, e o aplicativo Moovit instalado` são recursos comuns a quase todos os cenários. Em vez de repetir esses requisitos em cada cenário, eles poderiam ser definidos como requisitos globais ou pré-condições para o uso do sistema. +- `Interação com serviços externos` (como caronas pagas ou bicicletas compartilhadas em CN2 e CN4) pode ser encapsulada em uma funcionalidade genérica de integração com serviços de mobilidade, facilitando a adição de novos serviços no futuro. + +#### b. Reutilização de Ações e Episódios: + +- `Inserção de destino e apresentação de rotas:` A sequência de ações em CN1, CN4, CN5, e CN8 compartilha um fluxo comum de inserção de destino, cálculo de rota, e apresentação de resultados. Isso sugere que essa funcionalidade poderia ser centralizada e reutilizada em diferentes cenários. +- `Favoritar e salvar preferências`:` CN6 e CN12 têm funcionalidades relacionadas ao gerenciamento de preferências do usuário (favoritar linhas e assinar Moovit+). Essas ações poderiam ser abstraídas em um módulo comum de gerenciamento de preferências do usuário. + +#### c. Reutilização de Regras e Restrições: + +- `Atualização e precisão em tempo real:` A necessidade de informações atualizadas e precisas aparece repetidamente (CN1, CN2, CN5, CN7, CN8). Definir essa restrição como um requisito global para o sistema, ao invés de individualmente para cada cenário, ajudaria na consistência e clareza dos requisitos. +- `Manutenção de dados e verificação por Mooviters (CN11):` Esta funcionalidade poderia ser estendida e utilizada para validar dados em qualquer cenário onde a precisão das informações seja crítica. + +### 3. Aplicação de Reutilização no Design +No design de um sistema, essa análise de reutilização poderia resultar em: + +- `Módulos de serviços compartilhados:` Um módulo para gestão de integração de serviços externos (CN2, CN4), outro para cálculo e apresentação de rotas (CN1, CN4, CN5, CN8), e um para gerenciamento de preferências (CN6, CN12). +- `Modelagem de fluxos reutilizáveis:` Criar fluxos de uso que são reutilizados em múltiplos cenários, como o fluxo de inserção de destino e cálculo de rota. +- `Requisitos globais e pré-condições:` Estabelecer uma seção de requisitos globais no documento de requisitos, definindo pré-condições como "Conexão à internet" e "Localização ativada". + +### 4. Revisão de Cenários Específicos +Aplicando as observações acima, a seguir alguns exemplos de como cenários específicos poderiam ser ajustados para melhor reutilização: + +#### CN1 (Consulta de Rotas de Transporte Público) +- Recursos: Reduzir as especificações duplicadas, referindo-se ao requisito global de "Conexão à internet, localização ativada, Moovit instalado". +- Episódios: Clarificar que a "inserção de destino e apresentação de rotas" reutiliza o fluxo comum de cálculo de rotas definido em um módulo compartilhado. + +#### CN4 (Integração com Serviços de Carona Paga) +- Episódios: Incorporar a integração com serviços de mobilidade externa como um caso específico de um módulo de integração genérico, que pode ser reutilizado em outros cenários (como CN2). + +#### CN11 (Atualização de Informações de Transporte Público por um Mooviter) + +- Restrição: Destacar que a "precisão das informações em tempo real" também se aplica a outros cenários e que as regras de validação de dados por Mooviters podem ser reutilizadas onde relevante. + +## Validação + +### Cenário CN1: Consulta de Rotas de Transporte Público + +#### Pontos de Vista: +- **Usuário:** Deseja encontrar a rota mais eficiente. +- **Governo do Estado:** Deseja fornecer dados precisos e atualizados. +- **Operadora de Transporte Público:** Precisa garantir que as informações sejam precisas e atualizadas. +- **Desenvolvedor do Sistema:** Deve garantir a integração com os dados e uma interface amigável. + +#### Avaliação: +- **Usuário:** Cenário atende às expectativas, fornecendo uma rota eficiente. No entanto, o usuário pode ficar frustrado se os dados não estiverem atualizados. +- **Governo do Estado:** Cenário contribui para o objetivo de melhorar a experiência do transporte público, mas depende da qualidade dos dados. +- **Operadora de Transporte Público:** Cenário não detalha como garantir a precisão dos dados, o que pode ser um problema. +- **Desenvolvedor do Sistema:** Precisa de mais detalhes sobre como integrar e atualizar dados em tempo real. + +#### Sugestões: +- Adicionar detalhes sobre a atualização e validação dos dados. +- Incluir funcionalidades para o usuário verificar a atualização dos dados e reportar inconsistências. + +### Cenário CN2: Utilização de Serviço de Bicicletas Compartilhadas + +#### Pontos de Vista: +- **Usuário:** Quer saber a disponibilidade de bicicletas e como acessá-las. +- **Empresa de Bicicletas Compartilhadas:** Precisa garantir que os dados sobre a disponibilidade de bicicletas estejam corretos. +- **Desenvolvedor do Sistema:** Deve implementar a integração com o sistema de bicicletas e garantir a precisão das informações. + +#### Avaliação: +- **Usuário:** Cenário atende às necessidades de encontrar e usar bicicletas compartilhadas, mas precisa de atualização precisa sobre a disponibilidade. +- **Empresa de Bicicletas:** Cenário deve garantir a precisão das informações fornecidas para não gerar frustração no usuário. +- **Desenvolvedor:** Deve assegurar que a integração e a interface estejam funcionando corretamente e atualizem as informações em tempo real. + +#### Sugestões: +- Incluir detalhes sobre como o sistema lida com a atualização das informações sobre bicicletas. +- Adicionar um mecanismo de feedback para relatar problemas com a disponibilidade das bicicletas. + +### Cenário CN3: Uso de Benefícios Premium no Moovit + +#### Pontos de Vista: +- **Usuário:** Quer entender os benefícios do plano premium e pagar de forma segura. +- **Desenvolvedor do Sistema:** Deve garantir a integração segura com o sistema de pagamento e a funcionalidade do Moovit+. + +#### Avaliação: +- **Usuário:** Cenário aborda bem a compra e utilização do pacote premium, mas deve garantir que o processo de pagamento seja seguro. +- **Desenvolvedor:** Precisa garantir que o sistema de pagamento funcione sem falhas e que as funcionalidades premium estejam claramente descritas. + +#### Sugestões: +- Detalhar o processo de segurança do pagamento e como lidar com falhas no pagamento. + +### Cenário CN4: Integração com Serviços de Carona Paga + +#### Pontos de Vista: +- **Usuário:** Quer combinar transporte público com carona paga de forma eficiente. +- **Serviço de Carona Paga:** Deve garantir que a integração com o Moovit seja fluida e eficiente. +- **Desenvolvedor do Sistema:** Deve assegurar a integração técnica entre o Moovit e os serviços de carona paga. + +#### Avaliação: +- **Usuário:** Cenário aborda bem a combinação de transporte público e carona paga, mas deve garantir a integração eficiente e a disponibilidade dos serviços de carona. +- **Serviço de Carona Paga:** Deve garantir a disponibilidade e a integração com o Moovit. +- **Desenvolvedor:** Precisa assegurar que a integração funcione sem problemas e que os usuários possam facilmente utilizar ambos os serviços. + +#### Sugestões: +- Incluir detalhes sobre a integração com serviços de carona paga e como lidar com a indisponibilidade de carros. + +### Cenário CN5: Procura por uma Linha de Ônibus Específica + +#### Pontos de Vista: +- **Usuário:** Deseja encontrar informações sobre uma linha específica de ônibus. +- **Operadora de Transporte Público:** Precisa garantir que as informações estejam atualizadas. +- **Desenvolvedor do Sistema:** Deve implementar a funcionalidade de busca e garantir que as informações sejam precisas. + +#### Avaliação +- **Usuário:** Cenário atende bem a necessidade de encontrar informações sobre uma linha específica. +- **Operadora de Transporte Público:** Deve garantir que as informações sobre horários e paradas estejam sempre atualizadas. +- **Desenvolvedor:** Precisa assegurar que a funcionalidade de busca funcione corretamente e que as informações sejam precisas. + +#### Sugestões: +- Adicionar mecanismos para verificar a precisão dos horários e paradas e fornecer rotas alternativas em caso de alterações. + +### Cenário CN6: Usuário Favorita Linhas de Transporte para Acesso Rápido + +#### Pontos de Vista: +- **Usuário:** Quer acessar rapidamente suas linhas favoritas. +- **Desenvolvedor do Sistema:** Deve garantir que a funcionalidade de favoritos seja fácil de usar e atualize as informações em tempo real. + +#### Avaliação: +- **Usuário:** Cenário atende bem à necessidade de acessar rapidamente linhas favoritas. +- **Desenvolvedor:** Precisa garantir que a funcionalidade de favoritos esteja bem implementada e que as informações sejam atualizadas em tempo real. + +#### Sugestões: +- Incluir detalhes sobre como o sistema lida com mudanças nas linhas favoritas e atualiza as informações. + +### Cenário CN7: Verificação da Proximidade de um Ônibus + +#### Pontos de Vista: +- **Usuário:** Quer saber a localização e o tempo de chegada do ônibus. +- **Desenvolvedor do Sistema:** Deve garantir que a localização e o tempo de chegada sejam precisos e atualizados. + +#### Avaliação: +- **Usuário:** Cenário atende bem à necessidade de verificar a proximidade do ônibus, mas deve garantir a precisão dos dados. +- **Desenvolvedor:** Precisa assegurar que a funcionalidade de rastreamento e a estimativa de chegada estejam corretas e atualizadas. + +#### Sugestões: +- Adicionar mecanismos para lidar com falhas na obtenção da localização do ônibus e sugerir opções alternativas. + +### Cenário CN8: Planejamento de Viagem com Múltiplos Modos de Transporte + +#### Pontos de Vista: +- **Usuário:** Quer planejar uma viagem usando diferentes modos de transporte. +- **Desenvolvedor do Sistema:** Deve garantir que o planejamento multimodal funcione corretamente e forneça informações precisas. + +#### Avaliação: +- **Usuário:** Cenário atende bem à necessidade de planejamento multimodal, mas deve garantir a precisão das informações sobre os diferentes modos de transporte. +- **Desenvolvedor:** Precisa assegurar que a funcionalidade de planejamento multimodal seja precisa e eficiente. + +#### Sugestões: +- Detalhar como o sistema lida com a indisponibilidade de modos de transporte e sugere rotas alternativas. + +### Cenário CN9: Usuário Reporta um Problema no Transporte Público + +#### Pontos de Vista: +- **Usuário:** Quer relatar problemas encontrados durante o uso do transporte público. +- **Desenvolvedor do Sistema:** Deve garantir que a funcionalidade de reporte de problemas esteja funcionando e seja eficaz. + +#### Avaliação: +- **Usuário:** Cenário atende bem à necessidade de reportar problemas, mas deve garantir que o sistema processe e encaminhe os relatórios eficientemente. +- **Desenvolvedor:** Precisa assegurar que a funcionalidade de reporte de problemas esteja bem implementada e funcione sem falhas. + +#### Sugestões: +- Incluir detalhes sobre como o sistema lida com falhas no processamento de relatórios e sugere alternativas. + +### Cenário CN10: Acesso a Notícias Relacionadas ao Transporte Público + +#### Pontos de Vista: +- **Usuário:** Quer se manter informado sobre as últimas notícias e atualizações relacionadas ao transporte público. +- **Desenvolvedor do Sistema:** Deve garantir que a funcionalidade de notícias esteja atualizada e forneça informações relevantes. + +#### Avaliação: +- **Usuário:** Cenário atende bem à necessidade de acessar notícias e atualizações, mas deve garantir a precisão e relevância das informações. +- **Desenvolvedor:** Precisa assegurar que as notícias sejam atualizadas e relevantes para o usuário. + +#### Sugestões: +- Adicionar mecanismos para lidar com a falta de notícias e falhas na atualização das informações. + +### Cenário CN11: Atualização de Informações de Transporte Público por um Mooviter + +#### Pontos de Vista: +- **Mooviter:** Deve garantir que as informações sobre linhas de ônibus estejam atualizadas. +- **Desenvolvedor do Sistema:** Deve garantir que o processo de atualização seja seguro e eficiente. + +#### Avaliação: +- **Mooviter:** Cenário aborda bem a necessidade de atualizar informações, mas deve garantir a precisão e a segurança das atualizações. +- **Desenvolvedor:** Precisa assegurar que o sistema permita atualizações seguras e que as informações sejam rapidamente refletidas no sistema. + +#### Sugestões: +- Detalhar como o sistema lida com atualizações de dados e garantir a precisão e segurança do processo. + +### Cenário CN12: Exibição de Mapas com Rotas de Transporte Público + +#### Pontos de Vista: +- **Usuário:** Quer visualizar rotas de transporte público de forma clara e precisa. +- **Desenvolvedor do Sistema:** Deve garantir que a exibição dos mapas e rotas seja precisa e fácil de entender. + +#### Avaliação: +- **Usuário:** Cenário atende bem à necessidade de visualizar rotas, mas deve garantir a clareza e a precisão dos mapas. +- **Desenvolvedor:** Precisa assegurar que a exibição de mapas e rotas seja eficaz e sem erros. + +#### Sugestões: +- Adicionar funcionalidades para lidar com a visualização de rotas alternativas e garantir que os mapas sejam atualizados com precisão. + +| Autor | Versão |Data| +|-------|-----------------|----| +|[Pedro Paulo](https://github.com/Pedrin0030)|1ª |08/09/2024| \ No newline at end of file diff --git a/docs/Analise/lexico.md b/docs/Analise/lexico.md new file mode 100644 index 0000000..f49aa9f --- /dev/null +++ b/docs/Analise/lexico.md @@ -0,0 +1,92 @@ +## Análise do Léxico + +Abaixo haverá um detalhamento de cada categoria que será analisada em cada checklist: + +1. Símbolo + +* O símbolo é claramente definido e não ambíguo? +* O símbolo é relevante e utilizado consistentemente no contexto do sistema? + +2. Classificação + +* A classificação do símbolo está correta (Verbo, Objeto, Estado)? +* A classificação ajuda a entender a função e o uso do símbolo dentro do sistema? + +3. Sinônimo + +* Os sinônimos fornecidos são apropriados e refletem variações do símbolo? +* Há sinônimos adicionais que poderiam ser incluídos para maior clareza? + +4. Noção + +* A definição do símbolo é clara, objetiva e livre de jargões desnecessários? +* A definição é específica ao contexto do sistema e compreensível para os stakeholders? + +5. Impacto + +* O impacto do símbolo no sistema está bem descrito? +* A descrição do impacto mostra claramente como o símbolo contribui para a funcionalidade do sistema? + +6. Redirecionamento + +* O termo tem direcionamento? + +----- + +| Checklist | Alertas | Assinar Pacote Premium | Bicicleta Compartilhada | Carona Paga | +|------|-----|----|---|--| +| 1)Símbolo|Sim| Sim|Sim|Sim| +| 2)Classificação|Sim|Sim|Sim|Sim| +| 3)Sinônimo|Sim|Sim|Sim|Sim| +| 4)Noção|Sim|Sim|Sim|Sim| +| 5)Impacto|Sim|Sim|Sim|Sim| +| 6)Redirecionamento|Não|Não|Não|Não| + + +| Checklist | Definir Destino | Estação de Bicicletas compartilhadas | Favoritar | Filtrar rotas | +|------|-----|----|---|--| +| 1)Símbolo|Sim| Sim|Sim|Sim| +| 2)Classificação|Sim|Sim|Sim|Sim| +| 3)Sinônimo|Sim|Sim|Sim|Sim| +| 4)Noção|Sim|Sim|Sim|Sim| +| 5)Impacto|Sim|Sim|Sim|Sim| +| 6)Redirecionamento|Não|Não|Não|Não| + + +| Checklist | Linhas de Transporte | Localizar | Mapa | Moovit | +|------|-----|----|---|--| +| 1)Símbolo|Sim| Sim|Sim|Sim| +| 2)Classificação|Sim|Sim|Sim|Sim| +| 3)Sinônimo|Sim|Sim|Sim|Sim| +| 4)Noção|Sim|Sim|Sim|Sim| +| 5)Impacto|Sim|Sim|Sim|Sim| +| 6)Redirecionamento|Não|Não|Não|Não| + + +| Checklist | Mooviter | Moovit+ | Parada | Pesquisar por linha | +|------|-----|----|---|--| +| 1)Símbolo|Sim| Sim|Sim|Sim| +| 2)Classificação|Sim|Sim|Sim|Sim| +| 3)Sinônimo|Sim|Sim|Sim|Sim| +| 4)Noção|Sim|Sim|Sim|Sim| +| 5)Impacto|Sim|Sim|Sim|Sim| +| 6)Redirecionamento|Não|Não|Não|Não| + + +| Checklist | Reportar | Rota | Transporte Público | Usuário | +|------|-----|----|---|--| +| 1)Símbolo|Sim| Sim|Sim|Sim| +| 2)Classificação|Sim|Sim|Sim|Sim| +| 3)Sinônimo|Sim|Sim|Sim|Sim| +| 4)Noção|Sim|Sim|Sim|Sim| +| 5)Impacto|Sim|Sim|Sim|Sim| +| 6)Redirecionamento|Não|Não|Não|Não| + +## Conclusão + +Todos os itens do léxico atendem aos critérios estabelecidos pelo checklist, com exceção à identificação (redirecionamento) dos léxicos por meio de “hiperlink” ou semelhante. Cada símbolo está claramente definido, a classificação está correta, os sinônimos são adequados, as definições são claras e concisas, e o impacto está bem descrito. + + +| Autor | Versão |Data| +|-------|-----------------|----| +|[Márcio Henrique]|1ª |08/09/2024| \ No newline at end of file diff --git a/docs/Analise/nfr-framework.md b/docs/Analise/nfr-framework.md new file mode 100644 index 0000000..e1279da --- /dev/null +++ b/docs/Analise/nfr-framework.md @@ -0,0 +1,42 @@ +# Inspeção do NFR Framework + +A verificação do [NFR Framework](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/Modelagem/NFR-Framework.md) foi realizada por meio de uma inspeção detalhada utilizando o método de checklist. A inspeção seguiu critérios específicos para avaliar a clareza, consistência e viabilidade das abstrações e relações representadas no Softgoal Interdependency Graph (SIG). A seguir, é apresentado o checklist utilizado, uma tabela de avaliação dos diagramas inspecionados e uma lista dos principais problemas encontrados durante a análise. + +--- + +## Checklist para Verificação dos Diagramas + +1. Os softgoals estão nomeados de maneira clara e adequada? +2. Os softgoals estão diretamente vinculados aos critérios de qualidade relevantes? +3. As operacionalizações estão corretamente definidas e descrevem de forma clara como os softgoals serão implementados? +4. As operacionalizações possuem impactos mensuráveis e podem ser implementadas de forma prática para atingir os softgoals? +5. As argumentações justificam ou explicam decisões importantes? +6. As classificações ('help', 'hurt', 'make', 'break') estão corretamente aplicadas para descrever as contribuições? +7. As escolhas de contribuições ou operacionalizações são justificadas de forma explícita e lógica? +8. As notações e símbolos utilizados no diagrama estão consistentes e de acordo com as convenções do SIG? +9. O impacto de cada operacionalização está claramente representado, mostrando como contribui para os softgoals? +10. Existe uma representação clara de como os requisitos funcionais impactam ou são impactados pelos softgoals? + +--- + +## Tabela de Avaliação +Nesta tabela, um X indica que o diagrama atendeu completamente ao critério correspondente, enquanto um espaço em branco indica que o critério não foi atendido ou não foi adequadamente abordado. + +| Diagrama | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | +| :---- | :----: | :----: | :----: | :----: | :----: | :----: | :----: | :----: | :----: | :----: | +| [NFR001](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/assets/NFR/NFR%20MoovitV1.png) | X | X | | | | X | | X | | | +| [NFR002](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/assets/NFR/NFR%20%20MoovitV1-2.png) | X | X | X | | | X | | X | | | +| [NFR003](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/assets/NFR/NFR%20MoovitV2.jpg) | X | X | X | X | | X | | X | | | +| [NFR004](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/assets/NFR/NFR%20MoovitV3.jpg) | X | X | X | X | | X | X | X | X | | + +--- + +## Problemas Encontrados + +- Algumas operacionalizações não estão claramente definidas, faltando mais informações sobre como elas serão implementadas para atingir os softgoals. +- A avaliação prática do impacto das operacionalizações nos softgoals é dificultada pela falta de clareza sobre como esse impacto será medido. +- Não há uma representação clara de como os requisitos funcionais impactam ou são impactados pelos softgoals, o que compromete a análise de interdependências. + +| Autor | Versão |Data| +|-------|-----------------|----| +|[Diego Carlito](https://github.com/DiegoCarlito) e [Marcos Castilhos](https://github.com/Marcosatc147)|1ª |08/09/2024| \ No newline at end of file diff --git a/docs/Modelagem/istar.md b/docs/Modelagem/istar.md index b7ebdba..69794d7 100644 --- a/docs/Modelagem/istar.md +++ b/docs/Modelagem/istar.md @@ -46,7 +46,7 @@ Após a primeira versão a equipe decidiu em cada integrante fazer um "estrela" Após cada ator chave ter sido desenvolvido tivemos a versão final do "estrela" com contribuição geral da equipe. -![Segunda Versão pedro](<../assets/istar/version2.0.png>) +![Segunda Versão pedro](<../assets/istar/version2.png>) |Autor| Versão |Data| |----|----|---------- | diff --git a/docs/PosRastrea/backward-From.md b/docs/PosRastrea/backward-From.md new file mode 100644 index 0000000..7788f93 --- /dev/null +++ b/docs/PosRastrea/backward-From.md @@ -0,0 +1,48 @@ +# Backward From + +A rastreabilidade Backward From consiste em rastrear artefatos atuais (como diagramas, código ou documentação) de volta aos requisitos ou elementos iniciais. Isso permite verificar se o que foi implementado realmente satisfaz as necessidades e expectativas definidas no início do projeto. + +## Metodologia +- **Identificação dos Requisitos:** Para cada requisito, identificar seu ID, descrição, origem e status de implementação. +- **Mapeamento dos Artefatos:** Listar todos os artefatos produzidos e associá-los aos requisitos originais. +- **Verificação de Coerência:** Confirmar que os artefatos estão atendendo aos requisitos como descrito e conforme as expectativas definidas no início do projeto. Avaliar se o status de implementação reflete a conformidade esperada. + +## Tabela de Requisitos Funcionais + +| ID | Descrição | Origem | Implementado | +|----------|---------------|------------|------| +[RF01](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) | Permitir que os usuários busquem rotas de transporte público. |[RF01](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md)| Sim | +[RF02](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Fornecer informações em tempo real sobre horários de chegada dos ônibus. |[RF02](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md)| Sim | +[RF03](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Exibir diferentes rotas de transporte público disponíveis para um determinado destino. |[RF03](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md)| Sim | +[RF04](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Permitir que os usuários visualizem a localização dos veículos de transporte público em tempo real.|[RF04](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) | Sim | +[RF05](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Fornecer informações sobre as linhas de transporte público e suas paradas. |[RF05](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) | Sim | +[RF06](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Permitir a navegação passo a passo para os usuários chegarem ao seu destino. |[RF06](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md)| Sim | +[RF07](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Permitir que os usuários salvem suas linhas favoritas.|[RF07](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) | Sim | +[RF08](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Permitir que os usuários filtrem suas preferências de rotas e modos de transporte.|[RF08](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) | Sim | +[RF09](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Permitir que os usuários relatem problemas ou atualizações sobre rotas e horários.|[RF09](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) | Sim | +[RF10](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Fornecer dados de tráfego e condições das vias para melhor planejamento de rotas.|[RF10](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md)| Inconclusivo | +[RF11](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Sistema de geolocalização para rastreamento preciso dos usuários e veículos.|[RF11](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) | Parcialmente | +[RF12](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Permitir a personalização de notificações de horários e alertas de transporte.| [RF12](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md)| Sim | +[RF13](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Integrar soluções de IA para otimizar o planejamento e a operação dos transportes.| [RF13](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) | Inconclusivo | +[RF14](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Suportar modo offline para acessar informações básicas de rotas e paradas.| [RF14](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) | Não | +[RF15](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Fornecer suporte multilíngue para usuários de diferentes regiões.| [RF15](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) | Sim | +[RF16](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Suportar integração com serviços de carona paga para fornecer opções de transporte.| [Persona 4](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/Elicitacao/Personas.md) | Parcialmente | +[RF17](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |Integrar com serviços de bicicletas e patinetes compartilhados para exibir locais disponíveis.| [Persona 2](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/Elicitacao/Personas.md) | Não | + +## Tabela de Requisitos Não Funcionais + +| ID | Descrição | Origem | Implementado | +-----|-----|--------|-------------------| +[RNF01](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md)| O sistema deve ser responsivo, adaptando-se a diferentes tamanhos de tela (dispositivos móveis e tablets).|[RNF01](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md)| Sim | +[RNF02](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |O sistema deve ser compatível com as principais versões dos sistemas operacionais Android e iOS.| [RNF02](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) | Sim | +[RNF03](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md) |A interface do usuário deve ser intuitiva e fácil de usar, seguindo as diretrizes de design de UX/UI.|[RNF03](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md)| Sim | +[RNF04](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md)|O sistema deve seguir as condições de LGPD para a compra de assinaturas.|[RNF04](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md)| Sim | +[RNF05](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/PreRastrea/Baseline.md)|O sistema deve ser escalável sendo possível utilizar em qualquer região.| [Persona 3](https://github.com/Marcosatc147/req2024.1-Moovit/blob/main/docs/Elicitacao/Personas.md) | Sim | + + + +|Autor | Versão |Data| +|-------|-----------------|----| +|[Diego Carlito](https://github.com/DiegoCarlito)|1ª |11/09/2024| +|[Marcos Castilhs](https://github.com/Marcosatc147)|1ª |11/09/2024| +|[Pedro Paulo](https://github.com/Pedrin0030)|2ª |11/09/2024| \ No newline at end of file diff --git a/docs/PosRastrea/forward-From.md b/docs/PosRastrea/forward-From.md new file mode 100644 index 0000000..2361cae --- /dev/null +++ b/docs/PosRastrea/forward-From.md @@ -0,0 +1,44 @@ +# Forward From + +O objetivo do Forward From é garantir que todos os requisitos originais sejam corretamente endereçados e atendidos ao longo do desenvolvimento do projeto, permitindo uma visão clara de como cada requisito contribui para o produto final. + + +## Metodologia +- **Identificação dos Requisitos:** Confirmar que cada requisito tem um identificador único e uma descrição. +- **Funcionalidade:** Assegurar que as funcionalidades desenvolvidas correspondem aos requisitos especificados. +- **Mapeamento dos Artefatos:** Checar se os artefatos relacionados estão corretamente alinhados com o requisito. + +## Tabela de Requisitos Funcionais + +| ID | Descrição | Funcionalidade | Artefato | +|----------|---------------|------------|------| +<<<<<<< HEAD +RF01 | Permitir que os usuários busquem rotas de transporte público. | | Baseline,Brainstorm e RichPicture | +RF02 |Fornecer informações em tempo real sobre horários de chegada dos ônibus. | ![aovivo](../assets/pos/aovivo.jpeg) | Baseline,Brainstorm e RichPicture| +RF03 |Exibir diferentes rotas de transporte público disponíveis para um determinado destino. | ![sugestao](../assets/pos/sugestaorotas.jpeg) | Baseline,Brainstorm e RichPicture | +RF04 |Permitir que os usuários visualizem a localização dos veículos de transporte público em tempo real.| ![aovivo](../assets/pos/aovivo.jpeg) | Baseline, Brainstorm e RichPicture| +RF05 |Fornecer informações sobre as linhas de transporte público e suas paradas. | ![aovivo](../assets/pos/estacao.jpeg) | Baseline, Brainstorm e RichPicture | +RF06 |Permitir a navegação passo a passo para os usuários chegarem ao seu destino. | ![aovivo](../assets/pos/naavegação.jpeg) | Baseline | +RF07 |Permitir que os usuários salvem suas linhas favoritas.| ![aovivo](../assets/pos/favorito.jpeg) | Baseline| +RF08 |Permitir que os usuários filtrem suas preferências de rotas e modos de transporte.| ![aovivo](../assets/pos/rota.jpeg) | Baseline | +RF09 |Permitir que os usuários relatem problemas ou atualizações sobre rotas e horários.| ![aovivo](../assets/pos/mooviter.png) | Brainstorm e RichPicture | +RF10 |Fornecer dados de tráfego e condições das vias para melhor planejamento de rotas.| moovit+ | Baseline | +RF11 |Sistema de geolocalização para rastreamento preciso dos usuários e veículos.| ![aovivo](../assets/pos/geo.png) | Baseline | +RF12 |Permitir a personalização de notificações de horários e alertas de transporte.| | Baseline | +RF13 |Integrar soluções de IA para otimizar o planejamento e a operação dos transportes.| moovit+ | Baseline | +RF14 |Suportar modo offline para acessar informações básicas de rotas e paradas.| ![aovivo](../assets/pos/offile.jpeg) | Baseline| +RF15 |Fornecer suporte multilíngue para usuários de diferentes regiões.| ![aovivo](../assets/pos/linguistico.jpeg) | Baseline | +RF16 |Suportar integração com serviços de carona paga para fornecer opções de transporte.| ![aovivo](../assets/pos/privado.jpeg) | Baseline | + +## Tabela de Requisitos Não Funcionais + +| ID | Descrição | Funcionalidade | Artefato | +-----|-----|--------|-------------------| +<<<<<<< HEAD +RNF01| O sistema deve ser responsivo, adaptando-se a diferentes tamanhos de tela (dispositivos móveis e tablets).| Usuários em sua grande parte aprovam. | NFR004 | +RNF02|O sistema deve ser compatível com as principais versões dos sistemas operacionais Android e iOS.| “A solução está disponível para Android, iPhone e na versão Web” segundo o site do moovit | NFR004 | +RNF03|A interface do usuário deve ser intuitiva e fácil de usar, seguindo as diretrizes de design de UX/UI.| Por análise de uso esse requisito foi atendido pela maioria das partes | NFR004 | +RNF04|O sistema deve seguir as condições de LGPD para a compra de assinaturas.| Por se implantado no Brasil, é obrigatório que esse requisito seja atendido | NFR004 | +RNF05|O sistema deve ser escalável sendo possível utilizar em qualquer região.| Por ser um aplicativo global atendendo várias regiões esse requisito foi atendido | NFR004 | + + diff --git a/docs/_sidebar.md b/docs/_sidebar.md index 477e9af..a55b7fc 100644 --- a/docs/_sidebar.md +++ b/docs/_sidebar.md @@ -32,8 +32,12 @@ * [Ágil](./Agil/backlog.md) * [Análise](./Analise/analise.md) - + * [- Cenário](./Analise/cenario.md) + * [- Léxico](./Analise/lexico.md) + * [- Backlog](./Analise/backlog.md) + * [- Argumentação](./Analise/argumentacao.md) * [Pós-Rastreabildade]() * [- Backward-From](./PosRastrea/backward-From.md) - * [- Forward-From](./PosRastrea/forward-From.md) \ No newline at end of file + * [- Forward-From](./PosRastrea/forward-From.md) + diff --git a/docs/assets/istar/version2.0.png b/docs/assets/istar/version2.0.png deleted file mode 100644 index 1ca5934..0000000 Binary files a/docs/assets/istar/version2.0.png and /dev/null differ diff --git a/docs/assets/istar/version2.png b/docs/assets/istar/version2.png new file mode 100644 index 0000000..2163c30 Binary files /dev/null and b/docs/assets/istar/version2.png differ diff --git a/docs/assets/pos/aovivo.jpeg b/docs/assets/pos/aovivo.jpeg new file mode 100644 index 0000000..5e7de33 Binary files /dev/null and b/docs/assets/pos/aovivo.jpeg differ diff --git a/docs/assets/pos/estacao.jpeg b/docs/assets/pos/estacao.jpeg new file mode 100644 index 0000000..dbc03b9 Binary files /dev/null and b/docs/assets/pos/estacao.jpeg differ diff --git a/docs/assets/pos/favorito.jpeg b/docs/assets/pos/favorito.jpeg new file mode 100644 index 0000000..5fb0c0d Binary files /dev/null and b/docs/assets/pos/favorito.jpeg differ diff --git a/docs/assets/pos/geo.png b/docs/assets/pos/geo.png new file mode 100644 index 0000000..9b962c9 Binary files /dev/null and b/docs/assets/pos/geo.png differ diff --git a/docs/assets/pos/linguistico.jpeg b/docs/assets/pos/linguistico.jpeg new file mode 100644 index 0000000..0e28cfa Binary files /dev/null and b/docs/assets/pos/linguistico.jpeg differ diff --git a/docs/assets/pos/mooviter.png b/docs/assets/pos/mooviter.png new file mode 100644 index 0000000..ae99897 Binary files /dev/null and b/docs/assets/pos/mooviter.png differ diff --git "a/docs/assets/pos/naavega\303\247\303\243o.jpeg" "b/docs/assets/pos/naavega\303\247\303\243o.jpeg" new file mode 100644 index 0000000..59a757d Binary files /dev/null and "b/docs/assets/pos/naavega\303\247\303\243o.jpeg" differ diff --git a/docs/assets/pos/offile.jpeg b/docs/assets/pos/offile.jpeg new file mode 100644 index 0000000..3b927a7 Binary files /dev/null and b/docs/assets/pos/offile.jpeg differ diff --git a/docs/assets/pos/privado.jpeg b/docs/assets/pos/privado.jpeg new file mode 100644 index 0000000..c214333 Binary files /dev/null and b/docs/assets/pos/privado.jpeg differ diff --git a/docs/assets/pos/rota.jpeg b/docs/assets/pos/rota.jpeg new file mode 100644 index 0000000..ff41387 Binary files /dev/null and b/docs/assets/pos/rota.jpeg differ diff --git a/docs/assets/pos/sugestaorotas.jpeg b/docs/assets/pos/sugestaorotas.jpeg new file mode 100644 index 0000000..c52251c Binary files /dev/null and b/docs/assets/pos/sugestaorotas.jpeg differ