Get best of the week

Requisitos de software do dedo

Um post sobre o básico do desenvolvimento de requisitos - sem diagramas, termos e tabelas complexos, mas com gifs.

imagem

Em resumo, as principais etapas no desenvolvimento de requisitos são:

  1. Por que temos que fazer alguma coisa? (Precisa de mais ouro)
  2. O que nós fazemos? (tudo é como as pessoas fazem, mas mais barato)
  3. Como vamos fazer isso? (com blockchain e especialistas em dados, é claro)
  4. Quando faremos isso? (ontem e refatorar "mais tarde")

E agora com mais detalhes.

Se você já pediu para fazer algo, significa que você criou requisitos. Eles podem estar na forma de um desejo oral, carta, tarefa técnica, tarefa ou qualquer outra coisa.
Portanto, os requisitos estão em toda parte.

imagem

Se, depois de atender à solicitação, algo desse errado - isso atrapalhava o executor
ou você definia a tarefa incorretamente.

Como você sabe, a tarefa errada pode ser bastante cara. Por exemplo, se por meio ano uma equipe de 5 programadores desenvolveu um sistema que ninguém precisava.

Nesta era turbulenta, os requisitos de design ágil são frequentemente negligenciados. Mas metodologias flexíveis nem sempre o salvam de grandes perdas. Portanto, mesmo que você não tenha um analista no projeto, mesmo que não seja de TI, não se esqueça do bom senso e retire das melhores práticas o que você precisa no momento.

Então, quais são os requisitos e por que é importante poder desenvolvê-los?

Então, vejamos as fontes:

imagem

Ou seja, você pode falar sobre requisitos e sobre propriedades futuras. Que tal um produto que atenda às metas de desenvolvimento.

Por onde começar a desenvolver requisitos? Uma dica está oculta na definição: você precisa começar com o objetivo - por que precisamos fazer alguma coisa?

1. porque


imagem

Como "o mais rápido possível !!!!" não havia necessidade de fazer algo - é importante encontrar tempo e energia para descobrir por que isso é necessário.

Porque muitas vezes, depois de esclarecer a meta, a tarefa muda ou é completamente eliminada.
Por exemplo, o

Cliente mostrará imediatamente todos os pedidos que foram feitos no sistema. Digamos que enrijecemos e empurramos uma tarefa no meio de um sprint para exibir todos os pedidos do administrador. Depois disso, o cliente pede para exibir em uma janela separada uma lista de todas as empresas cujos pedidos ele vê. Eles fizeram isso também. Em seguida, o cliente solicita a retirada de todas as empresas parceiras. Ok ... Depois de algum tempo, nos reunimos com o cliente e vemos como ele carrega as duas listas no Excel, reconhece a diferença e começa a telefonar para empresas que não têm pedidos para lembrá-los de fazer pedidos pelo sistema.

Se perguntássemos ao cliente, desde o início, qual o objetivo que ele deseja alcançar analisando todos os pedidos, pouparíamos muito tempo e esforço relatando imediatamente às empresas que não fizeram pedidos até o momento.
Você pode usar o método “Five Why” ou qualquer outro. Mas geralmente as pessoas não resistem: se você mostra interesse no trabalho delas, uma solução fica disponível.

Tendo decidido sobre uma meta, é necessário defini-la claramente e estabelecer critérios pelos quais você possa dizer com precisão que a meta foi alcançada.

Por exemplo, o

processo de pedido de materiais é considerado automatizado se> 90% das empresas parceiras fizerem pedidos pelo sistema.

Isso facilita a compreensão das tarefas e, ao mesmo tempo, libera as mãos na escolha dos meios para atingir a meta.

E sim, não esqueça de coordenar essa beleza com os clientes. Em geral, não se esqueça de coordenar os requisitos com todas as partes interessadas.

2. o que?


O objetivo é alcançado de diferentes maneiras. E o segundo passo importante no desenvolvimento de requisitos é apenas sobre a escolha do caminho - o que exatamente faremos para alcançar a meta.

imagem



, :

. . . // .

. — , .

. . .

Para pensar em todas as opções, você precisa descobrir - o que está acontecendo agora? Como o processo funciona sem o seu sistema, como usuários e clientes funcionam? Mesmo se ainda não houver processo, informações detalhadas sobre o estado atual são muito importantes. Portanto, entenderemos qual solução resolverá o problema e não criaremos outra.

imagem

Cada opção de implementação tem seus prós e contras, seus recursos necessários e seu nível de resultado. Tendo modelado todas as opções, elaborado ou, pelo menos, acabado de falar essas informações com as partes interessadas, você poderá fazer uma escolha equilibrada e informada.

3. como


Então, entendemos nosso objetivo e o que faremos para alcançá-lo. Resta descobrir como estamos implementando isso: quais páginas mostraremos aos usuários, de que forma exibiremos o relatório para o cliente, como receberemos dados de outro sistema, como armazená-los e assim por diante.

Esta etapa é uma questão de tecnologia. E se você tiver concluído com êxito os dois anteriores, será muito mais fácil.
Embora a técnica dependa do contexto, é útil seguir a "lista de verificação" de Wigers e outras pessoas inteligentes. Se para você algum tipo de requisito não é relevante no momento - tudo bem, não o descreveremos. Mas é importante não esquecer e testar a si mesmo.

imagem

por exemplo

  • O questionário deve conter um arquivo com uma foto, pois é necessária uma foto ao processar documentos - este é um requisito comercial . E talvez uma regra de negócios.
  • - , — . , .
  • , — , . , .
  • base64 . — .
  • , . : 10.

Para cada requisito comercial, como regra, existem vários requisitos do usuário. Um requisito do usuário é decomposto em vários requisitos funcionais. Para cada requisito funcional, requisitos e limitações não funcionais devem ser considerados.

Além disso, requisitos e restrições não funcionais podem fluir diretamente dos requisitos do usuário e dos requisitos e regras de negócios.
Dessa maneira, as árvores são obtidas dos requisitos, na parte superior de cada um deles é um requisito de negócios.

imagem

4. quando?


Na “floresta” de seus requisitos, é provável que existam mutuamente exclusivos e repetitivos. Portanto, é útil documentar e apresentar toda essa beleza na forma de tabelas e diagramas.

Existem muitas ferramentas aqui: por exemplo, BPMN para descrever processos de negócios e UML para criar esquemas de interações entre serviços e componentes.

Se você conseguir explicar a todos o que e como você deseja fazer com o sistema, usando um guardanapo e três manchas de café, então você é John Wick da análise e isso é incrível.

imagem

No entanto, como regra, o nível de detalhe "pontual" não permite que você veja as armadilhas e pense em todos os cenários possíveis. Afinal, tudo parece estar claro, mas desenhei um pequeno diagrama - e aqui você tem um desafio sem fim, um ramo de processo esquecido e o caminho mais curto para o ouro.
Portanto, é útil saber quais ferramentas estão disponíveis para reverter o caos.

De uma forma esquemática e estruturada, os requisitos precisam ser priorizados - dependendo do utilitário (o cliente e os usuários lhe dirão isso) e a complexidade (a equipe de desenvolvimento o informará).

imagem

E então você já pode se espalhar por sprints / estágios de desenvolvimento e implementação. Bem, repita esses exercícios em cada iteração. E você será feliz - sem alterações, um cliente satisfeito, uma equipe feliz, um produto que funcione e beneficie, os elfos tocam harpa em um fundo de arco-íris.

imagem

Claro, sempre haverá problemas. Haverá alterações, prazos queimados e bugs. Nem sempre será possível passar por todas as etapas e fazer análises normais, concordar ou até mesmo conversar com o cliente, documentar e rastrear os requisitos. Mas em qualquer situação, entender "como deve ser" ajuda a melhorar o produto. Mesmo que, no momento, você esteja fazendo o que está acontecendo - você está ciente de que está perdendo e conhece os riscos. E se você conhece os riscos, pode gerenciá-los.

Eu recomendo a leitura mais sobre requisitos no livro de Wigers e Beatty: "Desenvolvimento de requisitos de software". Embora o livro nem sempre seja simples, mas muito útil. A maioria dos outros materiais sobre o tema é recontar essas verdades com graus variados de liberdade.

Obrigado por sua atenção e bom design.

More articles:


All Articles