Отчёты как источник функциональных требований и проектных решений

Оглавление

Отчёты как источник функциональных требований и проектных решений

Сегодня я расскажу о том, как правильно работать с отчётами и о том, какой это замечательный источник функциональных требований (и даже проектных решений) при разработке информационных систем.

Попутно рассмотрим типовые ошибки при проектировании отчётов, причины их появления и инструменты предотвращения.

Для начала определимся, что такое отчёт и каково его основное предназначение.

Отчёт — структурированное отображение информации, формируемое на основе данных, хранящихся в информационной системе (ИС), и предоставляемое по запросу пользователя системы.

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

Как создается отчёт

При создании отчёта этапы проектирования и разработки последовательно сменяют друг друга.

На этапе проектирования отчёта системный аналитик:

1. Определяет по техническому заданию (ТЗ) показатели, которые должны выводиться в отчёт
2. Создаёт прототип для формы вывода отчёта и согласовывает его с заинтересованными лицами
3. Описывает последовательность и формулы для расчёта показателей в отчёте
4. Связывает показатели, выводимые в отчёт, с атрибутами модели данных
5. Оформляет постановку на реализацию отчёта

На этапе реализации отчёта разработчик:

1. Берёт постановку на реализацию отчёта в работу
2. Верстает форму для вывода отчёта на экран (или печатную форму отчёта)
3. Создаёт SQL-запросы для выборки нужных данных из базы данных (БД)
4. Реализует расчётные процедуры с полученными данными
5. Выводит полученные результаты в форму вывода
6. И наступает всеобщее счастье! Даже скучно…

Казалось бы, если работа аналитика и разработчика чётко регламентирована инженерией требований, что может пойти не так?

Да что угодно, в чём я имел возможность лично убедиться, потому что…

Из предисловия к первому изданию книги

Четыре типа проблемных ситуаций с отчётами

Как-то раз меня пригласили в качестве аналитика на этап технического проектирования очень большого проекта. Это был проект автоматизации учёта и отслеживания движения транспортных средств (ТС) одного из крупнейших регионов России.

Мне пришлось написать более двухсот постановок на отчёты, но оказалось, что примерно в 20% случаев из 100 невозможно получить из системы данные для отчёта, основываясь на том, как она спроектирована и реализуется.

Проанализировав и сгруппировав все проблемные ситуации, я выделил 4 типа ошибок в отчётах:

1. Данные для получения отчётов в системе в принципе не предусмотрены
2. Данные присутствуют, но нет ясности, эти ли данные нужны для формирования отчёта, и не понятно как это проверить
3. Данные есть, но их так много, что попытка провести выборку и расчёт для получения отчёта приводит к многочасовым расчётам или зависанию системы
4. Данные есть, отчёт реализован и строится, но показатели не соответствуют эталонным

Поговорим о том, почему это случается и как это предотвратить.

Ситуация 1: в системе не предусмотрено хранение нужных нам данных

Причины, по которым возникла ситуация:
В ТЗ не были указаны требования к автоматизации процессов по внесению исходных данных, на основании которых формируется отчётность, то есть была нарушена методология разработки ТЗ.

Последствия для проекта:
Дополнительные денежные и временные затраты на доработку ИС, чтобы нужные для отчета данные все-таки поступали в систему.

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

Как это предотвратить:
Соблюдать методологию разработки ТЗ и использовать отчёты, которые нужны пользователям, как источник требований к проектированию ИС.

“

Когда вы разрабатываете ТЗ как аналитик, ни в коем случае не поддавайтесь на уговоры (за исключением письменного приказа!), когда руководитель проекта, начальство, заказчик предлагают или требуют отложить отчёты на потом, когда система уже будет разработана.

Помните, ответственность на проекте за формирование ТЗ и полноту требований несёт аналитик, и в конечном счёте виноваты будете именно вы!

Отчёты как источник требований

Чтобы отчёты стали тем замечательным источником выявления функциональных требований (ФТ) к системе, о котором я говорил, работа с ними должна начинаться как можно раньше.

Этап обследования организации

На этапе сбора бизнес- и пользовательских требований у заинтересованных лиц необходимо выяснить:

• Какие формы отчётности существуют в компании сейчас
• Кто их формирует и на основании каких данных
• Кто является потребителем отчётов
• Какие отчёты могут понадобиться в будущем (их возможное содержание и структура)

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

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

Этап формирования концепции ИС

На этом этапе нужно:

• Определить, какие отчёты будут реализованы в ИС и согласовать их с заказчиком как концепцию
• Проверить, что среди пользователей ИС есть потребители этих отчётов
• Проверить, что есть поставщики данных в ИС для проектирования реализуемых отчётов
• Проверить, что процессы поставки данных подлежат включению в состав ИС

Самый лучший инструмент для проверки полноты данных, о котором мы говорим на курсах в школе systems. education, это контекстная диаграмма.

Допустим, у нас есть система мониторинга использования автотранспорта и есть выделенные на этапе начального формирования концепции пользователи системы, которые могут быть как людьми, так и другими ИС.

Рассмотрим для примера отчёт об опозданиях на маршрутах.

Контекстная диаграмма с данными для отчёта об опозданиях на маршрутах (синий квадрат)

Потребителем этого отчёта является пользователь с ролью «Диспетчер».

Для формирования отчёта понадобятся данные о водителях, об автобусах, о маршруте и данные о назначениях на маршрут транспортных средств (ТС). Кроме того, понадобятся данные устройств телематики, которые определяют время прохождения ТС контрольных точек. Представляя структуру отчёта, которая была собрана на этапе предпроектного обследования, мы понимаем, что отчёт сформируется, так как все нужные для него данные у нас в системе есть.

Рассмотрим ещё один пример. Пользователь «Менеджер по автотранспорту» по условиям ТЗ должен иметь возможность получать отчёт о рентабельности маршрутов.

Контекстная диаграмма с данными для отчёта о рентабельности маршрутов (зелёный квадрат)

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

И рассмотрим третий пример. Тому же менеджеру по автотранспорту, чтобы принимать управленческие решения (например, сколько докупить автобусов), необходимо получать отчёт о простоях и ремонтах автотранспорта.

Контекстная диаграмма с данными для отчёта о простоях и ремонтах ТС (красный квадрат)

Для отчёта необходимы данные о ТС (они есть), но также нужны данные о ТС, которые находятся в ремонте, а эту информацию в систему никто не поставляет! Процесса поставки данных нет: его забыли указать при формировании ТЗ.

Если присмотреться внимательно, то эти же данные нужны нам и для формирования других отчётов, потому что, чтобы ТС можно было назначить на маршрут, оно не должно находиться в ремонте. Этого не обнаружили, когда формировались функции системы, которые отвечают за поставку, потому что в реальности работы данного АТП это всё было отражено административно: диспетчеру «на бумажке» подавались сведения о том, что такие-то автобусы находятся в ремонте и их нельзя ставить на маршруты, и он их просто не выбирал.

Соответственно, мы не только не получили такие отчёты, мы упустили целый набор либо технических интерфейсов обмена данными с другими системами, где они будут храниться, либо интерфейсов взаимодействия с пользователями, чтобы эти данные поступали.

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

Этап разработки технического задания

На этапе разработки ТЗ нам нужно сформировать функциональные и нефункциональные требования (НФТ) к отчётам.

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

“

Например, система должна позволять пользователю с ролью «Кассир», «Администратор кассы» просматривать отчёт «Кассовый отчёт» с набором полей:

• Дата рабочего дня
  
• Номер рабочей смены
• Дата открытия рабочей смены
• Дата закрытия рабочей смены
  
• …

В НФТ мы формируем требования к качеству или доступности формирования отчёта (скорость формирования отчёта, количество одновременно работающих с отчётами пользователей и т.  п.)

Например, скорость формирования отчётов не должна превышать 1 секунду в 80% случаев.

Ситуация 2: данные присутствуют, но нет ясности, те ли это данные и как это проверить

Причины, по которым возникла ситуация:


• В ТЗ отсутствует или плохо описана концептуальная модель данных (КМД)
• Модель предметной области плохо задокументирована

Последствия для проекта:
Дополнительные временные затраты аналитика и привлекаемых экспертов на доработку и/или документирование КМД.

Кто виноват:
Тот, кто разрабатывал и описывал концептуальную модель данных для проекта.

Как предотвратить:


• Всегда разрабатывать КМД как составную часть ТЗ
• Тщательно документировать КМД

В моем проекте для части отчётов было невозможно сформировать постановки на разработку отчетов, потому что я не понимал, какие данные из модели нужно брать, чтобы эти отчёты формировались. При этом концептуальная модель данных была зафиксирована в виде модели в Enterprise Architect (EA), но в ней были описаны только классы и атрибуты, а их значения — не были. Даже эксперты в предметной области не могли мне объяснить, что это значит, исходя только из названий в модели.

Как правильно документировать данные

Давайте сравним описание данных, каким оно было оставлено моим предшественником (слева) и каким его предлагаю делать я (справа).

Пример описания сущности с пояснениями

Попробуйте понять без пояснения, что «Время: int» это «Время движения от предыдущего Объекта движения. Плановый показатель». И даже эксперт предметной области в этом не поможет: это служебный (технический) атрибут, предназначенный для работы системы, и он появился только в момент автоматизации.

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

Ситуация 3: данных так много, что технических возможностей системы не хватает для их обработки

Мне было необходимо построить ряд отчётов о завершенности рейсов.

Рейс считался завершённым, если более 80% остановок были пройдены вовремя. Все данные хранились в системе телематики. Данные в систему телематики (с устройств, установленных на автобусе) собирались раз в несколько секунд или даже в секунду, то есть система телематики хранила огромные объемы данных.

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

Чтобы построить отчёт о завершённости маршрута, нужно было выполнить ряд последовательных шагов:

1. Сравнить данные координат остановки
2. Сравнить, был ли на данном устройстве в тот день назначенный на рейс автобус
3. собрать это по данным всего предприятия, в котором несколько сотен ТС, за определённый период.

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

Причины, по которым возникла ситуация:


• Особенность технической реализации информационной системы
• Неправильная оценка объема обрабатываемых данных

Последствия для проекта:
дополнительные временные затраты на разработку технического решения и возможное увеличение стоимости технической составляющей системы.

Кто виноват:
Архитектор

Как предотвратить:
Необходимы правильные проектные решения со стороны архитектора на этапе эскизного проекта.

Что может предложить системный аналитик

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

Рассмотрим часть модели, в которую были внесены изменения для построения отчета о завершенности маршрута транспортного средства.

Пример проектного решения для упрощения получения отчёта на больших данных

Итак, мы внесли изменения в логику работы системы. Теперь расчет того, успешен ли рейс, производился сразу после завершения рейса, а не в момент формирования отчёта. Признак успешного завершения мы хранили в базе данных. Для кого-то такое решение может показаться спорным и не очень изящным, но именно оно было применено в нашем случае, и проблемы с построением отчетов из-за недостаточной мощности были решены.

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

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

Ситуация 4: данные есть, отчёт реализован и строится, но показатели не соответствуют эталонным

Это самая простая ситуация, которая случается буквально у всех аналитиков, которые работают с отчётами.

Причины, по которым возникла ситуация:
Ошибки при разработке постановок на реализацию отчёта и/или ошибки при реализации отчёта в коде.

Кто виноват:
Тот, кто разрабатывал и/или реализовывал отчёт.

Последствия для проекта:
Дополнительные затраты на доработку и/или реализацию отчёта в ИС. Если такие отчёты попали в релиз, это вызывает недовольство пользователей и заказчика.

Как предотвратить:
Предоставьте тестировщикам для проверки правильности результатов отчёта реальные тестовые примеры, согласованные с экспертами.

Выводы

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

1. Отчёты — замечательный источник требований к проектируемой ИС, и чем раньше вы начнете с ним работать (в идеале — на этапе предварительного обследования и концепции), тем больше вероятности избежать дорогостоящих ошибок. Кроме того, отчеты — важнейший инструмент принятия решений для бизнеса заказчика.
2. Документируйте аналитические артефакты как можно более полно. Делайте это и на этапе предварительного обследования, и на этапе формирования концепции ИС, и тем более на этапе разработки ТЗ. Максимально подробное документирование — залог того, что при разработке и сопровождении ИС будет меньше проблем с построением отчетов.
3. Проверка отчётов на реальных тестовых примерах — залог хороших отношений с заказчиком и участниками команды разработки.
4. Соблюдайте методологию разработки ИС — и будет вам счастье!

Подписаться на новые статьи

Научиться создавать эффективные системные требования

Научиться создавать эффективные системные требования под руководством опытного наставника с использованием контекстных диаграмм, а также ещё 10 других современных аналитических техник, можно на нашем онлайн-курсе «Системный анализ и Разработка требований к ИТ-системам»

СМОТРЕТЬ ПРОГРАМММУ

Отчёты как источник функциональных требований и проектных решений

Оглавление

Отчёты как источник функциональных требований и проектных решений

Сегодня я расскажу о том, как правильно работать с отчётами и о том, какой это замечательный источник функциональных требований (и даже проектных решений) при разработке информационных систем.

Попутно рассмотрим типовые ошибки при проектировании отчётов, причины их появления и инструменты предотвращения.

Для начала определимся, что такое отчёт и каково его основное предназначение.

Отчёт — структурированное отображение информации, формируемое на основе данных, хранящихся в информационной системе (ИС), и предоставляемое по запросу пользователя системы.

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

Как создается отчёт

При создании отчёта этапы проектирования и разработки последовательно сменяют друг друга.

На этапе проектирования отчёта системный аналитик:

1. Определяет по техническому заданию (ТЗ) показатели, которые должны выводиться в отчёт
2. Создаёт прототип для формы вывода отчёта и согласовывает его с заинтересованными лицами
3. Описывает последовательность и формулы для расчёта показателей в отчёте
4. Связывает показатели, выводимые в отчёт, с атрибутами модели данных
5. Оформляет постановку на реализацию отчёта

На этапе реализации отчёта разработчик:

1. Берёт постановку на реализацию отчёта в работу
2. Верстает форму для вывода отчёта на экран (или печатную форму отчёта)
3. Создаёт SQL-запросы для выборки нужных данных из базы данных (БД)
4. Реализует расчётные процедуры с полученными данными
5. Выводит полученные результаты в форму вывода
6. И наступает всеобщее счастье! Даже скучно…

Казалось бы, если работа аналитика и разработчика чётко регламентирована инженерией требований, что может пойти не так?

Да что угодно, в чём я имел возможность лично убедиться, потому что…

Из предисловия к первому изданию книги

Четыре типа проблемных ситуаций с отчётами

Как-то раз меня пригласили в качестве аналитика на этап технического проектирования очень большого проекта. Это был проект автоматизации учёта и отслеживания движения транспортных средств (ТС) одного из крупнейших регионов России.

Мне пришлось написать более двухсот постановок на отчёты, но оказалось, что примерно в 20% случаев из 100 невозможно получить из системы данные для отчёта, основываясь на том, как она спроектирована и реализуется.

Проанализировав и сгруппировав все проблемные ситуации, я выделил 4 типа ошибок в отчётах:

1. Данные для получения отчётов в системе в принципе не предусмотрены
2. Данные присутствуют, но нет ясности, эти ли данные нужны для формирования отчёта, и не понятно как это проверить
3. Данные есть, но их так много, что попытка провести выборку и расчёт для получения отчёта приводит к многочасовым расчётам или зависанию системы
4. Данные есть, отчёт реализован и строится, но показатели не соответствуют эталонным

Поговорим о том, почему это случается и как это предотвратить.

Ситуация 1: в системе не предусмотрено хранение нужных нам данных

Причины, по которым возникла ситуация:
В ТЗ не были указаны требования к автоматизации процессов по внесению исходных данных, на основании которых формируется отчётность, то есть была нарушена методология разработки ТЗ.

Последствия для проекта:
Дополнительные денежные и временные затраты на доработку ИС, чтобы нужные для отчета данные все-таки поступали в систему.

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

Как это предотвратить:
Соблюдать методологию разработки ТЗ и использовать отчёты, которые нужны пользователям, как источник требований к проектированию ИС.

“

Когда вы разрабатываете ТЗ как аналитик, ни в коем случае не поддавайтесь на уговоры (за исключением письменного приказа!), когда руководитель проекта, начальство, заказчик предлагают или требуют отложить отчёты на потом, когда система уже будет разработана.

Помните, ответственность на проекте за формирование ТЗ и полноту требований несёт аналитик, и в конечном счёте виноваты будете именно вы!

Отчёты как источник требований

Чтобы отчёты стали тем замечательным источником выявления функциональных требований (ФТ) к системе, о котором я говорил, работа с ними должна начинаться как можно раньше.

Этап обследования организации

На этапе сбора бизнес- и пользовательских требований у заинтересованных лиц необходимо выяснить:

• Какие формы отчётности существуют в компании сейчас
• Кто их формирует и на основании каких данных
• Кто является потребителем отчётов
• Какие отчёты могут понадобиться в будущем (их возможное содержание и структура)

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

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

Этап формирования концепции ИС

На этом этапе нужно:

• Определить, какие отчёты будут реализованы в ИС и согласовать их с заказчиком как концепцию
• Проверить, что среди пользователей ИС есть потребители этих отчётов
• Проверить, что есть поставщики данных в ИС для проектирования реализуемых отчётов
• Проверить, что процессы поставки данных подлежат включению в состав ИС

Самый лучший инструмент для проверки полноты данных, о котором мы говорим на курсах в школе systems. education, это контекстная диаграмма.

Допустим, у нас есть система мониторинга использования автотранспорта и есть выделенные на этапе начального формирования концепции пользователи системы, которые могут быть как людьми, так и другими ИС.

Рассмотрим для примера отчёт об опозданиях на маршрутах.

Контекстная диаграмма с данными для отчёта об опозданиях на маршрутах (синий квадрат)

Потребителем этого отчёта является пользователь с ролью «Диспетчер».

Для формирования отчёта понадобятся данные о водителях, об автобусах, о маршруте и данные о назначениях на маршрут транспортных средств (ТС). Кроме того, понадобятся данные устройств телематики, которые определяют время прохождения ТС контрольных точек. Представляя структуру отчёта, которая была собрана на этапе предпроектного обследования, мы понимаем, что отчёт сформируется, так как все нужные для него данные у нас в системе есть.

Рассмотрим ещё один пример. Пользователь «Менеджер по автотранспорту» по условиям ТЗ должен иметь возможность получать отчёт о рентабельности маршрутов.

Контекстная диаграмма с данными для отчёта о рентабельности маршрутов (зелёный квадрат)

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

И рассмотрим третий пример. Тому же менеджеру по автотранспорту, чтобы принимать управленческие решения (например, сколько докупить автобусов), необходимо получать отчёт о простоях и ремонтах автотранспорта.

Контекстная диаграмма с данными для отчёта о простоях и ремонтах ТС (красный квадрат)

Для отчёта необходимы данные о ТС (они есть), но также нужны данные о ТС, которые находятся в ремонте, а эту информацию в систему никто не поставляет! Процесса поставки данных нет: его забыли указать при формировании ТЗ.

Если присмотреться внимательно, то эти же данные нужны нам и для формирования других отчётов, потому что, чтобы ТС можно было назначить на маршрут, оно не должно находиться в ремонте. Этого не обнаружили, когда формировались функции системы, которые отвечают за поставку, потому что в реальности работы данного АТП это всё было отражено административно: диспетчеру «на бумажке» подавались сведения о том, что такие-то автобусы находятся в ремонте и их нельзя ставить на маршруты, и он их просто не выбирал.

Соответственно, мы не только не получили такие отчёты, мы упустили целый набор либо технических интерфейсов обмена данными с другими системами, где они будут храниться, либо интерфейсов взаимодействия с пользователями, чтобы эти данные поступали.

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

Этап разработки технического задания

На этапе разработки ТЗ нам нужно сформировать функциональные и нефункциональные требования (НФТ) к отчётам.

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

“

Например, система должна позволять пользователю с ролью «Кассир», «Администратор кассы» просматривать отчёт «Кассовый отчёт» с набором полей:

• Дата рабочего дня
  
• Номер рабочей смены
• Дата открытия рабочей смены
• Дата закрытия рабочей смены
  
• …

В НФТ мы формируем требования к качеству или доступности формирования отчёта (скорость формирования отчёта, количество одновременно работающих с отчётами пользователей и т.  п.)

Например, скорость формирования отчётов не должна превышать 1 секунду в 80% случаев.

Ситуация 2: данные присутствуют, но нет ясности, те ли это данные и как это проверить

Причины, по которым возникла ситуация:


• В ТЗ отсутствует или плохо описана концептуальная модель данных (КМД)
• Модель предметной области плохо задокументирована

Последствия для проекта:
Дополнительные временные затраты аналитика и привлекаемых экспертов на доработку и/или документирование КМД.

Кто виноват:
Тот, кто разрабатывал и описывал концептуальную модель данных для проекта.

Как предотвратить:


• Всегда разрабатывать КМД как составную часть ТЗ
• Тщательно документировать КМД

В моем проекте для части отчётов было невозможно сформировать постановки на разработку отчетов, потому что я не понимал, какие данные из модели нужно брать, чтобы эти отчёты формировались. При этом концептуальная модель данных была зафиксирована в виде модели в Enterprise Architect (EA), но в ней были описаны только классы и атрибуты, а их значения — не были. Даже эксперты в предметной области не могли мне объяснить, что это значит, исходя только из названий в модели.

Как правильно документировать данные

Давайте сравним описание данных, каким оно было оставлено моим предшественником (слева) и каким его предлагаю делать я (справа).

Пример описания сущности с пояснениями

Попробуйте понять без пояснения, что «Время: int» это «Время движения от предыдущего Объекта движения. Плановый показатель». И даже эксперт предметной области в этом не поможет: это служебный (технический) атрибут, предназначенный для работы системы, и он появился только в момент автоматизации.

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

Ситуация 3: данных так много, что технических возможностей системы не хватает для их обработки

Мне было необходимо построить ряд отчётов о завершенности рейсов.

Рейс считался завершённым, если более 80% остановок были пройдены вовремя. Все данные хранились в системе телематики. Данные в систему телематики (с устройств, установленных на автобусе) собирались раз в несколько секунд или даже в секунду, то есть система телематики хранила огромные объемы данных.

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

Чтобы построить отчёт о завершённости маршрута, нужно было выполнить ряд последовательных шагов:

1. Сравнить данные координат остановки
2. Сравнить, был ли на данном устройстве в тот день назначенный на рейс автобус
3. собрать это по данным всего предприятия, в котором несколько сотен ТС, за определённый период.

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

Причины, по которым возникла ситуация:


• Особенность технической реализации информационной системы
• Неправильная оценка объема обрабатываемых данных

Последствия для проекта:
дополнительные временные затраты на разработку технического решения и возможное увеличение стоимости технической составляющей системы.

Кто виноват:
Архитектор

Как предотвратить:
Необходимы правильные проектные решения со стороны архитектора на этапе эскизного проекта.

Что может предложить системный аналитик

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

Рассмотрим часть модели, в которую были внесены изменения для построения отчета о завершенности маршрута транспортного средства.

Пример проектного решения для упрощения получения отчёта на больших данных

Итак, мы внесли изменения в логику работы системы. Теперь расчет того, успешен ли рейс, производился сразу после завершения рейса, а не в момент формирования отчёта. Признак успешного завершения мы хранили в базе данных. Для кого-то такое решение может показаться спорным и не очень изящным, но именно оно было применено в нашем случае, и проблемы с построением отчетов из-за недостаточной мощности были решены.

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

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

Ситуация 4: данные есть, отчёт реализован и строится, но показатели не соответствуют эталонным

Это самая простая ситуация, которая случается буквально у всех аналитиков, которые работают с отчётами.

Причины, по которым возникла ситуация:
Ошибки при разработке постановок на реализацию отчёта и/или ошибки при реализации отчёта в коде.

Кто виноват:
Тот, кто разрабатывал и/или реализовывал отчёт.

Последствия для проекта:
Дополнительные затраты на доработку и/или реализацию отчёта в ИС. Если такие отчёты попали в релиз, это вызывает недовольство пользователей и заказчика.

Как предотвратить:
Предоставьте тестировщикам для проверки правильности результатов отчёта реальные тестовые примеры, согласованные с экспертами.

Выводы

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

1. Отчёты — замечательный источник требований к проектируемой ИС, и чем раньше вы начнете с ним работать (в идеале — на этапе предварительного обследования и концепции), тем больше вероятности избежать дорогостоящих ошибок. Кроме того, отчеты — важнейший инструмент принятия решений для бизнеса заказчика.
2. Документируйте аналитические артефакты как можно более полно. Делайте это и на этапе предварительного обследования, и на этапе формирования концепции ИС, и тем более на этапе разработки ТЗ. Максимально подробное документирование — залог того, что при разработке и сопровождении ИС будет меньше проблем с построением отчетов.
3. Проверка отчётов на реальных тестовых примерах — залог хороших отношений с заказчиком и участниками команды разработки.
4. Соблюдайте методологию разработки ИС — и будет вам счастье!

Подписаться на новые статьи

Научиться создавать эффективные системные требования

Научиться создавать эффективные системные требования под руководством опытного наставника с использованием контекстных диаграмм, а также ещё 10 других современных аналитических техник, можно на нашем онлайн-курсе «Системный анализ и Разработка требований к ИТ-системам»

СМОТРЕТЬ ПРОГРАМММУ

Функциональные и нефункциональные требования: Спецификация и типы

Время чтения: 11 минут

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

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

Типы требований

BABOK, признанный набор отраслевых стандартов бизнес-анализа, предлагает следующую классификацию требований.

Бизнес-требования

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

• увеличение доходов/пропускной способности/охвата клиентов,
• сокращение расходов/ошибок,
• улучшение обслуживания клиентов и т. д.

Требования пользователей (заинтересованных сторон)

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

Требования к решению

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

• Функциональные требования определяют, что должен делать продукт, каковы его особенности и функции.
• Нефункциональные требования описывают общие свойства системы. Они также известны как атрибуты качества .

Требования к переходу

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

Чтобы узнать больше о документации по программному обеспечению и планировании, просмотрите наше пояснительное видео.

Документирование программного обеспечения и планирование за 11 минут или меньше

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

Функциональные и нефункциональные требования

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

Система отправляет запрос на подтверждение после того, как пользователь вводит личную информацию.

Функция поиска позволяет пользователю искать среди различных счетов, если они хотят кредитовать выставленный счет.

Система отправляет электронное письмо с подтверждением при создании новой учетной записи пользователя.

Нефункциональные требования, не связанные с функциональностью системы, скорее определяют как должна работать система. Некоторые примеры:

Страницы сайта должны загружаться за 3 секунды при общем количестве одновременных пользователей <5 тысяч.

Система должна обслуживать 20 миллионов пользователей без ухудшения производительности.

Вот краткое сравнение, а затем мы перейдем к более подробному объяснению каждой группы.

Функциональные и нефункциональные требования

Типы функциональных требований и их спецификации

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

• Аутентификация
• Уровни авторизации
• Соответствие законам или правилам
• Внешние интерфейсы
• Обработка транзакций
• Отчетность
• Бизнес-правила и т. д.

Требования обычно пишутся в виде текста, особенно для Agile-ориентированных проектов. Однако они могут быть и визуальными. Вот наиболее распространенные форматы и документы:

• Документ спецификации требований к программному обеспечению
• Варианты использования
• Пользовательские истории
• Структура разбивки работ (WBS) или функциональная декомпозиция
• Прототипы
• Модели и схемы

Давайте посмотрим, о чем каждый из них.

Документ спецификации требований к программному обеспечению

Как функциональные, так и нефункциональные требования могут быть формализованы в документе спецификации требований к программному обеспечению (SRS) . Чтобы узнать больше о документации программного обеспечения в целом, прочитайте нашу статью на эту тему. SRS содержит описания функций и возможностей, которые должен предоставлять продукт. Документ также определяет ограничения и допущения. SRS может быть отдельным документом, сообщающим функциональные требования, или может сопровождать другую документацию по программному обеспечению, такую ​​как пользовательские истории и варианты использования.

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

СГД должна включать следующие разделы:

Назначение . Определения, обзор системы и предыстория.

Общее описание. Предположения, ограничения, бизнес-правила и видение продукта.

Особые требования. Системные атрибуты, функциональные требования и требования к базе данных.

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

Пример: Если вы хотите увидеть реальный документ, загрузите этот пример SRS, созданный в Университете штата Мичиган, который включает в себя все пункты, упомянутые выше, в дополнение к примерам использования для иллюстрации частей продукта. Ниже приведен краткий список содержимого SRS.

Шаблон спецификации требований к программному обеспечению, источник: Требования к программному обеспечению Карла Вигерс Джой Битти

Варианты использования

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

Каждый вариант использования включает три основных элемента:

Действующие лица. Это внешние пользователи, взаимодействующие с системой.

Система . Система описывается функциональными требованиями, которые определяют предполагаемое поведение продукта.

Цели . Цели взаимодействия между пользователями и системой обозначены как цели.

Существует два формата представления вариантов использования:

• Спецификация вариантов использования, структурированная в текстовом формате
• Диаграмма вариантов использования

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

• Описание
• Состояние до и после взаимодействия
• Основной путь взаимодействия
• Альтернативный путь
• Путь исключения

Пример:

Шаблон спецификации варианта использования

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

Диаграмма вариантов использования включает следующие основные элементы:

• Варианты использования. Варианты использования, обычно нарисованные овалами, представляют собой различные сценарии взаимодействия, которые могут иметь субъекты с системой ( вход в систему, совершение покупки, просмотр товаров, и т. д. . ).
• Границы системы. Границы очерчены прямоугольником, который группирует различные варианты использования в системе.
• Актеры. Это рисунки, изображающие внешних пользователей (людей или системы), которые взаимодействуют с системой.
• Ассоциации. Связи нарисованы линиями, показывающими различные типы отношений между субъектами и вариантами использования.

Пример:

Пример диаграммы вариантов использования

Пользовательские истории

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

Типичная история пользователя записывается следующим образом:

Как <тип пользователя>, я хочу <некоторую цель>, чтобы <по какой-то причине>.

Пример :

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

Истории пользователей должны сопровождаться критериями приемки . Это условия, которым должен удовлетворять продукт, чтобы быть принятым пользователем, заинтересованными сторонами или владельцем продукта. Каждая пользовательская история должна иметь хотя бы один критерий приемлемости. Эффективные критерии приемки должны быть проверяемыми, краткими и полностью понятными всем членам команды и заинтересованным сторонам. Они могут быть записаны в виде контрольных списков, обычного текста или в формате «Дано/Когда/Тогда».

Пример:

Вот пример контрольного списка критериев приемлемости для пользовательской истории, описывающей функцию поиска:

• Поле поиска доступно на верхней панели.
• Поиск начинается, когда пользователь нажимает Отправить .
• Заполнитель по умолчанию — серый текст Введите имя .
• Заполнитель исчезает, когда пользователь начинает печатать.
• Язык поиска английский.
• Пользователь может ввести не более 200 символов.
• Не поддерживает специальные символы. Если пользователь ввел в поисковый запрос специальный символ, выводится предупреждающее сообщение: Поисковый ввод не может содержать спецсимволы .

Наконец, все пользовательские истории должны соответствовать модели качества INVEST :

•          I – Независимая
•          N – возможен торг
•          В – Ценный
•          E – Оценка
•          S – Маленький
•          T – Тестируемый

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

Возможен торг. Это означает, что все стороны соглашаются отдавать приоритет переговорам, а не спецификации. Это также означает, что детали будут создаваться постоянно во время разработки.

Ценный. История должна быть ценной для покупателя. Вы должны спросить себя с точки зрения клиента, «почему» вам нужно реализовать данную функцию.

Оценивается. Качественная пользовательская история может быть оценена. Это поможет команде составить график и расставить приоритеты при реализации. Чем больше история, тем сложнее ее оценить.

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

Можно проверить. Если историю можно проверить, она достаточно ясна и хороша. Протестированные истории означают, что требования выполнены и готовы к использованию.

Функциональная декомпозиция или структурная декомпозиция работ (WBS)

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

Предлагаем следующую логику функциональной декомпозиции:

1. Найдите наиболее общую функцию.
2. Найти ближайшую подфункцию.
3. Найти следующий уровень подфункции.
4. Проверьте свою схему.

Или процесс декомпозиции может выглядеть следующим образом:

Функция высокого уровня -> Подфункция -> Процесс -> Действие

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

Пример:

Пример функционального разложения

Программные прототипы программного обеспечения

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

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

Конструкторская документация и прототипы

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

Каркасы. Вайрфреймы — это низкоточные графические структуры веб-сайта или приложения. Они помогают отображать различные страницы продуктов с разделами и интерактивными элементами.

Пример каркаса

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

Дизайн прототипов. Эти документы содержат визуальные элементы и допускают некоторые взаимодействия с интерфейсом, такие как прокрутка, переход по ссылкам или заполнение форм. Прототипы дизайна можно создавать с нуля с помощью HTML и CSS, но большинство UX-команд используют сервисы прототипирования, такие как InVision.

Пример:

Чтобы узнать больше о том, как обрабатываются процессы проектирования UX, ознакомьтесь с нашим примером создания решения для управления поездками для Cornerstone, корпоративного поставщика SaaS, в котором мы использовали все три типа требований к дизайну.

Дизайн интерфейса Flight Status платформы 4site

Примеры нефункциональных требований

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

Объяснение нефункциональных требований

Здесь мы кратко опишем наиболее типичные нефункциональные требования.

Удобство использования

Удобство использования определяет, насколько сложно пользователю будет изучить систему и работать с ней. Юзабилити можно оценивать с разных точек зрения:

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

Интуитивность: насколько просто разобраться в интерфейсе, кнопках, заголовках и т. д.

Низкая воспринимаемая нагрузка: сколько попыток требуется пользователям для выполнения конкретной задачи.

Пример: Требования удобства использования могут учитывать языковые барьеры и задачи локализации: Люди, не понимающие французский язык, должны иметь возможность использовать продукт . Или вы можете установить требования доступности: Пользователи клавиатуры, которые перемещаются по веб-сайту с помощью , должны иметь возможность нажать кнопку «Добавить в корзину» со страницы продукта в течение 15 кликов .

Безопасность

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

Пример: A Права доступа к конкретной системной информации могут быть изменены только системным администратором данных.

Надежность

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

Пример: Процесс обновления базы данных должен выполнить откат всех связанных обновлений в случае сбоя любого обновления.

Производительность

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

Пример: Время загрузки главной страницы должно быть не более 2 секунд для пользователей, которые заходят на веб-сайт через мобильное соединение LTE.

Доступность

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

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

Масштабируемость

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

Пример: Лимит посещаемости веб-сайта должен быть достаточно масштабируемым, чтобы поддерживать 200 000 пользователей одновременно.

Передовой опыт документирования требований

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

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

Требования должны быть конкретными, точными и полными. При написании документации следите за языком и убедитесь, что ваши требования точны. Они должны охватывать все сценарии, но никогда не должны противоречить друг другу. Избегайте расплывчатости и слабых фраз, таких как «система должна быть быстрой» или «когда что-то случается». Будьте конкретны и дайте количественную оценку терминам, чтобы все читатели могли понимать их одинаково.

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

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

Руководство по функциональным требованиям (с примерами)

Узнайте, как определить требования и согласовать все заинтересованные стороны.

Правильная формулировка требований — ключ к успеху любого проекта. Неспособность точно определить и задокументировать их неизбежно приводит к недопониманию между заинтересованными сторонами, постоянным пересмотрам и ненужным задержкам. Исследования показывают, что неясных или плохо задокументированных требований могут увеличить сроки и бюджет проекта до 60% .

С ростом популярности Agile-подхода к документации некоторые команды начали пренебрегать требованиями к документации — в конце концов, это «рабочее программное обеспечение важнее всеобъемлющей документации», верно?

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

• Что такое функциональные требования?
• Почему необходимо документировать функциональные требования
• Примеры функциональных требований
• Функциональные и нефункциональные требования
• Как написать документ с функциональными требованиями

Что такое функциональные требования?

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

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

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

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

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

Функциональные требования могут быть зафиксированы как часть документа с требованиями к продукту (PRD) или в форме отдельного документа с функциональными требованиями (FRD). Вот пример того, как такой документ может выглядеть в Nuclino, едином рабочем пространстве для всех знаний, документов и проектов вашей команды — создайте учетную запись и начните документировать свои требования в одном централизованном месте:

Почему необходимо документировать функциональные требования

Документирование и согласование функциональных требований имеет множество преимуществ:

• Заинтересованные стороны имеют единый источник достоверной информации . Четко задокументированные требования позволяют всем разработчикам, дизайнерам и специалистам по контролю качества работать на одной странице и работать над достижением одной цели, избегая недопонимания.

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

• Проекты становятся более предсказуемыми . Подробные, качественные требования позволяют команде более точно оценить время и стоимость разработки и разработать продукт, соответствующий ожиданиям.

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

Примеры функциональных требований

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

• Система должна отправлять электронное письмо с подтверждением при каждом размещении заказа.

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

• Система должна позволять пользователям подтверждать свои учетные записи, используя свой номер телефона.

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

• История пользователя : Как существующий пользователь, я хочу иметь возможность войти в свою учетную запись.

• Функциональные требования :

• Система должна позволять пользователям входить в свою учетную запись, вводя адрес электронной почты и пароль.

• Система должна позволять пользователям входить в систему со своими учетными записями Google.

• Система должна позволять пользователям сбрасывать свой пароль, нажимая «Я забыл свой пароль» и получая ссылку на подтвержденный адрес электронной почты.

Функциональные и нефункциональные требования

При определении требований к продукту важно различать функциональные и нефункциональные требования.

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

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

С другой стороны, нефункциональные требования (также известные как «требования к качеству» или «атрибуты качества») являются более абстрактными. Они накладывают ограничения на реализацию функциональных требований с точки зрения производительности, безопасности, надежности, масштабируемости, переносимости и т. д.

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

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

• Функциональное требование : «Система должна позволять пользователю отправлять отзывы через контактную форму в приложении».

• Нефункциональное требование : «При нажатии кнопки отправки экран подтверждения должен загрузиться в течение 2 секунд».

Как написать документ с функциональными требованиями

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

Выберите правильный инструмент документирования

В прошлом большинство команд использовали Microsoft Word для создания функциональных требований и управления ими. Это неизбежно привело к тому, что устаревшие и неточные FRD прыгали по почтовым ящикам команды.

К счастью, теперь у вас есть из чего выбирать. Выберите инструмент, который упрощает совместную работу и гарантирует, что у всех всегда будет самая последняя версия, чтобы избежать путаницы. Например, вы можете хранить свои требования в Google Doc или, что еще лучше, в инструменте документации вашей команды или внутренней вики, которую можно легко настроить в Nuclino.

Хотя Nuclino можно использовать исключительно как инструмент документирования, он очень универсален и способен на гораздо большее. Он предлагает различные способы структурирования и визуализации вашего контента, включая вложенный список, доску Канбан, таблицу и график в стиле ментальной карты. Это делает Nuclino отличным решением для многих дополнительных вариантов использования, включая совместную работу над проектами, планирование спринтов, асинхронную связь и многое другое. Nuclino работает как коллективный мозг, позволяя вам объединить работу всей вашей команды и сотрудничать без хаоса файлов и папок, переключения контекста или разрозненности.

Сделайте это совместным процессом

Ваш FRD должен быть живым документом, изменяющимся по мере продвижения вашего проекта. Чтобы все оставались на одной волне, каждая заинтересованная сторона должна постоянно вносить свой вклад. Вовлекайте свою команду на раннем этапе и сообща обновляйте требования.

Будьте максимально ясны

Хорошо написанные функциональные требования обычно имеют следующие характеристики:

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

• Краткий . Используйте простой и понятный язык без лишнего жаргона, чтобы избежать путаницы или неправильного толкования.

• Достижимый . Все требования, которые вы включаете, должны быть реалистичными в рамках временных и бюджетных ограничений, установленных в документе бизнес-требований.

• Гранулированный . Не пытайтесь объединить множество требований в одном. Чем точнее и детальнее ваши требования, тем проще ими управлять.

• Непротиворечивый . Убедитесь, что требования не противоречат друг другу и используйте единую терминологию.

• Поддающийся проверке . В конце проекта должна быть возможность определить, было ли выполнено требование.

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

Nuclino: коллективный мозг вашей команды

Nuclino объединяет все знания, документы и проекты вашей команды в одном месте. Это современный, простой и невероятно быстрый способ совместной работы без хаоса файлов и папок, переключения контекста или разрозненности.

This entry was posted in Популярное