Комментарии 6
Полезная статья, спасибо. Хотя лучше в подобной документации, как мне кажется, воздерживаться от канцеляризмов. И чем сложнее документ, тем важнее этот пункт. Потому что читать его будут живые люди - разработчики, а это народ ранимый, и у разработчиков мало времени и желания продираться через заросли "данных реквизитов".
Например, лично я бы (в своей практике) переформулировал пример ТЗ следующим образом:
1) В документ "Прием на работу" нужно добавить чекбокс "Реферальная программа" (а может, лучше "партнерка"?) По умолчанию - "галочка" не установлена.
Там же - поле "Реферер" - выбор значения из справочника "Сотрудники". Поле в состоянии "disabled" (кстати, лучше даже еще и hide), пока не поставлена галочка в чекбоксе "Реферальная программа".
Примечание: это поле нужно для указания сотрудника, который пригласил в реферальную программу своего знакомого (кстати, я бы еще эту подсказку написал в самой форме) или в поле в качестве placeholder, если 1С такое умеет).
2) Нужно сделать регистр сведений "Реферальная программа". Структура:
3) Нужно разработать табличный отчет "Реферальная программа". Это четыре столбца:
| № п/п (сквозная нумерация) | Реферал | Реферер | Дата трудоустройства |
Конечно, терминологию использовать 1С-ную, чтобы разработчик даже не вчитываясь текст, мгновенно понял, что там нужно сделать. Чем дружелюбнее ТЗ по отношению к разработчику, тем больше шансов у ТЗ быть понятым и правильно выполненным.
Не хватает во введении о ГОСТ 34.602-2020, а когда начали про ЗУП то упомянуть ГОСТ Р 51583-2014.
Узкоприменимая версия документа от сотрудника 1С. Т.е. хорошо известный и описанный продукт, обеспечивающий автоматизации известных же процессов. А! И продукт что ПО, без аппаратное части и особой интеграции.
Поэтому есть "описание бизнес процесса", а не "характеристика объекта автоматизации", есть "Отчётность" и "Интерфейс", которых вообще может не быть, если, например, ТЗ на шину данных.
Но нет порядка разработки и требований к подготовке объекта. А чего там думать? Не АСУ же делаем! Железа нет, чертежей нет, помещения нет и требований ко всему этому.
Ну и конечно... Требования к документированию нафиг. Развивать ИС или пользоваться ею тривиально, описывать не нужно.
Уважаемый автор! К ГОСТ 34 много претензий, устарел он сильно. А 19 ещё старше и хуже. Да вот беда, нет ничего лучше! Только подобные предстпвленному вами варианты СТП, которые подходят конкретному предприятия и его узким задачам.
Главный вопрос: для кого было ТЗ? Для заказчика? Тогда зачем описание технической реализации? Или у вас с ним отношения вплоть до код-ревью с его стороны?
Я разделяю документы для заказчика и для своего программиста-разработчика. Заказчику попроще и красиво, чтобы поняли суть доработки и обоснованность затрат на реализацию. Для разработчика - именно ТЗ, но хотелось бы на разжёвывать до каждого реквизита. Если он не понимает какой регистр создать для хранения референтов, то мне проще ему словами объяснить задачу, чем бумагу марать. Особенно, если за это не платит заказчик
ТЗ, за которое НЕ стыдно. Простые шаги к понятному техзаданию