Em 2018, o livro "Desenvolvimento de requisitos de software" foi reimpresso. Os colegas me enviaram um link para a publicação. Os autores adicionaram técnicas para trabalhar em projetos ágeis, determinando o papel do analista e recomendações para automação. Existem
críticas extremamente
conflitantes na Web. Encomendei um livro e descobri a pergunta.
Prós
Tudo é pintado
Os iniciantes terão uma compreensão completa do trabalho do analista. Os profissionais se lembrarão do que eles mesmos enfrentaram. Todos os estágios da criação de especificações são analisados. O Apêndice B contém um manual compilado com base no princípio de solução de problemas. O próprio índice serve como uma dica. Listas de verificação detalhadas estão contidas em quase todos os capítulos. Por exemplo, um modelo de especificação inclui 8 cláusulas, 24 subcláusulas e dois apêndices. Guia abrangente.
Informação fácil de encontrar
As informações são claramente estruturadas e isso facilita a pesquisa do livro. O índice está escrito em 9 páginas. Ele rapidamente encontra o estágio e a explicação certos. Em cada capítulo, há referências a outros capítulos, se houver alguma pergunta descrita em mais detalhes. No final do manual, há um glossário de termos, para que você não tenha medo de frases como "UML", "ciclo de vida do projeto em cascata" ou "matriz CRUD". Em alguns minutos, há uma versão em PDF das edições anteriores. Você pode usar a pesquisa de documentos se precisar de dados específicos.
Para todos em TI
Os analistas entram em contato com todos os envolvidos no projeto: clientes, designers, desenvolvedores, testadores, vendedores, suporte e usuários do produto. E cada grupo deve saber como correlacionar adequadamente os termos de referência com o que estão fazendo. Um funcionário inexperiente pode perguntar algo como: "E onde está escrito para nós que, quando você clica neste item, nada deve acontecer?" Se ele ler o livro, ele responderá a essa pergunta e deixará comentários razoáveis sobre o documento.
Explicação dos Termos
É difícil ler o manual por hábito, mas depois da 700ª página fica mais fácil :) No decorrer da apresentação, cada conceito é apresentado entre parênteses em inglês, o original. Isso é conveniente porque o tradutor nem sempre é preciso e você pode abrir a Wikipedia em inglês. No final do livro, há um glossário de termos com explicações. É verdade que nem todos os conceitos são encontrados no manual. Para complementar a lista, tive que adicionar 50 novas frases e números de páginas manualmente.
Contras
Verbosidade
Os autores abusam de frases longas e informações desnecessárias. Por isso, o significado é mais difícil de entender.
“As ferramentas de gerenciamento de requisitos ajudam a rastrear requisitos, possibilitando identificar relacionamentos entre diferentes tipos de requisitos, entre requisitos em diferentes subsistemas e entre requisitos individuais e componentes de sistema relacionados (como design, módulos de código, testes e documentação do usuário).”
Leo Tolstoi, e você?
"... os métodos de comunicação podem fornecer sincronização eficaz no tempo e no espaço dentro da equipe".
E na folha em branco está escrito que este é um manual, não um tratado filosófico.
"Diagrama de estado para o status de pedidos de comida."
Os autores não repetem duas vezes, não repetem.
"Stephen Withall (2007) descreve muitos esquemas para documentar dados com precisão (também chamados de informações)."
Dados = Informação. E há algo a fazer!
E esse ruído semântico ao longo do livro. Há uma suspeita de que os autores foram pagos pelas falas.
Erros gramaticais
No decorrer da leitura, contei mais de 160. Todos os erros no currículo da escola. Por exemplo: palavras são puladas, "-tsya" é usado em vez de "-tat", frases são repetidas em um parágrafo, erros de digitação comuns são encontrados, vírgulas são puladas, conceitos escritos de maneira semelhante são confusos.
O primeiro erro ocorre assim que você abre o livro. Chris não tem megalomania, eles apenas a confundiram com Karl, que dedicou um livro a ela. Eles são cônjuges.
Como você gosta dessa frase?
"Redesenhe o sistema para melhor processamento de regras comerciais voláteis que eram um suporte complexo ao projeto".
Colocação do produto
No decorrer da apresentação, os autores mencionam repetidamente os produtos da Microsoft. Eles são tão famosos que não faz sentido escrever sobre eles. E quando é necessário nomear os sistemas de gerenciamento de requisitos (SUT), os autores ficam calados sobre eles. Eu só li este capítulo por causa deles. O livro acabou de ser lançado pela Microsoft Press, enquanto os "soft" não possuem um SUT completo. A lealdade da empresa superava a dívida profissional.
Eufemismo
Por exemplo, no Apêndice B, os autores fornecem um exemplo de documentação de requisitos. Eles escrevem que os clientes devem poder alterar as assinaturas. Mas não se diz sobre a criação de assinaturas. Como posso alterar algo que ainda não foi criado? Ignorou a fase inicial.
Ou é indicado que o sistema deve permitir ao cliente especificar um método de pagamento. Mas não está escrito sobre confirmação de pagamento. Qual é o sentido de indicar como você deseja pagar se o pagamento não puder ser confirmado? Perdeu a etapa final.
As etapas restantes são detalhadas no aplicativo em alguns detalhes. Nesse contexto, os elos que faltam na cadeia de opções deixam um sentimento de subestimação. É claro que os aplicativos são dados como exemplo, mas ainda assim.
O que é relevante para a Rússia?
Antes de ler, pensei algo assim: “O que um americano pode nos aconselhar? Eles têm tudo em números, e não há problema. ” Descobriu-se que os problemas são praticamente os mesmos.
Nenhuma cultura de respeito aos requisitos
Como um desenvolvedor familiar disse: "Não leio TK, mas escrevo imediatamente o código". Esta não é uma abordagem equilibrada. A implementação não é coordenada com as partes interessadas, opções adicionais não estão sendo estudadas e as comunicações com outros elementos são negligenciadas. O risco de erro e seu preço aumentam. Se o usuário encontrar um erro após o lançamento, seu preço aumentará 21 vezes. Na fase do TK, eliminá-lo é muito mais barato. Mas, embora as empresas não levem a sério a especificação, ela será "desejada o melhor, mas acabou como sempre".
Sem requisitos de negócios
Os requisitos de negócios descrevem por que uma organização precisa de um sistema, isto é, metas que uma empresa pretende alcançar com ele. Mas se você olhar para empresas russas de tamanho médio, terá uma impressão estranha. Alguns não entendem por que produzem, enquanto outros não entendem por que compram. Mas as ambições são infladas e apostam em selos no Instagram. Acontece que você se comunica com outro gênio de Skolkovo, e ele impõe apaixonadamente necessidades imaginárias em seus clientes. Como resultado, a empresa parece um vegetal, e o orçamento parece um balde holey.
"Anexar" ao design
Isso é impossível, porque após o reprojeto, você precisa editar o TK. Isso é uma perda desnecessária de tempo. A especificação não precisa depender do design. Permita que os projetistas tenham uma escolha de como implementar esse ou aquele requisito. Por exemplo, o elemento de controle "Excluir" pode ser representado como um item de botão, ícone, link, furto ou menu de contexto. É melhor descrever isso através de funções e circuitos, em vez de interfaces. Não "o sistema exibe uma lista suspensa", mas "o sistema oferece uma opção".
Nenhuma compreensão das especificidades do analista
Por exemplo, em uma empresa, os analistas expandiram suas responsabilidades. Eles foram instruídos a informar as autoridades sobre quando esse ou aquele requisito está sendo implementado e por quem. Se houve um atraso, eles descobriram o porquê. A tarefa foi transferida em etapas e pessoas responsáveis de outros departamentos foram nomeadas. Como resultado, a parte do conteúdo sofreu. Tudo o que é descrito é de responsabilidade do gerente de projetos. O gerente é responsável pela troca de informações sobre o projeto, o analista é responsável pela troca de informações sobre o produto. Estas são duas linhas de negócios diferentes.
Nenhuma ferramenta usada
Um chefe queria que aqueles que trabalhavam com a TK os conhecessem perto do texto. Isso não é realista. A empresa possui várias dezenas de TK, e seu número está aumentando. Se você mesmo terminou de desenhar o TK há um mês, ainda o esquece, porque então mergulha em 2-3 novos. O problema foi resolvido não devido à memória, mas devido à implementação de sistemas de gerenciamento de requisitos (SUT). Eles suportam a identificação, gerenciamento, rastreamento e retirada de requisitos. Mas você tem que pagar por eles, e os empregadores preferem trabalhar à moda antiga, como em um ditado:
Dois soldados do batalhão de construção substituem a escavadeira.
E uma das forças transportadas pelo ar as substitui duplamente.
Post scriptumEscrevi para os editores da versão russa do livro sobre os erros e sugeri corrigi-los. A solicitação foi lida, mas a equipe não respondeu. Portanto, consideram o analfabetismo a norma. Isso é triste porque o original é bom.
Conclusão
O livro deixa uma impressão controversa devido à sua desordem. O conteúdo é alto, mas o formulário não é. Isso é assustador. Mas, se um especialista quiser atuar como analista, ele terá que entender o que os autores querem dizer. Não é fácil, mas o tempo gasto vale a pena, e você se respeitará um pouco mais.