Комментарии 8
Вопросы к автору статьи.
1) Вы требования к тз сами придумали или заимствовали?
Если придумали сами:
какие требования были до Вас.
почему Вы полагаете, что Ваши критерии необходимы и достаточны.
Если заимствовали, то откуда.
----------------
В СССР был стандарт требований к т.з. Вы изучали опыт предшественников?
Пример "мы за все хорошее против всего плохого" :) В реальной жизни это все не работает.
Причина проста и очевидна. Системы чуть сложнее "Hello world" обычно имеют взаимосвязи, зависимости и т.д. И это самое сложное, так как отдельный маленький кирпичик описать можно, но "стена" часто почему-то не собирается. Про это особо ничего
Плюс есть специфика. Web-морду с REST API надо описывать по одному, интеграционные сценарий на какой-то ESP - в принципе по другому, аналитику - вообще другой мир
В реальности работает чек лист + шаблон, который надо сделать под конкретный проект + заранее оговорить с командой, какие требования применяются всегда (логи, безопасность, нотация), чтобы не писать каждый раз
Весьма скептически отношусь ко всяким универсальным советам, т.к. жизнь это все опровергает на раз-два :)
Как по мне, надо в первую очередь ориентироваться на адресатов этих требований, слушать и слышать их реальные нужды и чаяния.
Например, заказчика от бизнеса волнуют в требованиях одни вещи, команду разработки другие, еще и вкусовщина примешивается.
Про атомарность и краткость - за все хорошее, но тоже часто не работает. Иным личностям надо написать 5 раз одно и то же разными словами, чтобы они это все-таки прочитали и сделали как написано. И хоть ты тресни.
В целом - в каждой избушке свои погремушки, т.е. задача аналитика - достичь некоторого консенсуса, чтобы желания бизнеса трансформировались в продукт с приемлемым для бизнеса результатом. И в каждом конкретном случае форма этого консенсуса будет очень даже своя.
Из универсального - описывая требования к фрагментам системы, очень неплохо бы не забывать делать это же самое для всей системы как единого целого. А то фичей на компоненты напилят, а что в целом то должно происходить большинству так и не ясно.
Примеров маловато. С примерами тем кому надо "5 раз описать другими словами" лучше заходит.
Стандарты без примеров это совсем идиллия.
Хорошие пункты вычитки ТЗ. Для закрепления и понимания куда двигаться нужны примеры. Из реальных проектов будут идеальны.
Хороший набор критериев для первой версии требований, на самом деле. Теперь бы шаг вперед и посмотреть в сторону их поддержки.
RUP скажем или ГОСТ 34 предполагал еще что требования должны быть
Трассируемыми
Изменяемыми
Потому что система документации такой же живой организм как и вся система, и большая часть работы на самом деле будет лежать в изменениях требований.
А вы как у себя делаете управление изменениями?
Что за странная глупая мода не писать точки в конце предложений?
Письменная речь — это не код, у неё свои правила. Точка — обозначение законченности выражения. Что даёт таким вот новаторам её упразднение? Оптимизирует текст? Нет. Делает его более читабельным? Нет. Делает его неряшливым и глупым? Да.
Вроде образованные люди должны быть: аналитики, менеджеры, дизигнеры всякие. Покажите мне хоть одного серьёзного западного специалиста, который так похабно обращается с языком.
Бомбит прям.
Хороший универсальный шаблон
Как написать хорошее ТЗ?