Índice do curso
1.
2.
3.
4.
5.
6.
7. < —
8. - -
9.
—
Às vezes parece que a tarefa para o desenvolvedor é simplesmente óbvia! Mas não confie muito no bom senso ao definir o problema. Para qualquer um, mesmo na tarefa mais simples, as discrepâncias são possíveis, porque as pessoas tendem a viver em um mundo de suas próprias ilusões. Por exemplo, na República de Cuba, acredita-se que as paredes devem ser claras e matizadas, e mesmo que o cliente peça para pintar as paredes de branco, os trabalhadores podem adicionar manchas de cor, porque “fica mais bonito assim”. O mesmo vale para o desenvolvimento.
Tal documento como requisitos ajuda a superar a “parede de mal-entendidos”. A presença de requisitos permite criar a mesma ideia do que precisa ser feito no produto, o que exatamente deve ser o recurso.
Como os requisitos são construídos
Ao formular requisitos de desenvolvimento, você precisa entender para qual usuário estamos desenvolvendo um produto. É aqui que a Persona do Usuário se torna útil (já falamos sobre eles aqui ). User Persona é o chamado Ator no sistema e, para cada ator, definimos um conjunto de regras e recursos.
Por exemplo, os seguintes atores podem ser definidos em um aplicativo de fórum da web:
- O administrador pode fazer tudo, literalmente tudo - incluindo atribuir funções (pessoas) a outros usuários.
- Um usuário normal só pode deixar mensagens.
- O moderador pode deixar mensagens, deletar mensagens de outras pessoas, banir usuários regulares.
No caso do aplicativo de chamada de táxi, que periodicamente relembramos durante nosso curso, as pessoas podem ser um passageiro, um motorista de táxi e uma operadora.
Para formular um requisito adequado, você precisa elaborar um documento que chamamos de Descrição de Recursos. E para isso você precisa responder às seguintes perguntas:
- Pelo que? Qual é o propósito? Quais são os benefícios para o negócio?
- Por quê? Quais são os riscos? O que perderemos se não o fizermos? O que acontece se o fizermos?
- O que? Que problema queremos resolver? Para quem?
- Como? Requisitos funcionais e caso de uso (sequência de ações).
Também é necessário prever a presença de um vocabulário de termos da área temática. Isso é especialmente verdadeiro para acrônimos específicos. Por exemplo, o desenvolvedor pode não saber todos os nomes de processos e especificações da indústria siderúrgica ou culinária.
Por fim, o documento precisa fazer uma seção “Aprovações”, na qual, por um lado, os clientes do recurso (stakeholders, clientes, gerente de produto) concordam que a descrição corresponde ao que desejam do produto. Por outro lado, os desenvolvedores (líderes de equipe, arquitetos) confirmarão se a descrição da tarefa nos requisitos é clara e completa. Assim, todos os participantes do processo de desenvolvimento devem dizer: “Sim, entendemos o documento, agora dá para fazer”.
Métricas auxiliares
Ao trabalhar com requisitos, métricas auxiliares ajudam a obter uma execução precisa da tarefa, bem como reduzem o tempo gasto na verificação de conformidade.
- A definição de Pronto é uma breve descrição de como saber se um recurso está funcionando.
- Requisitos não funcionais - requisitos para parâmetros técnicos, como capacidade de resposta da IU, carga de backend, limitações de CPU e RAM. Este é um ponto muito importante, porque se você não expressar os requisitos, poderá obter um monstro - o photoshop embutido em vez de apenas escolher a cor do carro.
- Requisitos de segurança - criptografia, armazenamento de dados pessoais, etc.
- Corner Case - testando casos extremos. O que acontece se o preço do produto for 0? Quantos carros de táxi uma pessoa pode encomendar ao mesmo tempo?
- — , . , , , , — Visa, MasterCard, , .
- . , , , , . , , . , .
- . , “ ”, “ ”.
Requisitos funcionais e não funcionais, casos de uso
Vamos nos deter um pouco nos requisitos funcionais e não funcionais.
Os requisitos funcionais explicam o que precisa ser feito, eles listam as ações da aplicação como uma reação às ações do ator. Esses requisitos são implementados nos cenários de uso listados.
Os requisitos não funcionais capturam as condições sob as quais a solução deve permanecer eficaz ou as qualidades que a solução deve possuir. Os exemplos mais comuns de requisitos não funcionais são:
- escalabilidade,
- confiabilidade, tempo de inatividade mínimo,
- métodos de suporte.
Os casos de uso também são usados para descrever os requisitos. Este é o elemento principal do nosso documento, que preparamos ao gerar uma solicitação de recurso. Os scripts devem fornecer um fluxo passo a passo completo do que um usuário pode fazer com seu aplicativo.
Os scripts personalizados geralmente contêm as seguintes seções:
Seção: Contexto
Responde à pergunta: Qual componente? Qual é a condição?
Exemplo: O usuário não está autorizado.
Seção: Ator
Responde à pergunta: Que pessoa?
Exemplo: usuário regular.
Seção: Pré - condições
Responde à pergunta: Quais são os recursos?
Exemplo: há um convite para receber um status VIP.
Seção:Objetivo
Responde à pergunta: O que o usuário pretende fazer / obter?
Exemplo: Faça login.
Seção: Cenário principal
Responde à pergunta: Quais ações precisam ser tomadas para alcançar o resultado?
Exemplo: Digite seu nome de usuário e senha, pressione o botão "entrar".
Seção: Scripts ruins
Responde à pergunta: O que pode dar errado, uma lista de erros, incluindo o texto das mensagens de erro para o usuário.
Exemplo: O botão não é pressionado, o idioma não muda, a conexão não pode ser estabelecida através do protocolo https, e assim por diante ...
Seção: Layouts
Responde à pergunta: Possíveis layouts ou protótipos de design de IU.
Exemplo: Desenhe na Figma ou Sketch.
De forma simplificada, os scripts personalizados podem ter a seguinte aparência:
Desmascarar
. ( e-mail) ( ). , , : « » « . »
Como a descrição do recurso é lida?
Cada categoria de usuários pode reunir informações úteis para si mesmos a partir dos requisitos. E por isso é muito importante ter em mente que os requisitos serão lidos por pessoas diferentes:
- Desenvolvedores - é importante que eles saibam por que o recurso é necessário e que problema ele resolve. Para não perder tempo com correções posteriores, os desenvolvedores precisam fornecer uma lista completa de todos os cenários, bem como prestar atenção aos casos de canto. Se você informar atempadamente ao desenvolvedor o que acrescentaremos mais tarde, por exemplo, pagamentos com cartão MIR, ele poderá prever essa possibilidade ao nível da arquitetura. Assim, os custos podem ser reduzidos significativamente evitando o retrabalho.
- , QA — , . Corner Cases. , — , .. ( , , ) . , . .
- DevOps Datacenter Operations— , , , . DevOps , , , .
- — , , . , , .
Se você escrever requisitos de desenvolvimento, certifique-se de fazer a pergunta - quem é seu usuário, o que ele faz (ou pode fazer), em que condições ele está. Crie um diagrama de seu comportamento, ele ajudará a descrever todos os aspectos dos requisitos.
Na hora de redigir um documento, é preciso ser o mais curto possível e não deixar lugares incompreensíveis. Os requisitos irão abranger várias páginas de qualquer maneira. Precisa ser lido por muitas pessoas e deve ser legível.
Siga uma regra simples: comece com a coisa principal e só então adicione os detalhes. Além disso, você precisa obter feedback do controle de qualidade, desenvolvedores, DevOps e outras partes interessadas. Provavelmente, a descrição do recurso adquirirá novos detalhes após a comunicação com as partes interessadas.
Tente pensar em cenários não óbvios. É aconselhável determinar imediatamente o que seu aplicativo deve fazer em situações de emergência. Pense em quais componentes externos estão afetando seu recurso. E quando tudo estiver pronto, mais uma vez faça a pergunta: "O que mais você pode testar além das etapas descritas nos scripts personalizados?"
Conclusão
No próximo artigo, falaremos sobre o plano de negócios e os preços do novo produto.
Nesse ínterim, compartilhe nos comentários sua experiência de trabalho com os requisitos, tanto do lado do gerente quanto do executor. Diga-nos, houve um exemplo em sua prática em que um cliente funcional queria uma coisa, mas no final acabou completamente diferente por causa de um mal-entendido?
→ A gravação em vídeo de todas as palestras do curso está disponível no YouTube
Lecture sobre o roteiro e requisitos para o desenvolvimento: