Como escrever um documento de requisitos de produto de aplicativo móvel

Neste artigo, falaremos sobre a função crítica dos requisitos no desenvolvimento de aplicativos móveis. Quais são os tipos de requisitos e qual a maneira correta de desenvolvê-los? Role para baixo e obtenha um exemplo de documento de requisitos de aplicativo móvel para ajudá-lo a começar.

Conteúdo:

1. Por que você deve escrever um documento de requisitos de produto de aplicativo móvel
2. Tipos de requisitos
3. Requisitos de negócio
4. Requisitos do usuário
5. requisitos de sistema
6. Maneiras de desenvolver e gerenciar requisitos
7. Características de um bom documento de requisitos de desenvolvimento de aplicativos móveis
8. Um modelo de documento de requisitos de aplicativo móvel

Por que você deve escrever um documento de requisitos de produto de aplicativo móvel (PRD)?

Para transformar sua ideia em um aplicativo móvel entregável, você precisa de uma equipe de desenvolvedores. Mas encontrar a equipe certa não é a parte difícil. A parte difícil é explicar a visão de seu aplicativo móvel para os desenvolvedores de forma tão clara que eles a concebam da maneira que você faz.

Escrever um documento de requisitos de produto de aplicativo móvel (PRD) ajuda a facilitar um encontro de mentes entre você e outras partes interessadas . Não hesite em investir tempo em requisitos de produtos de engenharia, porque a recompensa potencial é clara.

• Aumente sua própria certeza. Discutir os requisitos para seu aplicativo móvel torna tudo mais claro. Objetivos, perspectivas, recursos, restrições - sua visão de produto começa a tomar forma. Determinar os requisitos do produto leva você de declarações confusas para tarefas tangíveis com prazos, orçamentos e critérios de qualidade completos.

• Deixe suas ideias claras para os desenvolvedores. Requisitos claros de produto reduzem a lacuna de expectativa entre o aplicativo móvel que você deseja e o que os desenvolvedores oferecem.

• Obtenha desenvolvimento e entrega rápidos. Com os requisitos documentados do aplicativo móvel em vista, sua equipe de desenvolvimento pode entender melhor seu projeto, definir prioridades e reduzir o retrabalho.

• Certifique-se de que o aplicativo final atenda às suas expectativas de qualidade. Graças aos critérios de aceitação declarados em um PRD, sua equipe pode determinar facilmente se você ficará satisfeito com o aplicativo entregue.

• Reduza o deslocamento do escopo. Uma especificação de requisitos de alta qualidade evita que você desenvolva recursos desnecessários, impede que sua equipe de desenvolvedores trabalhe com propósitos cruzados e evita que toda a equipe de desenvolvimento fique sobrecarregada.

• Gastar menos. Uma vez que requisitos bem elaborados contribuem para o foco no essencial, reduzem o retrabalho e aceleram o desenvolvimento, eles economizam seu dinheiro.

De acordo com a pesquisa de Boehm, o retrabalho pode custar cerca de 40% a 50% do custo total de todo o desenvolvimento de software. E uma grande parte do retrabalho é causada por erros de requisitos.

Outra vantagem dos requisitos claros é que eles permitem que sua equipe detecte defeitos logo após a criação de um produto e os conserte a um custo menor do que no desenvolvimento tardio ou após o lançamento do aplicativo. Portanto, considere o desenvolvimento de requisitos não como um desperdício e uma questão frustrante, mas como um investimento em seu projeto que vai render muito .

Tipos de requisitos

Quando você tem a ideia de fazer um aplicativo, precisa se perguntar três questões principais:

• Porque? Por que você precisa de um aplicativo móvel? Para ajudar as pessoas com sua experiência única, obtenha um fluxo de receita extra, como um investimento - qual é o seu objetivo?
• Quem? Quem usará seu aplicativo? Pense nas dores, problemas, necessidades e preferências dos usuários-alvo. Que solução os usuários esperam obter de seu aplicativo?
• Como? Como você alcançará os resultados de negócios desejados e atenderá às expectativas dos usuários? Pense na funcionalidade que seu aplicativo deve fornecer.

As respostas a essas perguntas formam três níveis principais de requisitos para o desenvolvimento de aplicativos móveis: requisitos de negócios, requisitos de usuário e requisitos de sistema.

Cada nível também possui uma variedade de requisitos funcionais e não funcionais.

Os requisitos funcionais estão relacionados à operação e aos recursos do seu aplicativo que você irá implementar.

Os requisitos não funcionais definem características e restrições que não estão conectadas aos requisitos funcionais. Na maioria dos casos, os requisitos não funcionais estão relacionados a:

• Atributos do produto desenvolvido, como desempenho, confiabilidade, disponibilidade e usabilidade.
• O processo de desenvolvimento , descrevendo metodologias de desenvolvimento, padrões, linguagens de codificação, restrições de tempo, segurança, etc.
• O ambiente externo , levando em consideração a conexão do seu aplicativo a outros sistemas e componentes de hardware, alinhamento com a política corporativa, regulamentações governamentais e assim por diante

Se você está preocupado em como escrever especificações para o desenvolvimento de aplicativos móveis, comece eliciando seus requisitos de negócios.

Requisitos de negócio

Ao escrever seus requisitos de negócios, concentre-se nos motivos pelos quais construir um aplicativo móvel é essencial para o seu negócio, as mudanças que o aplicativo acarretará e os resultados que você espera que ele proporcione. Para manter sua visão de produto clara para sua empresa de desenvolvimento, você deve registrar seus requisitos de negócios em um documento de requisitos de negócios de aplicativo móvel (BRD) .

Observe que, embora usemos o termo “documento”, ele não precisa ser um pedaço de papel impresso ou um Documento Google. Você pode armazenar seus requisitos usando diagramas, bancos de dados, planilhas ou ferramentas de gerenciamento de requisitos, ou pode combiná-los com um documento de texto tradicional.

Com base no documento de visão e escopo proposto por Karl Wiegers na terceira edição dos Requisitos de Software , preparamos a seguinte estrutura BRD:

Você pode representar o escopo do seu projeto usando diferentes ferramentas. O mais abrangente é uma tela enxuta . Ele representa os segmentos de um plano de negócios crucial para o desenvolvimento de documentação para todos os aplicativos móveis: grupos de usuários e seus principais problemas, soluções que seu aplicativo irá fornecer junto com uma proposta de valor única (UVP) e outras vantagens. No modelo de tela enxuta, você pode descrever os canais que usará para atrair usuários-alvo e as principais métricas que dirão como está seu negócio. Uma tela enxuta também ajuda a determinar o modelo de monetização para seu aplicativo móvel junto com outros fluxos de receita em potencial.

Para promover uma comunicação clara entre todas as partes interessadas do projeto, na Mind Studios, também usamos um mapa mental . Esta ferramenta espelha a lógica de um aplicativo móvel e as interconexões entre seus principais componentes.

Aqui está um exemplo simples de um mapa mental para um aplicativo de meditação como o Headspace:

Lembre-se de que o esboço dos requisitos de negócios envolve todos os participantes do projeto. É sempre um esforço conjunto.

Requisitos do usuário

Depois de identificar seus requisitos de negócios, é hora de se concentrar nas necessidades de seus usuários. Você precisa delinear os objetivos potenciais com os quais os usuários acessam seu aplicativo e as ações que eles realizarão para atingir esses objetivos. Mas que opinião você deve considerar ao redigir os requisitos do usuário?

O problema é que não existe um único tipo de usuário de aplicativo. Pelo contrário, existem muitos tipos de usuários que solicitam coisas diferentes: investidores, proprietários de negócios, usuários finais, desenvolvedores, distribuidores, reguladores, equipe de marketing e outros. Sua tarefa é ouvir a todos e encontrar o equilíbrio entre as necessidades dos diferentes grupos de usuários.

Quando se trata dos requisitos do usuário, é sensato começar com estas três etapas:

Etapa 1 - Classificar usuários. Agrupe todas as partes interessadas em classes de usuário. Você pode classificá-los de acordo com os seguintes critérios:

• Nível de acesso (convidado, usuário regular, usuário pagante, provedor, administrador)
• Tarefas que executam (encontrar, ver, ler, selecionar, comprar, compartilhar, comentar)
• Recursos de aplicativos que eles usam (pesquisa, mapeamento, classificação, comparação, pagamento etc.)
• Frequência de visitas (diária, mensal)
• Plataformas utilizadas (iOS ou Android)
• Língua nativa (ou outros dados demográficos, como localização, sexo, educação e situação familiar).

Etapa 2 - Identifique os campeões do produto. Escolha indivíduos que possam representar cada grupo de usuários e comunicar os requisitos do usuário ao seu gerente de projeto. Ser um bom campeão de produto significa ter uma visão clara dos benefícios que seu aplicativo trará aos usuários. Por sua vez, os defensores do produto devem ser usuários reais para compreender perfeitamente as dores e necessidades urgentes dos usuários.

Etapa 3 - chegue a um acordo sobre os tomadores de decisão dos requisitos para o seu projeto. Combine os representantes de cada grupo de usuários com as partes interessadas. Tenha cuidado para não ignorar nenhuma parte interessada para evitar reclamações de que o aplicativo final não atende às expectativas das partes interessadas.

Depois de identificar representantes de usuários qualificados, obtenha sua opinião sobre dois tipos de requisitos de usuários.

Registre o feedback dos usuários em um documento de requisitos do usuário (URD) . Para fazer isso, você pode usar as seguintes técnicas:

A persona do usuário é uma ferramenta útil que permite visualizar seus usuários-alvo. Para cada persona do usuário, escolha um nome e uma foto e, em seguida, liste as necessidades, desejos e objetivos do usuário. Escreva os principais motivos pelos quais a persona usará seu aplicativo. Aqui está um exemplo de uma persona de usuário que criamos para um aplicativo de mídia social como o LinkedIn:

Histórias de usuários. Descreva as ações que os usuários realizarão em seu aplicativo para atingir seus objetivos. Em seguida, organize essas ações em uma sequência natural para determinar uma jornada típica do usuário por meio de seu aplicativo. Dependendo do escopo do seu projeto, você pode principalmente delinear epopeias - ações do usuário intrincadas que você pode decompor em etapas menores que os usuários realizarão durante o uso do seu aplicativo. Epopéias são histórias de usuários que tendem a ser escritas da seguinte forma: Como um <tipo de usuário>, quero <algum objetivo> para que <algum motivo>.

No desenvolvimento ágil, as histórias de usuário costumam ser colocadas em um backlog do produto. Ao negociar o escopo de desenvolvimento de software para a primeira versão e as versões subsequentes, você e sua equipe de desenvolvimento considerarão as histórias de usuário do backlog e selecionarão as mais relevantes. Ao organizar histórias de usuário, você pode formar um roteiro de produto que define claramente quais recursos do aplicativo você deve implementar e quando. O exemplo abaixo está relacionado às duas epopéias básicas mais comuns para qualquer aplicativo móvel:

requisitos de sistema

Um documento de requisitos de produto completo para um aplicativo móvel deve conter os requisitos sobre como seu aplicativo deve operar. Resista à tentação de escrever requisitos de sistema às pressas com base apenas nos desejos dos usuários e nas necessidades de negócios. Fale com os desenvolvedores. Eles darão feedback sobre se é tecnicamente possível realizar seus planos originais para a funcionalidade do aplicativo. Ao conversar com os desenvolvedores, você revelará ameaças potenciais ao desenvolvimento do seu projeto e poderá estabelecer coletivamente um plano B para contorná-las.

Após um diálogo construtivo com sua equipe, anote os requisitos acordados em uma especificação de requisitos de software (SRS) que contém os seguintes blocos:

requisitos de sistema
Requisitos funcionais	Liste os recursos que os desenvolvedores podem construir para permitir que os usuários concluam tarefas de acordo com seus requisitos de negócios. Para fazer isso, use mapas mentais existentes ou histórias de usuários. Depois de definir o que seu aplicativo fará, atribua um nome e número exclusivos a cada requisito funcional junto com uma breve descrição, justificativa e status.
Requisitos de subsistema	Descreva os requisitos para seu aplicativo móvel da perspectiva dos subsistemas de software e hardware. Por exemplo, se você for construir um aplicativo de rastreamento de atividades físicas, precisará escrever requisitos para rastreadores vestíveis que serão sincronizados com o aplicativo.
Regras do negócio	Como todos os negócios estão sujeitos a leis, políticas e padrões do setor, essas serão fontes óbvias de requisitos para um SRS. Aqui está uma lista de fontes de requisitos: Política corporativa Regulamentações governamentais Padrões industriais Funções do usuário e classificações de permissão Modelos se-então de comportamento do usuário Algoritmos computacionais, se houver
Requisitos de dados	Ao desenvolver um aplicativo móvel, você precisa criar, armazenar, modificar, exibir, excluir, processar e usar grandes quantidades de dados. Para gerenciar fluxos de dados, você precisa: delinear um modelo lógico de interações de entidades de dados definir entidades no dicionário de dados especificar como o sistema deve aplicar a análise, retenção ou descarte de dados escolha os tipos de relatórios de dados (planilhas, gráficos, painéis, etc.)
Atributos de qualidade	Escrever critérios de qualidade claros garante que os desenvolvedores atenderão às suas expectativas com o produto final. Você precisa considerar os atributos de qualidade que são importantes para: sua empresa e usuários, como usabilidade, desempenho e segurança ( atributos externos ) desenvolvedores, como eficiência, capacidade de modificação e portabilidade ( atributos internos ) Discuta quais atributos são essenciais para o sucesso de seu aplicativo com outras partes interessadas e priorize-os. Escreva expectativas específicas para cada atributo usando critérios de ajuste - uma quantificação do requisito que descreve o padrão que seu aplicativo deve atingir. Traduzir atributos de qualidade em especificações técnicas e escrever testes de aceitação para sua equipe para permitir que eles verifiquem os resultados.
Interfaces externas	Esta parte de um documento de requisitos funcionais para um aplicativo móvel é necessária para garantir que seu aplicativo se comunique adequadamente com usuários e sistemas externos de hardware ou software. Em uma SRS, você precisa anotar os requisitos para: Interfaces de usuário. Especifique o design das telas do seu aplicativo móvel (padrões para fontes, ícones, esquemas de cores, imagens, tamanho da tela, layout, resolução e assim por diante) Interfaces de software. Descreva as interações entre seu aplicativo e outros componentes de software, incluindo outros aplicativos, sites, bibliotecas, bancos de dados e ferramentas. Interfaces de hardware. Descreva cada um dos tipos de dispositivos suportados, interações de dados e controle entre software e hardware e protocolos de comunicação a serem usados. Interfaces de comunicação. Em um SRS para seu aplicativo móvel, indique os requisitos para quaisquer funções de comunicação que seu aplicativo usará, incluindo mensagens no aplicativo, notificações push, e-mails e protocolos de rede.
Restrições	Registre as restrições que restringem o design, a operação e a implementação de seu aplicativo móvel. Em primeiro lugar, verifique se a especificação dos requisitos do seu aplicativo móvel está de acordo com os requisitos da Apple App Store e Google Play Store. Além disso, especifique outras restrições do sistema impostas, por exemplo, pela linguagem de programação usada ou regras de uso de APIs ou conteúdo de terceiros.
Requisitos de localização	Se você deseja que seu aplicativo seja usado em países, culturas e localizações geográficas diferentes daqueles em que foi criado, defina os requisitos para a mudança: Moeda Formatos de data, número, endereço e número de telefone Idioma (incluindo convenções ortográficas nacionais, dialetos locais, instruções) Funcionalidade para cumprir regulamentos e leis Conteúdo considerando questões culturais e políticas Fusos horários Pesos e medidas Outras variáveis

Vamos dar uma olhada mais de perto nas ferramentas que você pode usar para representar os requisitos do sistema em sua especificação de requisitos de software para um aplicativo móvel.
As planilhas oferecem uma apresentação tradicional em linhas e colunas da funcionalidade do aplicativo que você pretende construir. Vamos revisar um fragmento da planilha de requisitos funcionais que elaboramos como parte de um documento de desenvolvimento de aplicativo móvel imobiliário:

Um diagrama de relacionamento de entidade (ERD) representa como as entidades de dados se relacionam entre si dentro de um sistema e as conexões entre os elementos dentro dessas entidades. A seguir está um exemplo de um diagrama que usamos em um documento de especificação de requisitos para um aplicativo móvel de entrega de comida:

Maneiras de desenvolver e gerenciar requisitos

Conforme seu projeto evolui, mudanças nos requisitos de software para seu aplicativo móvel são inevitáveis. Novos requisitos podem surgir de qualquer lugar: seus investidores podem insistir em obter um retorno sobre o investimento mais rápido do que o planejado; os usuários podem ir para o aplicativo de um concorrente porque seu aplicativo não fornece um recurso de que gostam; as atualizações de software subsequentes podem impor restrições extras ao desenvolvimento de seu aplicativo móvel.

É tentador descrever os requisitos de software para o desenvolvimento de aplicativos móveis de uma vez por todas, mas fazer isso pode levar ao fracasso do projeto. Vamos descobrir por que o desenvolvimento de requisitos é um processo iterativo .

A redação dos requisitos para o seu projeto de aplicativo móvel geralmente envolve a execução de quatro atividades:

1. Elicitar, ou perguntar o que os usuários esperam de um novo produto, ouvindo o que eles dizem e observando o que fazem
2. Análise ou processamento de feedback do usuário para compreender, classificar e relacionar essas informações a possíveis requisitos de aplicativos móveis
3. Coleta de especificações, que envolve transformar a entrada vaga do usuário em documentos de requisitos bem pensados, estruturados e escritos com ilustrações visuais
4. Validação, que consiste em obter a confirmação das partes interessadas de que a especificação de requisitos que você criou é precisa e completa

Ao conduzir a análise, você pode perceber algumas imprecisões que o levam de volta à elicitação. E ao escrever um documento de requisitos de produto de aplicativo móvel, você pode esbarrar em algumas lacunas que exigem que você conduza mais análises. Se as partes interessadas apontarem erros em seu documento de requisitos, você terá que reescrever algumas declarações, conduzir uma reanálise ou mesmo conduzir uma pesquisa de acompanhamento. Somente entrelaçando e iterando essas atividades você pode fornecer às partes interessadas os requisitos de aplicativos móveis relevantes ao longo de todo o ciclo de desenvolvimento.

Na Mind Studios , definimos e concordamos com os requisitos iniciais do produto na fase de descoberta e validação da ideia, executando as seguintes etapas:

Em nome do sucesso do seu projeto, você precisa controlar a volatilidade dos requisitos com um gerenciamento sólido. Um gerente de projeto e / ou analista de negócios pode assumir essa responsabilidade. Os gerentes de projeto e analistas de negócios têm diferentes ferramentas de gerenciamento de requisitos para:

• Rastreie a necessidade de mudar os requisitos
• Realize uma análise de impacto para determinar o que essas mudanças trarão para o desenvolvimento do projeto
• Manutenção de requisitos de rastreamento
• Acompanhe o status de cada requisito
• Rastrear problemas de requisitos
• Manter um histórico de mudanças de requisitos

Características de um bom documento de requisitos de desenvolvimento de aplicativos móveis

Visto que em nenhum lugar mais do que nos requisitos do produto os interesses de todas as partes interessadas se cruzam, você precisa ter certeza de que seus requisitos são igualmente claros e compreensíveis para investidores, usuários e desenvolvedores. Como construir um documento de requisitos de aplicativo móvel para atender às necessidades de todos? Não apenas o conteúdo de um documento de requisitos, mas o tom de voz pode ajudá-lo com isso.

Vá além para obter um documento de requisitos de produto de alta qualidade. Discuta o nível de detalhe, as técnicas de representação e o estilo de redação que são melhores para as partes interessadas.

Em um mundo perfeito, os requisitos de seu aplicativo móvel declarados em um PRD devem ser:

• Completo. Por exemplo, cada requisito funcional deve conter informações suficientes para que os desenvolvedores possam implementá-lo corretamente. Se você tiver algumas lacunas, marque-as como TBD (a ser determinado) e faça o acompanhamento mais tarde.
• Correto. Você e sua equipe de desenvolvimento devem verificar a exatidão do documento de requisitos do produto do seu aplicativo móvel. Você pode considerar os requisitos corretos se eles estiverem em conformidade com as especificações técnicas, regras de negócios, padrões do setor e leis relevantes.
• Consistente. Isso significa que nenhum requisito em um PRD deve contradizer outros requisitos no mesmo PRD.
• Factível. Deve ser possível realizar cada requisito de produto dentro do ambiente operacional disponível, dados os recursos, tempo e orçamento conhecidos da equipe. A metodologia de desenvolvimento Agile e os protótipos de prova de conceito ajudam a avaliar a viabilidade dos requisitos.
• Priorizado. Cada requisito, seja um requisito funcional ou um requisito do usuário, deve ser classificado de acordo com a importância a ser implementado para uma liberação específica.
• Modificável. Como os requisitos podem mudar durante o desenvolvimento, a estrutura do documento de requisitos de seu produto precisa ser flexível.
• Verificável. Os requisitos do produto devem ser mensuráveis ​​e específicos para que os testadores possam verificá-los com testes e determinar se um determinado requisito foi implementado corretamente.
• Não ambíguo. Um dos principais motivos para escrever um documento de requisito de produto de aplicativo móvel é reduzir a falta de comunicação. Você precisa escrever todos os requisitos para que só possam ser interpretados de uma maneira possível.

Recomendamos fortemente a criação de um glossário de termos desde o início do desenvolvimento . O fato é que os desenvolvedores não estão familiarizados com a linguagem do seu negócio e provavelmente você não é proficiente em programação. A falta de compreensão dos termos pode levar a retrabalho, prazos perdidos, excesso de custos e debates desnecessários.

Um modelo de documento de requisitos de aplicativo móvel

Algumas empresas exigem uma lista detalhada de requisitos apoiada por uma especificação técnica bem elaborada, enquanto outras se contentam com uma abordagem superficial. Não importa a qual grupo você pertença, você deve começar de algum lugar.

Como orientação para desenvolver os requisitos iniciais, você pode preencher nosso modelo de requisitos de produto de aplicativo móvel . Ele fornece informações básicas suficientes para facilitar e acelerar a entrada dos desenvolvedores em seu projeto e, portanto, economizar tempo e dinheiro.

Resumo do documento de requisitos de produtos de aplicativos móveis feito pela Mind Studios

After you complete this brief, email it to us and one of our managers will respond promptly. This brief will provide a solid basis for creating a detailed mobile app product requirements document with the help of our team.

Have any questions about your mobile app project? Deixe-nos uma mensagem.

Palavra final

Even for the smallest projects, it's critical to have a shared understanding of initial requirements. In some cases, ready-made product requirements document templates can help you out. But more often, they're only illustrative. Since no two apps are alike, there's no chance that someone else's PRD will suit your project.

To perfectly meet your specific tasks, you need to create an original mobile app requirements document , which can be a time-consuming and tedious process. The good news is that you can leave it to experts. Especially since they're just one call away.