Comments 17
Дочитал до момента 'бизнес-требования = функциональные требования' и задумался - стоит ли читать дальше? 🤔
Все это круто, здорово и замечательно, если у заказчика есть время, а для вас деньги. Куда чаще надо сделать что-то, быстро и дешево.
Я прекрасно понимаю, что она неполная и написана c точки зрения системного аналитика,
Я бы сказал, что написана она с точки зрения единственного аналитика на проекте, совмещающего роли бизнес-аналитика, системного аналитика, а также проектировщика интерфейсов, архитектора, тестировщика, техписа и сопровожденца. И РП.
Да согласен по поводу времени и денег, заказчику всегда нужно еще вчера и бесплатно, но никто нам не мешает пропускать этапы, объединять их или на худой конец ТЗ записать на салфетке со слов заказчика и использовать его как конечный "посыл".
Я описываю свой опыт и в итоге этот план может выполнять не один человек, а команда)
По п. 9 "Составление технического задания": зачем изобретать свой собственный велосипед, когда есть ГОСТ 34.602-2020, в котором приведены состав и содержание документа. Необязательно целиком следовать ГОСТу, можно адаптировать под себя.
То же самое относится и к п.13 - есть ГОСТ Р 59795-2021, в котором приведены состав и содержание самых разных документов, разрабатываемых для ИС - берите, адаптируйте под себя и пользуйтесь.
Еще странность - тестирование системы есть, а сдачи/приемки - нет. Сдача/приемка, по опыту, отдельная песня, особенно в случаях, когда у заказчика собственная служба эксплуатации.
ИБ - не включает требования и этапы работ по аттестации ИС.
Можно и еще накидать, но, в общем и целом, получилась этакая смесь 34-ого ГОСТа (ныне ГОСТ Р 59793-2021) и 676-ого ПП. Работать конечно будет, но далеко не для всех систем и не для всех заказчиков.
Замечания в целом оправданы, но я писал исходя из своего опыта.
По поводу ГОСТов подумаю ,что можно еще включить.
Этапы Сдачи и Приёмки реально отдельная песня и как-то унифицировать сложно , но я попробую дописать.
Аттестацию ИС хотел включить , но это в первую очередь для ГОС систем.
ГОСТ 34 это все же автоматизированные системы, что чуть шире, куда включается и организационное обеспечение, и техническое, и метрологическое и т.д.
Когда мы ведем речь об информационных системах, тут я бы еще посмотрел в сторону ЕСПД - ГОСТ 19
Любой статье, где задумываются о требованиях и их формализации сразу плюс.
А так да, есть же 34 ГОСТ, как тут уже написали, он подойдёт в большинстве случаев как основа, которую можно адаптировать.
Начинайте требки с 3х пунктов:
Цели
Назначение
Ограничения
и дальше само пойдет ))
Тоже пару слов вставлю.
1. Техническое задание задание всегда пишет заказчик. А потом открыто публикует или распространяет между ограниченным составом проектировщиков. Затем проектировщик проектирует, с учетом ГОСТов, регламентов, с применением кусков/узлов уже ранее кем-то разработанных и опробованных в реальном деле, на выходе - проект информационной системы/автоматизации/и т.п., именно проект, в том числе со сметой, в том числе календарным планом и самое главное - с доказательствами надежности, повторяемости/отсутствия эвристики, устойчивости, (по аналогии с проектом строительства - конструктивные и архитектурные решения обеспечивающие все разделы безопасности, соответствие требованиям энергоэффективности, малобильных граждан и прочее).
Заказчик может заказать проект одному или нескольким проектировщикам.
Затем выбранный проект заказчик передает в работу нанятому на открытом конкурсе или взятому по знакомству изготовителю-разработчику, который и делает работы (кодит в вашем случае). Авторский надзор осуществляет вышеупомянутый проектировщик - решает возникающие вопросы проекта (если облажался на стадии проектирования - сам и вносит корректировки) и не дает разработчику испортить/завалить проект, подтверждает на каждом крупном этапе результаты работ и подписывается на приемке работ.
Вот как это работает. То что написали вы, работать эффективно не может априори.
Бывают случаи, когда описанные два этапа сливают в один и поручают одному исполнителю, но это как правило исполнитель который уже делал для заказчика что-то серьезное и уже практически все знает и о техпроцессах на производстве/чиновничьем деле и о процессах управления им.
Вторая пара слов.
2. Прямо первый заголовок - "Определение бизнес-требований". Эти мусорные слова везде - и к месту и не к месту (запретить их надо). Бизнес - это использование добавленной стоимости (нанял землекопов, берут больше кидают дальше - хорошо, лопата плохая сил нет - плохо). Бизнес-требования - это требования К бизнесу или требования самого бизнеса? И то и другое - в рассматриваемом случае нонсенс.
У вас по месту правильнее было бы - "требования к конечному продукту" (изделию, дому, информационной системе).
Но - такие требования выставляются для людей, которые хорошо понимают, что от них требуется.
У вас же этот первый раздел - обучение пришедшего и увидевшего первый раз токарный цех парня, хотя бы и классного программиста. Ни к чему хорошему это не приведет и не приводит.
Ну и напоследок.
3. Кто (сторонний, независимый и профессиональный) подтвердит заказчику, что подготовленное вами техническое задание исполнимо и адекватно по деньгам и силам?
Вот объясните простыми словами в 2 предложениях - чем отличаются между собой бизнес аналитик и системный аналитик? Дочитал до момента, когда системный аналитик должен что-то там сделать с интерфейсом и запутался окончательно.
Пункт 4 по идее должен быть включен в пункт 5 (или следовать за ним, но не до него), так как сначала необходимо разработать глобальную архитектуру проекта, где комплексно нужно учитывать различные аспекты, в том числе как проектирование БД
Статья - просто супер. Мне кажется, было бы круто если добавим этап для алгоритма бизнес-процесса и возможные ошибки (указать ошибки и альтернативные сценарии которые могут возникнуть, добавить скрины ошибок). И нужно разработать этап интеграции (взаимодейсвия системы с внешними системами)
Порядок создания технического задания для разработки информационной системы