10 основных техник для разработки требований к ПО

Denis Beskov
Aug 28 · 4 min read

BABOK предлагает порядка 50 техник для работы бизнес-аналитика.

Не все они нужны в работе сразу, поэтому мы предлагаем для целей создания качественных требований к программному обеспечению избранные 10.


I. Описание контекста, целей и рамок программной системы

Согласно Standish Report, одна из важнейших проблем и факторов успеха ИТ-проектов — корректная работа с целями и границами программного решения.

Техника 1. Карточка проекта

Идеальная основа для старта разработки требований к ПО — хорошо проработанные бизнес-требования и концепция ПО. В тех проектах, где таких наработок нет, мы предлагаем использовать их упрощённую замену — карточку проекта.

Какие разделы в ней есть:

  1. Текущая ситуация — автоматизируемая деятельность, заинтересованные лица, текущие решения (как участники деятельности выполняют свою работу сейчас), проблемы
  2. Целевая ситуация — целевые показатели, важные для заинтересованных сторон — как минимум для заказчика и пользователей
  3. Концепция решения — роли пользователей, список основных свойств (ПО), смежные системы

Техника 2. Контекстная диаграмма (Context Diagram)

Один из старейших, простых и эффективных способов показать контекст и рамки программной системы — контекстная диаграмма.

Она показывает 3 аспекта:

  • какие роли пользователей взаимодействуют с программной системой
  • какие внешние программные системы взаимодействуют с программной системой
  • какими данными обменивается создаваемая программная система с окружением

Техника 3. Диаграмма способов применения (Use Case Diagram)

Более свежий формат представления рамок программной системы, фокусирующийся на ключевых результатах её применения для пользователей и смежных систем — диаграмма способов применения.

Диаграмма показывает:

  • роли пользователей, использующих программную систему
  • смежные программные системы
  • ключевые результаты/задачи, которые пользователи и смежные системы получают от неё в формате «Деятельность + Результат»

Диаграмма имеет свои преимущества и недостатки по сравнению с контекстной, поэтому полезно уметь создавать обе, при необходимости сочетая в своём проекте.


II. Функциональная модель программной системы

Традиционно основной объём требований составляют функциональные описания — что должна делать программная система.

Техника 4. ФТ в канонической форме

Самый старый формат, до сих пор не потерявший актуальность — это описание функциональности с помощью выражений вида:

<Программная система> <должна> <действие> <Объект><условия>

и

<Программная система> <должна> позволять <Участник> <действие> <Объект><условия>

Техника 5. Сценарии способов применения (Use Cases)

Канонические функциональные требования достаточно сложны для планирования разработки итерациями и контроля полноты, поэтому описание функциональности в формате сценариев способов применения хорошо дополняет канонические ФТ, выступая их источником/контейнером и задавая хорошую основу для последующей итерационной работы архитектора, тестировщика, технического писателя.

Мы рекомендуем для освоения полный формат юскейса по Вигерсу, Коберна, который включает в себя:

  1. Название
  2. Действующие лица
  3. Предусловия
  4. Основной поток
  5. Расширения

Основное назначение сценариев способов применения по задумке их авторов — проектирование и описание взаимодействия пользователя с программной системой, однако на практике техника может быть успешно использована как для описания интеграций, так и для работы алгоритмов обработки данных.

Подробнее про применение юскейсов можно прочитать в статье «Use case — что это такое и зачем они нужны».

Техника 6. Диаграмма состояний (Statechart Diagram)

Также, как и контекстная диаграмма, одна из старейших в системном анализе и инженерии.

Показывает для выбранного класса данных:

  • допустимые состояния
  • допустимые переходы
  • условия переходов

Обычно строится для 1–2 классов данных, обладающих нетривиальным жизненным циклом (не «новый-обновлён-удалён»).


III. Моделирование данных

Второй важнейший аспект моделирования при создании программной системы, после функциональности — структуры данных.

Требования в общем случае не должны заменять проектирование интерфейсов, бизнес-объектов, и баз данных, но должны давать достаточно информации для последующего проектирования.

Техника 7. Концептуальная модель данных

Концептуальная модель отражает всего 2 компонента:

  • классы данных, с которыми должна работать программная система
  • связи между этими классами

Мы рекомендуем для концептуального моделирования простой формат диаграммы, без уточнения атрибутного состава, методов и типов связей, как в UML Class Diagram.

Техника 8. Словарь данных (Data Dictionary)

Атрибутный состав классов данных не очень удобно поддерживать на диаграмме, но это не значит, что он не нужен.

Для его проработки мы рекомендуем использовать словарь данных, использующий простейшую форму языка описания формальных грамматик Бэкуса-Наура:

<Определяемое> =
<компонент 1> + <компонент 2> + <компонент …> + <компонент N>


IV. Контроль полноты требований

Техника 9. Трассировка классов данных на типовые операции

Есть множество способов измерять и обеспечивать полноту требований, один из самых полезных и простых их них — построение матрицы трассировок перечня классов данных на типовые информационные операции:

  1. создание
  2. обновление
  3. просмотр
  4. поиск
  5. импорт
  6. удаление
  7. архивирование

Матрица помогает принять осознанные решения — есть ли необходимость реализовывать в создаваемой программной системе функцию, отвечающую за конкретную информационную операцию над конкретным классом данных или нет.


V. Качество ПО

Техника 10. Формулирование требований к качеству и ограничениям

Эта техника обычно использует в качестве основы канонический формат требований

Обычно существует большой разрыв между десятками атрибутов качества ПО, которые предлагают семейства международных стандартов ISO 250X0 и проектной практикой, где требования к качеству не предъявляют, что становится проблемой на этапах сдачи и эксплуатации программной системы.

Чтобы сократить этот разрыв, мы предлагаем освоить самые полезные 10 атрибутов качества и 6 ограничений и начать применять выборочно в своих проектах, начиная с 1–2:

  1. Атрибуты внешнего качества: производительность, надёжность, доступность, масштабируемость, безопасность
  2. Атрибуты качества в использовании: результативность, эффективность, скорость обучения, точность, утомляемость
  3. Ограничения: совместимость с оборудованием, системным ПО, ограничения на языки и средства разработки, допущения о квалификации пользователей, состав поставки, лицензионные ограничения

Все эти техники можно освоить на практике за 24 часа в очном или онлайн-формате:

ИТ-анализ

ИТ-анализ

    Denis Beskov

    Written by

    Product Management, Requirements Engineering, Pragmatic Education enthusiast

    ИТ-анализ

    ИТ-анализ

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade