--- title: Документация и стандарты questionDates: q-transfer-0331: '2026-10-01' q-transfer-0351: '2026-10-01' q-transfer-0352: '2026-10-01' q-transfer-0368: '2026-10-01' seo: description: >- Тема «Документация и стандарты» для собеседования Systems Analyst. Чем ГОСТ 19 отличается от ГОСТ 34? Приходилось ли вам писать спецификации? title: Документация и стандарты — Systems Analyst --- [Все темы Systems Analyst](/prep/systems-analyst) ## Чем ГОСТ 19 отличается от ГОСТ 34? [#q-14bee738d69b81b4a36cf4fd31d4e781] ГОСТ 19 и ГОСТ 34 в этом контексте обозначают комплексы стандартов, а не два отдельных документа: 1. ГОСТ 19, Единая система программной документации, задаёт виды программных документов и требования к их содержанию и оформлению. Объектом документирования является программа или программное изделие. 1. Комплекс ГОСТ 34 на автоматизированные системы охватывает их создание и документирование, включая виды и комплектность документов. Это не общее обозначение стандартов шифрования и информационной безопасности. При выборе уточняют объект разработки и конкретные стандарты с годом редакции, предусмотренные договором: программу либо автоматизированную систему в целом. :::note[Ссылки для изучения] 1. [ГОСТ19.101-2024: область применения и виды программных документов](https://meganorm.ru/Data/838/83832.pdf) 1. [ГОСТ34.201-2020: документы при создании автоматизированных систем](https://www.swrit.ru/doc/gost34/34.201-2020.pdf) ::: --- ## Приходилось ли вам писать спецификации? [#q-14bee738d69b81bfb89ce12e4e7a397f] Назовите спецификации, которые действительно писали, их аудиторию и свою роль. Можно рассказать о требованиях, интерфейсах, схемах данных и критериях проверки, если они входили в вашу работу. :::note[Ссылки для изучения] 1. [SRS: пример структуры спецификации требований в ERP-проекте — NAUKA](https://habr.com/ru/amp/publications/985034/) ::: --- ## Какие документы по ГОСТУ вы писали? [#q-14bee738d69b813c8609dffd6993dd5c] Возможный пример: техническое задание на информационную систему. Назовите реальный документ и точный ГОСТ с редакцией, по которому работали. Следующий перечень является общим примером содержания и не воспроизводит обязательную структуру конкретного ГОСТ. Цель документа: Определить требования к разработке новой информационной системы для автоматизации управления складскими запасами. Содержание: {/* prettier-ignore */} 1. Введение - Описание задачи и необходимости разработки новой системы. - Краткий обзор текущих проблем и недостатков в управлении складскими запасами. 1. Основные требования - Функциональные требования: описание основных функций системы, таких как учет поступления и отгрузки товаров, инвентаризация, генерация отчетности. - Нефункциональные требования: требования к производительности, надежности, безопасности и пользовательскому интерфейсу. 1. Архитектура системы - Описание общей архитектуры системы, включая серверную и клиентскую части, базы данных и интерфейсы взаимодействия. 1. Интеграция - Требования к интеграции новой системы с существующими информационными системами компании. 1. Тестирование - План тестирования: описание методов тестирования функциональных и нефункциональных требований, критерии приемочного тестирования. 1. План разработки - Расписание работ и этапы разработки: оценка сроков выполнения работ, распределение задач между командами разработчиков. 1. Заключение - Общие выводы и рекомендации по разработке и внедрению системы. :::note[Ссылки для изучения] 1. [ГОСТ34.602-2020: состав и содержание ТЗ на автоматизированную систему](https://www.swrit.ru/doc/gost34/34.602-2020.pdf) ::: --- ## Как бы вы сделали регистрацию программного обеспечения? [#q-14bee738d69b810e856ac2bc82c8d377] Сначала уточните, что означает регистрация ПО: учётная запись в продукте, лицензирование или официальная регистрация самого ПО. Ниже описана только регистрация пользовательского аккаунта; это не процедура регистрации программного обеспечения. {/* prettier-ignore */} 1. Идентификация пользователя: - Запрос данных о пользователе (имя, email, пароль). - Проверка уникальности email. - Хеширование пароля перед сохранением в базу данных. 1. Подтверждение email: - Отправка письма с ссылкой для подтверждения email. - Активация аккаунта после перехода по ссылке подтверждения. 1. Управление доступом: - Ролевая модель доступа (администратор, пользователь). - Возможность смены пароля и восстановления доступа. 1. Защита данных: - HTTPS для защищенной передачи данных. - Хранение паролей в хешированном виде. - Защита от атак перебора паролей и SQL-инъекций. 1. Дополнительные меры безопасности: - Двухфакторная аутентификация. - Мониторинг активности пользователей и журналирование событий. 1. Пользовательский интерфейс: - Интуитивно понятная форма регистрации и входа. - Возможность настройки профиля пользователя. :::note[Ссылки для изучения] 1. [Регистрация аккаунта: требования, критерии приёмки и интеграции USER-сервиса](https://habr.com/ru/articles/992264/) ::: --- ## Что включить в программу и методику испытаний? [#q-transfer-0331] ПМИ задаёт общий контур приёмки системы. В ней фиксируют объект и объём испытаний, проверяемые требования, состав среды, версии компонентов, тестовые данные и ограничения. Для каждого сценария нужны предусловия, шаги, ожидаемый результат и однозначный критерий прохождения. Также указывают роли участников, порядок регистрации и устранения замечаний, критерии входа и завершения испытаний. Результат оформляют протоколом: какие проверки проведены, какие отклонения остались и принято ли решение о приёмке. :::note[Ссылки для изучения] 1. [Состав ПМИ и протокол испытаний — раздел1.5 авторского курса А.Радзишевского](https://habr.com/ru/articles/1003922/) ::: --- ## Какие разделы включить в SRS? [#q-transfer-0351] SRS обычно содержит цель документа, границы и контекст системы, термины и заинтересованных участников. Основная часть описывает функциональные требования, внешние интерфейсы, данные и бизнес-правила. Отдельно фиксируют нефункциональные требования: производительность, безопасность, доступность, аудит и другие измеримые качества. Также нужны ограничения, допущения, зависимости, критерии приёмки и трассировка к источникам или целям. Структуру подстраивают под проект: документ должен отвечать, что должна делать система и при каких ограничениях, не превращаясь в подробное описание реализации, если такое решение ещё не принято. :::note[Ссылки для изучения] 1. [SRS: пример структуры спецификации требований в ERP-проекте — NAUKA](https://habr.com/ru/amp/publications/985034/) ::: --- ## Как Vision and Scope удерживает границы проекта? [#q-transfer-0352] Vision and Scope связывает инициативу с бизнес-проблемой: зачем проект нужен, для кого, какой результат и метрика означают успех. В документе явно перечисляют, что входит и не входит в первую границу, ключевые возможности, ограничения, допущения и заинтересованных лиц. При новом запросе его сравнивают с целями и `in/out scope`: запрос может быть ценным, но относиться к другой инициативе или требовать пересмотра срока и бюджета. Документ не запрещает изменения. Он даёт общую базу для осознанного решения и обновляется, если уполномоченные участники действительно меняют границы. :::note[Ссылки для изучения] 1. [Vision: пример целей, границ и состава выпусков в ERP-проекте — NAUKA](https://habr.com/ru/amp/publications/985034/) ::: --- ## Можно ли совмещать Responsible и Accountable в RACI? [#q-transfer-0368] В RACI `Responsible` выполняет работу, а `Accountable` несёт конечную ответственность и утверждает результат. Один человек может совмещать обе роли, особенно в небольшой задаче, если у него есть полномочия и это не лишает работу независимой проверки там, где она нужна. Для одного результата обычно назначают одного `Accountable`, иначе решение и эскалация размываются. `Responsible` может быть несколько, но тогда полезно уточнить конкретные части работы. Матрица должна отражать реальный процесс, а не формально заполнять все клетки: пустая или совмещённая роль допустима, если ответственность остаётся однозначной. :::note[Ссылки для изучения] 1. [Роли R и A в RACI и пример их совмещения — Timeweb](https://habr.com/ru/companies/timeweb/articles/597281/) :::