Зачем себя ограничивать: ограничения в ТЗ и спецификации требований

обучение бизнес-анализу, курсы бизнес-аналитик, бизнес-аналитик обучение курс, разработка ТЗ курсы обучение, требования ТЗ обучение курс, как написать ТЗ курс обучение, спецификация требований в ТЗ и SRS пример курсы, примеры для аналитика, Школа прикладного бизнес-анализа

Недавно я рассказывала про задачи оценки ограничений решения и ограничений предприятия из BABOK®Guide, которые ориентированы на работу с уже реализованным (хотя бы частично) продуктом. При разработке требований к решению системные и бизнес-аналитики тоже имеют дело с ограничениями, которые следует отразить в спецификации или техническом задании (ТЗ). Что это за ограничения, зачем и как их документировать, читайте далее.

Что такое ограничения и чем они отличаются от допущений, зависимостей и предположений

Согласно общему определению, ограничение – это правило, лимитирующее (ограничивающее) какие-либо действия или чьи-то права. В бизнес-анализе и разработке ПО ограничения можно рассматривать как специфические условия по реализации и/или использованию решения. В этом отношении ограничения похожи на нефункциональные требования, которые описывают качество и характеристики работы ПО.

Однако, ограничения и допущения это не одно и тоже. Когда речь идет о зависимости от внешних факторов, например, стабильность интернет-соединения или язык, который понимают пользователи, это называется зависимостями и предположениями/допущениями. В частности, для разработки собственной конфигурации «1C: Зарплата и Кадры» предположением или допущением может выступать знакомство пользователей с основными понятиями и принципами работы базовой конфигурации этой платформы. Зависимости обычно означают привязку к конкретным компонентам сторонних систем или общедоступных библиотек. Например, конкретная версия Java или OAuth-аутентификация пользователей через сторонние сервисы. А если какие-то условия ограничивают возможности, доступные разработчикам, их называют ограничениями. В терминологии BABOK®Guide это звучит так «ограничения дизайна и реализации».

Штурм BABOK за 5 дней: подготовка бизнес-аналитиков к экзамену на сертификат CBAP/CCBA (IIBA® Endorsed Сourse, 40 PD)

Код курса
CBAB
Ближайшая дата курса
7 февраля, 2022
Длительность обучения
40 ак.часов
Стоимость обучения
75 000 руб.

 

Как описать ограничения, допущения, зависимости и предположения в ТЗ и SRS

На практике в ТЗ на разработку ПО аналитик чаще всего отмечает следующие ограничения, зависимости и предположения:

  • требования к программному и аппаратному окружению, где будет развернуто решение. Обычно это операционная система, СУБД, браузер и другое внешнее ПО, необходимо для выполнения функций системы, т.е. функциональных требований. Например, если отчеты формируются с использованием офисных редакторов, они должны быть предустановлены на компьютере пользователя. Сюда же относятся требования к ресурсам пользовательского узла и сервера: частота ЦП, объем ОЗУ и ПЗУ, минимально необходимая пропускная способность передачи данных по сети, наличие клавиатуры, экрана и других интерфейсов взаимодействия с пользователем.
  • требования к используемым технологиям: языки разработки ПО и сопутствующие фреймворки, что может быть связано с особенностями поддержки и развития реализованного решения. Например, наличие у Заказчика сотрудников с соответствующими компетенциями и/или сложность их поиска на рынке вакансий. Сюда же можно отнести требования к специфическим особенностям реализации, к примеру, поддержка защищенных протоколов 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
Ближайшая дата курса
21 февраля, 2022
Длительность обучения
12 ак.часов
Стоимость обучения
20 000 руб.

Также в ТЗ по ГОСТ 34.602-89 и 19.201-78 описываются требования к программной документации. Чаще всего в этом разделе упоминается о необходимости разработки Руководства пользователя, Руководства Программиста и Руководства Администратора. SRS по IEEE 830-1998 не содержит отдельного пункта по требованиям к программной документации, а SRS по ISO IEEE 29148-2011/2018 имеет такой пункт «Документация для пользователей» в разделе «Общее описание». Подробнее о структуре и назначении этих стандартов читайте здесь.

Проверить, насколько хорошо вы усвоили материал этой статьи, вы можете прямо на нашем сайте, самостоятельно выполнив открытый интерактивный тест на знание стандартов разработки ТЗ и спецификации требований к ПО.

А освоить практические приемы разработки требований и их спецификации в виде ТЗ и SRS вам поможет мой авторский курс «Разработка ТЗ на информационную систему» в нашей Школе прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве.

 

Добавить комментарий

Поиск по сайту

Напишите нам, мы онлайн!