Доклад

1) Технология разработки технического задания 

1.​ Элементы ситуационного анализа и целеполагания

Выясните, кто является Заказчиком. В разговоре с Заказчиком установите,

1. Чего он хочет добиться созданием этого ПО (цель создания)
2. Кто будет использовать ПО (бизнес-роли) и для чего (назначение)
3. Каким образом эти люди работают сейчас (текущее решение) и с какими сложностями сталкиваются они или бизнес (проблемы)
4. Кто ещё может рассказать и уточнить пункты выше (Эксперты)
5. Где ещё можно прочитать о том, как работают люди и бизнес сейчас

Результаты разговора полезно оформить в виде Карточки проекта.

​2.​ Исследование и моделирование контекста

В разговоре с Экспертами:

1. Выявите смежные системы;
2. Уточните Роли пользователей ПО;
3. Выявите состав информации, которым будет обмениваться ПО со смежными системами и ролями (на уровне классов/объектов, без уточнения атрибутного состава).

Контекст ПО, включая смежные системы, роли и потоки данных полезно визуализировать в форме Контекстной диаграммы.

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

​3.​ Исследование текущей деятельности

1. Если есть возможность — понаблюдайте за тем, как работают люди сейчас и задайте им уточняющие вопросы об их опыте (что они делают, зачем, что важно в этой работе, с какими сложностями они сталкиваются, что пытались делать для их устранения, что получилось).
2. Изучите предоставленную вам документацию по бизнес-процессам (регламенты, инструкции, руководства, методики), сформулируйте вопросы к Заказчику и Экспертам на уточнение.
3. Задайте вопросы и обсудите их с Экспертами и Заказчиком, по результатам обсуждения обновите Контекстную диаграмму и Концептуальную модель данных.
4. Выявите информационные объекты, обладающие нетривиальным жизненным циклом.
5. Постройте и обсудите с Заказчиком и Экспертами Диаграммы состояний для объектов с нетривиальным ЖЦ.

​4​. Определение функционального объёма и приоритетов

1. Разработайте Диаграмму использования ПО (Use Case Diagram) и выявите, таким образом, основные Сценарии использования. Обсудите и уточните её с Заказчиком и Экспертами.
2. Совместно с Заказчиком и экспертами создайте Карту историй / сценариев использования (user story map), разбив сценарии/истории по шагам основного процесса, который будет поддерживать ПО и/или ролям и приоритизируйте сценарии, разбив их по очередям поставки.
3. Создайте Матрицу трассировки объектов из Концептуальной модели данных на типовые операции, убедившись, что по всем видам информационных операций приняты решения о том, нужно ли или не нужно их поддерживать в этом ПО.

​5.​ Проектирование основных потоков взаимодействия 1-й очереди поставки

1. Начните проработку Сценариев, описав основные потоки сценариев, входящих в первую очередь поставки.
2. Уточните Концептуальную модель данных по результатам.
3. Используя Концептуальную модель, создайте заготовку Словаря данных.
4. Опишите атрибутный состав всех объектов Словаря данных, упоминаемых в Сценариях первой поставки.

​6.​ Разработка требований к качеству и ограничений

Совместно с Заказчиком и Экспертами

1. Установите классы компонентов, из которых состоит ПО
2. Выберите наиболее важные виды требований и разработайте требования к внешнему качеству ПО
3. Выберите наиболее важные виды требований и разработайте требования к использованию ПО
4. Разработайте ограничения к ПО
5. Договоритесь о протоколах интеграции со смежными системами.

​7.​ Проектирование альтернативных потоков использования

1. Проработайте альтернативные ветки к Сценариям использования ПО, входящим в состав первой поставки.

​8.​ Выявление и разработка функциональных требований

1. Выделите атомарные Функциональные требования из текстов Сценариев, если они нужны.
2. Выберите способ группировки Функциональных требований и сгруппируйте их по нему.

​9.​ Разработка сценариев и моделей данных для 2-й и последующих очередей поставки

Аналогично шагам 5, 7 и 8

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

Техника 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. Ограничения: совместимость с оборудованием, системным ПО, ограничения на языки и средства разработки, допущения о квалификации пользователей, состав поставки, лицензионные ограничения

3) Прототипирование, как важный инструмент общения с командой

Figma

Axure

Justinmind