Недавно я рассказывала про задачи оценки ограничений решения и ограничений предприятия из BABOK®Guide, которые ориентированы на работу с уже реализованным (хотя бы частично) продуктом. При разработке требований к решению системные и бизнес-аналитики тоже имеют дело с ограничениями, которые следует отразить в спецификации или техническом задании (ТЗ). Что это за ограничения, зачем и как их документировать, читайте далее.
Что такое ограничения и чем они отличаются от допущений, зависимостей и предположений
Согласно общему определению, ограничение – это правило, лимитирующее (ограничивающее) какие-либо действия или чьи-то права. В бизнес-анализе и разработке ПО ограничения можно рассматривать как специфические условия по реализации и/или использованию решения. В этом отношении ограничения похожи на нефункциональные требования, которые описывают качество и характеристики работы ПО.
Однако, ограничения и допущения это не одно и тоже. Когда речь идет о зависимости от внешних факторов, например, стабильность интернет-соединения или язык, который понимают пользователи, это называется зависимостями и предположениями/допущениями. В частности, для разработки собственной конфигурации «1C: Зарплата и Кадры» предположением или допущением может выступать знакомство пользователей с основными понятиями и принципами работы базовой конфигурации этой платформы. Зависимости обычно означают привязку к конкретным компонентам сторонних систем или общедоступных библиотек. Например, конкретная версия Java или OAuth-аутентификация пользователей через сторонние сервисы. А если какие-то условия ограничивают возможности, доступные разработчикам, их называют ограничениями. В терминологии BABOK®Guide это звучит так «ограничения дизайна и реализации».
Как описать ограничения, допущения, зависимости и предположения в ТЗ и SRS
На практике в ТЗ на разработку ПО аналитик чаще всего отмечает следующие ограничения, зависимости и предположения:
- требования к программному и аппаратному окружению, где будет развернуто решение. Обычно это операционная система, СУБД, браузер и другое внешнее ПО, необходимо для выполнения функций системы, т.е. функциональных требований. Например, если отчеты формируются с использованием офисных редакторов, они должны быть предустановлены на компьютере пользователя. Сюда же относятся требования к ресурсам пользовательского узла и сервера: частота ЦП, объем ОЗУ и ПЗУ, минимально необходимая пропускная способность передачи данных по сети, наличие клавиатуры, экрана и других интерфейсов взаимодействия с пользователем.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 мая, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
- требования к используемым технологиям: языки разработки ПО и сопутствующие фреймворки, что может быть связано с особенностями поддержки и развития реализованного решения. Например, наличие у Заказчика сотрудников с соответствующими компетенциями и/или сложность их поиска на рынке вакансий. Сюда же можно отнести требования к специфическим особенностям реализации, к примеру, поддержка защищенных протоколов HTTPS и Kerberos или соответствие API концепции RESTful для интеграции с другими информационными системами.
- требования к пользователям, например, умение работать с офисными приложениями или аппаратными устройствами, на которых работает решение (сканер штрих-кода, мобильный планшет и пр.), а также способность пользователей понимать язык интерфейса программного решения.
Стандартизированные шаблоны по спецификации требований и их документированию в виде технического задания и SRS (российские ГОСТ 34.602-89 и 19.201-78, международные стандарты ISO IEEE 29148-2011/2018 и IEEE 830-1998) включают пункты описания ограничений и допущений. Зарубежные ISO IEEE 29148-2011/2018 и IEEE 830-1998 делают это в более явном виде, чем отечественные ГОСТы.
В частности, считающаяся устаревшей, но все равно используемая на практике методика составления спецификаций требований к ПО IEEE 830-1998, рекомендует отдельно описывать ограничения, допущения и зависимости, а также требования к внешним интерфейсам: интерфейсы пользователя, интерфейсы аппаратного обеспечения, интерфейсы программного обеспечения и интерфейсы взаимодействия.
Аналогично, более популярный сегодня международный стандарт по инженерии требований ISO IEEE 29148-2011/2018 рекомендует описывать в отдельных пунктах SRS:
- рамки, ограничения, правила и стандарты. Под ограничениями стандарт понимает любые факторы, которые ограничивают возможности команды разработки, от нормативных политик до соображений безопасности. А про правила читайте в нашей новой статье.
- допущения и зависимости. В частности, стандарт отмечает, что эти факторы не являются конструктивными ограничениями ПО, но любые их изменения могут повлиять на требования SRS. Например, может быть предположение о том, что конкретная операционная система доступна на оборудовании, где развернуто ПО.
- требования к внешним интерфейсам (UX-интерфейсы пользователя, программные интерфейсы, интерфейсы оборудования, интерфейсы связи и коммуникации).
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Также в ТЗ по ГОСТ 34.602-89 и 19.201-78 описываются требования к программной документации. Чаще всего в этом разделе упоминается о необходимости разработки Руководства пользователя, Руководства Программиста и Руководства Администратора. SRS по IEEE 830-1998 не содержит отдельного пункта по требованиям к программной документации, а SRS по ISO IEEE 29148-2011/2018 имеет такой пункт «Документация для пользователей» в разделе «Общее описание». Подробнее о структуре и назначении этих стандартов читайте здесь.
Проверить, насколько хорошо вы усвоили материал этой статьи, вы можете прямо на нашем сайте, самостоятельно выполнив открытый интерактивный тест на знание стандартов разработки ТЗ и спецификации требований к ПО.
А освоить практические приемы разработки требований и их спецификации в виде ТЗ и SRS вам поможет мой авторский курс «Разработка ТЗ на информационную систему» в нашей Школе прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве.
