Backlog do Produto
Introdução
Este artefato apresenta o backlog do produto na perspectiva de software para o projeto SpeedChair, com foco na elicitação e estruturação dos requisitos essenciais para o desenvolvimento da cadeira de rodas. A definição desses requisitos garante que a solução atenda às necessidades dos usuários, oferecendo funcionalidades que promovam segurança, acessibilidade e eficiência no uso diário. O backlog foi elaborado com base em reuniões com a equipe técnica e professores.
Objetivo
O objetivo desta analise no contexto de software, é elicitarmos os requsitos que irão compor o subsistema de software da cadeira, onde essa visão irá nos mostrar como podemos estruturar as funcionalidades e quais serão nossas prioridades na implementação.
Metodologia
Para o levantamento de requisitos dos sistemas de software que irão fazer parte do produto final, foram reailzadas reuniões em equipe e com professores com o intuito de elicitar os requisitos por meio de brainstorm, análise de concorrentes, análise de cenários, e entre outros métodos. Vale ressaltar que os requisitos do produto estão sendo baseados em um ambiente ideal, como asilos e hospitais, onde o contexto não muda de forma brusca com o decorrer do tempo. Abaixo temos a tabela 1 que mostra o backlog do produto no aspecto de software.
| ID | Requisito | Descrição |
|---|---|---|
| BGS1 | A cadeira deve ter um sistema embarcado que realiza a coleta de dados da cadeira | É importante termos dados sobre a cadeira, desde a questão da carga da bateria, até o estado dos componentes eletrônicos do sistema, com isso é importante que haja um sistema que consuma esses dados e os salve para utilização. |
| BGS2 | A cadeira deve possuir um sistema que analise os dados coletados e gere eventos de alerta, avisos e ou sinais de emergência | Tendo em vista o primeiro requisito do projeto que envolve a coleta de dados sobre o estado da cadeira, é importante que esses dados sejam tratados e processados por um sistema para emitir algum tipo de sinal sobre o estado da cadeira |
| BGS3 | A cadeira deve possuir um sistema de sensoriamento para identificação de potenciais riscos para o usuário, como buracos, escadas e outros perigos relacionados | Como a cadeira é controlada pelo usuário, pode haver riscos do usuário não conseguir definir se o obstáculo que está a sua frente, pode prejudir a cadeira e/ou o próprio usuário da cadeira |
| BGS4 | A cadeira deve possuir um sistema de emergência que ao processar dados de riscos, ela emite um alerta e em casos extremos, desarma a caderia | Como no requisito anterior deve ter um sistema para identificar riscos ao usuário ou a cadeira, é importante ter um sistema que lide com essa informação, o tratando de forma rápida e segura para manter o usuário e a cadeira em um estado saudável |
| BGS5 | A cadeira deve possuir um sistema de emergência acionado pelo próprio usuário que deve desativar a cadeira temporariamente e que emita um aviso sobre o acionamento | Esse requisito tem relação ao botão de emergência alocado na cadeira |
| BGS6 | A cadeira deve ter conexão com Alexa para emitir as informações da cadeira como os avisos, alertas e as informações de emergência | Vendo a questão da quantidade de informações que a cadeira transmite ao usuário após o processamento, é importante que essas informações sejam de fácil acesso, por isso a questão da integração com a Alexa |
| BGS7 | A cadeira deve ter um sistema para geração de relatórios que serão enviados por e-mail | Para facilitar a visualização dos dados referentes à cadeira e permitir que os usuários tomem decisões informadas de maneira eficiente e prática |
Fonte: Ester Lino, Wildemberg Sales.
Para uma melhor compreensão dos dados e trazendo esse backlog para uma visão de projeto ágil, todos os requisitos do backlog foram modelados como História de Usuário seguindo o padrão "Eu, como 'Tipo de usuário', quero que 'ação que o sistema deve executar' para que 'explicação do motivo para executar a ação'". Com isso trazemos uma abordagem um pouco mais analítica de cada requisito dentro de um modelo ágil, facilitando a visualização do escopo.
| ID | História de Usuário | Requisito Relacionado |
|---|---|---|
| US01 | Eu, como usuário, quero que ela colete e salve dados sobre o estado da bateria e componentes eletrônicos para que eu possa monitorar e garantir a manutenção adequada. | BGS1 |
| US02 | Eu, como usuário, quero que o sistema analise os dados coletados e gere eventos de alerta, avisos e sinais de emergência para que eu seja informado de qualquer anomalia ou risco de falha. | BGS2 |
| US03 | Eu, como usuário, quero que ela tenha um sistema de sensoriamento que identifique riscos como buracos, escadas e outros perigos para que eu possa ser alertado a tempo e evitar acidentes. | BGS3 |
| US04 | Eu, como usuário, quero que, ao processar dados de riscos, o sistema emita um alerta e, em casos extremos, desative a cadeira para minha segurança e preservação da cadeira. | BGS4 |
| US05 | Eu, como usuário, quero ter um botão de emergência que eu possa acionar manualmente para desativar a cadeira temporariamente e emitir um aviso de acionamento para que eu possa responder rapidamente a situações de perigo. | BGS5 |
| US06 | Eu, como usuário, quero que ela se conecte à Alexa para que as informações sobre dados, alertas, avisos e emergências sejam emitidas e de fácil acesso, permitindo que eu receba notificações sem precisar interagir diretamente com a cadeira. | BGS6 |
| US07 | Eu, como usuário, gostaria de me comunicar com a Alexa conectada a minha cadeira, para a solicitação de dados específicos da cadeira. | BGS6 |
| US08 | Eu, como usuário, gostaria de receber os relatórios gerados pela cadeira diretamente em meu e-mail, para que eu possa acessar e analisar os dados de forma conveniente. | BGS7 |
Fonte: Ester Lino, Wildemberg Sales.
Conclusão
Portanto, após todo o processo de elicitação realizado e as priorizações feitas, conseguimos ter um escopo de produto de software para a cadeira, com os requisitos elicitados, podemos modelar e planejar as outras partes que irão compor o sistema de software.
Tabela de Versionamento
| Versão | Versão | Descrição | Responsável |
|---|---|---|---|
| 1.0 | 13/11/2024 | Criação do artefato de backlog do produto em visão de software | Wildemberg Sales, Ester Lino |
| 1.1 | 23/11/2024 | Correção da estrutura do artefato de backlog do produto em visão de software | Wildemberg Sales, Ester Lino |
| 1.2 | 23/11/2024 | Adesão da US07 para o backlog do produto em visão de software | Wildemberg Sales, Ester Lino |
| 1.3 | 15/01/2025 | Adesão da US08 para o backlog do produto em visão de software | Arthur Gabriel |
| 1.4 | 18/02/2025 | Revisão do Backlog | Ester Lino, Wildemberg Sales |