10 основных техник для разработки требований к ПО
BABOK предлагает порядка 50 техник для работы бизнес-аналитика.
BABOK предлагает порядка 50 техник для работы бизнес-аналитика.
Не все они нужны в работе сразу, поэтому мы предлагаем для целей создания качественных требований к программному обеспечению избранные 10.
I. Описание контекста, целей и рамок программной системы
Согласно Standish Report, одна из важнейших проблем и факторов успеха ИТ-проектов — корректная работа с целями и границами программного решения.
Техника 1. Карточка проекта
Идеальная основа для старта разработки требований к ПО — хорошо проработанные бизнес-требования и концепция ПО. В тех проектах, где таких наработок нет, мы предлагаем использовать их упрощённую замену — карточку проекта.
Какие разделы в ней есть:
Текущая ситуация — автоматизируемая деятельность, заинтересованные лица, текущие решения (как участники деятельности выполняют свою работу сейчас), проблемы
Целевая ситуация — целевые показатели, важные для заинтересованных сторон — как минимум для заказчика и пользователей
Концепция решения — роли пользователей, список основных свойств (ПО), смежные системы
Пример карточки проекта:
Карточка проекта
Edit descriptiondrive.google.com
Техника 2. Контекстная диаграмма (Context Diagram)
Один из старейших, простых и эффективных способов показать контекст и рамки программной системы — контекстная диаграмма.
Пример контекстной диаграммы:
Онлайн-аукцион. Контекстная диаграмма.
Система Онлайн-аукцион по разработке ПО Пользователь Регистрационные данные, данные для авторизации Новые словарные…docs.google.com
Она показывает 3 аспекта:
какие роли пользователей взаимодействуют с программной системой
какие внешние программные системы взаимодействуют с программной системой
какими данными обменивается создаваемая программная система с окружением
Подробнее про контекстную диаграмму:
Контекстная диаграмма
Диаграмма может использоваться в документе концепции системы, документе системных требований или вики-документации для…systems.education
Техника 3. Диаграмма способов применения (Use Case Diagram)
Более свежий формат представления рамок программной системы, фокусирующийся на ключевых результатах её применения для пользователей и смежных систем — диаграмма способов применения.
Диаграмма показывает:
роли пользователей, использующих программную систему
смежные программные системы
ключевые результаты/задачи, которые пользователи и смежные системы получают от неё в формате «Деятельность + Результат»
Пример диаграммы юскейсов:
Организация торгов на разработку ПО. Диаграмма юскейсов
Организатор торгов Создать проект Оценить исполнителя Разместить рекламу Соц. сети Онлайн-аукцион для разработки ПО…docs.google.com
Диаграмма имеет свои преимущества и недостатки по сравнению с контекстной, поэтому полезно уметь создавать обе, при необходимости сочетая в своём проекте.
II. Функциональная модель программной системы
Традиционно основной объём требований составляют функциональные описания — что должна делать программная система.
Техника 4. ФТ в канонической форме
Самый старый формат, до сих пор не потерявший актуальность — это описание функциональности с помощью выражений вида:
<Программная система> <должна> <действие> <Объект><условия>
и
<Программная система> <должна> позволять <Участник> <действие> <Объект><условия>
Пример документа функциональных требований:
Функциональные требования. Система учета коммунальных услуг
drive.google.com
Сформулировать точные и правильные требования в канонической форме поможет статья:
Стоп-слова, как маркер проблем в требованиях
Сначала аналитик собирает пожелания стейкхолдеров. После этого их нужно обработать и формализовать, превратить в…systems.education
Или видео:
Техника 5. Сценарии способов применения (Use Cases)
Канонические функциональные требования достаточно сложны для планирования разработки итерациями и контроля полноты, поэтому описание функциональности в формате сценариев способов применения хорошо дополняет канонические ФТ, выступая их источником/контейнером и задавая хорошую основу для последующей итерационной работы архитектора, тестировщика, технического писателя.
iOS приложение словаря Мультитран. Use CasesEdit descriptiondrive.google.com
Мы рекомендуем для освоения полный формат юскейса по Вигерсу, Коберна, который включает в себя:
Название
Действующие лица
Предусловия
Основной поток
Расширения
Основное назначение сценариев способов применения по задумке их авторов — проектирование и описание взаимодействия пользователя с программной системой, однако на практике техника может быть успешно использована как для описания интеграций, так и для работы алгоритмов обработки данных.
Подробнее про назначение юскейсов можно прочитать в статье:
Use Cases
Описание решения задачи пользователя в системе в виде Use Case должно определять: Систему, с которой описывается…systems.education
Технология разработки юскейсов описана в статье:
Алгоритм описания функциональных требований к системе в формате Use Case
Технически, разница есть, то есть Use case это не тоже самое, что Use case scenario. Например, "Купить Товар" - Use…systems.education
Техника 6. Диаграмма состояний (Statechart Diagram)
Также, как и контекстная диаграмма, одна из старейших в системном анализе и инженерии.
Показывает для выбранного класса данных:
допустимые состояния
допустимые переходы
условия переходов
Обычно строится для 1–2 классов данных, обладающих нетривиальным жизненным циклом (не «новый-обновлён-удалён»).
Онлайн-аукцион. Диаграмма состояний объекта Проект
Создан ОТ заполняет поле "Наименование проекта" и система присваивает атрибут "ID проекта". Опубликован Рассмотрение…docs.google.com
III. Моделирование данных
Второй важнейший аспект моделирования при создании программной системы, после функциональности — структуры данных.
Требования в общем случае не должны заменять проектирование интерфейсов, бизнес-объектов, и баз данных, но должны давать достаточно информации для последующего проектирования.
Техника 7. Концептуальная модель данных
Концептуальная модель отражает всего 2 компонента:
классы данных, с которыми должна работать программная система
связи между этими классами
Пример модели данных:
Онлайн-аукцион по разработке ПО. Модель данных
Организатор торгов Проект Отчёты Портфолио Предложение по разработке Выполненные задания по компетенции Исполнитель…docs.google.com
Мы рекомендуем для концептуального моделирования простой формат диаграммы, без уточнения атрибутного состава, методов и типов связей, как в UML Class Diagram.
Техника 8. Словарь данных (Data Dictionary)
Атрибутный состав классов данных не очень удобно поддерживать на диаграмме, но это не значит, что он не нужен.
Для его проработки мы рекомендуем использовать словарь данных, использующий простейшую форму языка описания формальных грамматик Бэкуса-Наура:
<Определяемое> =
<компонент 1> + <компонент 2> + <компонент …> + <компонент N>
Пример словаря данных:
Онлайн-аукцион по разработке ПО. Словарь данных
Edit descriptiondrive.google.com
IV. Контроль полноты требований
Техника 9. Трассировка классов данных на типовые операции
Есть множество способов измерять и обеспечивать полноту требований, один из самых полезных и простых их них — построение матрицы трассировок перечня классов данных на типовые информационные операции:
создание
обновление
просмотр
поиск
импорт
удаление
архивирование
Матрица помогает принять осознанные решения — есть ли необходимость реализовывать в создаваемой программной системе функцию, отвечающую за конкретную информационную операцию над конкретным классом данных или нет.
Пример матрицы трассировки требований:
Матрица CRUD. Проблемы города
Лист1 Роли List,Search,History,Archive,Execute C,R,U,D,L,S,H,A,X Житель,UC-001 Сотрудник…docs.google.com
С прочими методиками обеспечения полноты требований можно ознакомиться в статье:
Требования не меняются, это мы их недовыявили
Как бы мы ни вели разработку - используя гибкие подходы или классические методы, требования всё равно уточняются и…systems.education
А также в вебинаре:
V. Качество ПО
Техника 10. Формулирование требований к качеству и ограничениям
Эта техника обычно использует в качестве основы канонический формат требований.
Обычно существует большой разрыв между десятками атрибутов качества ПО, которые предлагают семейства международных стандартов ISO 250X0 и проектной практикой, где требования к качеству не предъявляют, что становится проблемой на этапах сдачи и эксплуатации программной системы.
Чтобы сократить этот разрыв, мы предлагаем освоить самые полезные 10 атрибутов качества и 6 ограничений и начать применять выборочно в своих проектах, начиная с 1–2:
Атрибуты внешнего качества: производительность, надёжность, доступность, масштабируемость, безопасность
Атрибуты качества в использовании: результативность, эффективность, скорость обучения, точность, утомляемость
Ограничения: совместимость с оборудованием, системным ПО, ограничения на языки и средства разработки, допущения о квалификации пользователей, состав поставки, лицензионные ограничения
Пример требований к внешнему качеству:
Расходы и доходы. Требования к качеству ПО. Внешнее качество
Edit descriptiondrive.google.com
Подробнее про методику определения целевых показателей для внешнего качества читайте в статье:
Как задавать требования к ВНЕШНЕМУ качеству ПО в цифрах?
Большинство начинающих аналитиков и проектировщиков работают с системами на уровне функций: пишут сценарии…systems.education
Пример требований к качеству в использовании:
Качество использования ПО
Edit descriptiondrive.google.com
Как выбирать конкретные значения показателей, может помочь видео:
Пример ограничений:
iOS приложение словаря Мультитран. Ограничения
Edit descriptiondrive.google.com
Все эти техники можно освоить на практике за 24 часа в онлайн-формате: