🌾 ✊🏽 ⤴️ Programa educacional para especificações técnicas 〰️ 🤫 🤚

Benefício: obtenha conhecimento sobre o que é TK e como compilá-lo. Enriqueça seu vocabulário com palavras: modelo conceitual, fluxo de dados, cartão mental, fluxo do usuário. casos de uso, wireframes, modelo ER, servidor-cliente, API.

Para quem: desenvolvedores iniciantes e aqueles que querem ser entendidos (por clientes, startups e gerentes).

Tempo de leitura: 7 minutos.

Ponto de partida - requisitos

Eu quero um bolo, depois sorvete!
Vovka no Reino Distante

Existe um equívoco comum de que basta dizer: "Você precisa de um aplicativo para um museu / gato / planta" e fica imediatamente claro o que você precisa.

Infelizmente, isso não é tão simples. Imagine que você precisa construir uma casa. Você vai ao construtor, e ele começa a trabalhar. Você não forneceu a ele nenhum desenho ou enredo, nem mesmo disse qual a cor da cerca. Mas eles deram tudo por seis meses e uma quantia significativa de dinheiro.

Spoiler

Terrivelmente verdade? O orçamento já foi gasto e o prazo expirou.

Para impedir que isso aconteça, todos os requisitos do produto são corrigidos, é com isso que qualquer desenvolvimento começa.

Tipo conveniente de requisitos - TK

Amasse e pique!
Vovka no Reino Distante

Boa. Existem requisitos. Agora os desenvolvedores definitivamente entenderão você. Mas aqui vem a armadilha nº 1: a humanidade ainda não aprendeu a ler mentes. Portanto, é necessário, de alguma forma, transmitir informações e a melhor maneira para isso é os Termos de Referência.

Também é chamado de TK, SRS, PRD - todos esses são os nomes do documento no qual os requisitos do produto são fixados na forma correta.

Armadilha número 2: a memória de uma pessoa não é ilimitada, é sempre melhor ter um local onde todos os seus desejos e exigências sejam fixos (não correspondência em um telegrama ou telefonema). Portanto, TK é um documento de texto impresso com a aplicação de diagramas e infográficos, não escritos à mão ou fotografados. Melhor no formato .PDF ou Google Docs.

Receita para TK competente

Os termos de referência para desenvolvedores são um tipo de receita para um produto de sucesso. Um produto de sucesso é fácil de manter, pode ser desenvolvido e alterado, não desmorona quando um desenvolvedor muda e gera lucro de qualquer forma. Deseja que seu projeto seja concluído? Bem. Escreva uma boa receita para isso. Os ingredientes clássicos (de acordo com a norma internacional IEEE-830) são:

Modelo conceitual
Cartão funcional
Caminho do usuário
Interface de usuário
Interfaces de software
requisitos não Funcionais

Os últimos 2 pontos são específicos, aconselho-os a prestar atenção aos leitores próximos ao desenvolvimento.

Abaixo, analisarei em detalhes cada um dos itens. Para aqueles que não querem entender em detalhes, deixo um link para o padrão internacional com um modelo de tarefa técnica: link para um documento.

imagem

Modelo conceitual

Este item inclui uma breve descrição do produto, reflete o objetivo do projeto e suas características distintivas.

Por exemplo: "Um aplicativo de namoro onde você pode assistir a vídeos curtos em perfis de usuário e bate-papo". Também é bom dizer algumas palavras sobre o público do produto, para que a equipe do projeto possa entender seus recursos e fornecer algumas dicas úteis. Conte-nos sobre sua idade, caráter e localização territorial, algumas características que devem afetar o projeto.

Por exemplo: “São jovens que viajam ao exterior para lazer e estão interessados em comunicação fora da barreira do idioma, que gostam de tirar fotos e gravar vídeos.”

Vale a pena falar sobre os tipos de usuários e suas principais diferenças.

Por exemplo:“O aplicativo deve ter usuários regulares e moderadores que recebam reclamações dos usuários sobre conteúdo ou perfis. Os moderadores podem visualizar o bate-papo de usuários comuns após uma reclamação e bloquear uma conta que viole as regras do serviço. ”

E, finalmente, conte-nos sobre os componentes do seu produto.

Por exemplo: painel de administração usado por moderadores; Um aplicativo móvel que o usuário usa para registrar, adicionar conteúdo, participar de bate-papo etc.

As acrobacias serão feitas pelo chamado fluxo de dados ou gráfico de contexto, que refletirá como os usuários interagem com o produto, seus componentes e entre si.

Cartão funcional

O mapa funcional exibe o conceito geral do projeto com o nível de detalhe necessário para avaliar o escopo do trabalho e priorizar Em um formato tradicional, esse mapa se assemelha a um mapa do site. Mas é mais conveniente exibi-lo na forma de um cartão mental (cartões mentais, cartões de inteligência). Freqüentemente, os gerentes desenham palavras na reunião em um quadro-negro ou pedaço de papel e as conexões entre eles; portanto, este é o mapa mental. Isso pode ser feito convenientemente em serviços gratuitos (coggle, draw.io e mindmeister) ou simplesmente no Office Word.

É muito importante refletir todos os recursos do usuário no mapa funcional. Em uma primeira aproximação, isso é simplesmente um conjunto de recursos do produto.

Por exemplo: “O aplicativo deve incluir o registro por correio, criar e preencher dados de perfil, a capacidade de carregar e editar fotos e vídeos, uma lista de contas de outros usuários com vários tipos de filtros, bate-papo por texto e entrar em contato com o suporte.

imagem

Caminho do usuário

O chamado fluxo do usuário, ou caminho do usuário, é uma lista seqüencial de ações ou telas pelas quais o usuário pode passar ao interagir com o produto. Descreva como o usuário irá interagir com o produto em sua apresentação. Muito convenientemente, isso também pode ser feito com um mapa mental ou apenas uma lista de ações.

Por exemplo: “Um usuário efetua login para conhecer colegas. Ele preenche seu perfil com dados e envia fotos e vídeos. Em seguida, o usuário insere o feed e o filtra de acordo com alguns critérios. Como resultado, ele recebe uma lista de perfis relevantes, pode olhar para eles e escrever para outro usuário no chat.

O caminho do usuário é um algoritmo geral para trabalhar com o produto. Também existem casos de uso (casos de uso) - este é um detalhe do fluxo do usuário. No caso de um aplicativo de namoro móvel, você criou o caminho do usuário pelas telas e descreve o que o usuário pode fazer em cada tela.

Por exemplo: na tela de registro, o usuário pode:
acessar a tela de autorização , registrar -se nas redes sociais (Facebook, Twitter), inserir o e-mail, a senha, depois repeti-lo e confirmar o registro no e-mail.

imagem

Interface de usuário

O produto não deve apenas funcionar, mas também ter uma boa aparência. Vamos nos afastar um pouco do assunto dos aplicativos, para não forçá-lo a fazer o download deles para revisão. Melhor olhar para sites fofos:

Vimos um exemplo de design deficiente, agora limpamos o sangue dos olhos e passamos à discussão da interface. Nesta parte da tarefa técnica, vale a pena anexar árbitros - exemplos de como você deseja ver seu produto. Pode ser análogos de desenvolvimentos semelhantes ou apenas exemplos cujo design você gostou.

Descreva em termos gerais como deseja ver seu produto, que cores ele deve ter, quais elementos usar, que animação você deseja etc. Se você possui um livro de identidade ou marca corporativa, excelente, consulte-os.

Os designers agradecerão muito se você especificar um estilo de design de interface, como design plano ou design de material.

As acrobacias adicionarão wireframes (wireframes) - protótipos da interface do produto na forma de circuitos aproximados.

imagem

Interfaces de software

Esta seção é para profissionais. Se você tem confiança em suas habilidades, continue lendo.A melhor tarefa técnica também descreve a arquitetura do produto, ou seja, em quais componentes de software ele consiste. No caso de um aplicativo de namoro cliente-servidor, o serviço é dividido em uma parte do servidor que armazena dados e os processa, executa algumas operações lógicas e uma parte do cliente que exibe os dados.

O servidor é decomposto em módulos: bancos de dados, autenticação, bate-papo, etc. Manipulação de erros.

Os dados geralmente são armazenados no banco de dados na forma de estruturas especiais, geralmente tabelas (para bancos de dados relacionais) e estruturas json (para não relacionais). Os desenvolvedores agradecerão muito se, na tarefa técnica, você especificar as entidades do banco de dados (modelos ER) e descrever os campos armazenados, indicando seus tipos de dados (string, int, etc.), chaves (primárias, estrangeiras), obrigatórias (obrigatório ) e anulável.

imagem

requisitos não Funcionais

Estes são requisitos gerais do produto. Eles podem ser divididos em requisitos técnicos, requisitos de segurança e desempenho.Os requisitos técnicos indicam desejos para dispositivos e o ambiente operacional, por exemplo, para aplicativos de namoro, como Android 7.0+ e JDK 8+, iOS 11.0+ e Swift 4.2.

Nos requisitos de segurança, você pode especificar que a transferência de dados no bate-papo deve ser feita usando criptografia SHA-1 e que, ao se registrar, a complexidade da senha deve ser de pelo menos 8 bits.Os requisitos de desempenho falam sobre a conexão de componentes e a tolerância a falhas, por exemplo, indicam que o tempo limite para ler uma mensagem de bate-papo por mais de 1 se o aplicativo armazena parcialmente o cache e pode trabalhar offline por um tempo limitado.

Adendo

PDF, . , .
, , , .
-, , .
, , .
. , .
Prepare-se para passar mais de alguns dias ou consulte um profissional para escrever um artigo. Termos de referência competentes evitarão longas discussões de detalhes com os desenvolvedores e delinearão critérios claros para a entrega do projeto. Por exemplo, um TOR completo de acordo com a norma IEEE-830, anexado ao contrato de desenvolvimento, é um argumento em tribunal em caso de falha no cumprimento dos requisitos.

Programa educacional para especificações técnicas