Разработка требований к по

Определение требований к программному обеспечению

Сергей Трофимов

Вступление
Перечисление возможных требований
Осознание контекста системы
Модель предметной области
Бизнес-модель
Определение функциональных требований
Определение нефункциональных требований

Вступление

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

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

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

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

Можно определить следующие шаги рабочего процесса определения требований*:

  • Перечисление возможных требований;

  • Осознание контекста системы;

  • Определение функциональных требований;

  • Определение нефункциональных требований.

Перечисление возможных требований

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

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

  • состояние предложения (например, предложено, одобрено, включено в план, утверждено);

  • трудоемкость в человеко-часах или стоимость реализации;

  • приоритет (например, критический, важный или вспомогательный);

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

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

Осознание контекста системы

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

  • Моделирование предметной области;

  • Бизнес-моделирование.

Модель предметной области

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

Бизнес-модель

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

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

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

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

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

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

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

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

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

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

Плюсы

Расписано всё

Новички получат полное представление о работе аналитика. Профи вспомнят то, с чем сталкивались сами. Разобраны все стадии создания спецификаций. В приложении Б находится пособие, составленное по принципу «проблема — решение». Само оглавление выступает в роли подсказки. Подробные чек-листы содержатся почти в каждой главе. Например, шаблон спецификации включает 8 пунктов, 24 подпункта и два приложения. Исчерпывающее руководство.

Легко найти информацию

Информация чётко структурирована, и это облегчает поиск по книге. Оглавление прописано на 9 страницах. В нём быстро находится нужный этап и пояснения. В каждой главе есть отсылки на другие главы, если какой-либо вопрос там описан подробнее. В конце руководства приводится словарь терминов, так что можно не бояться таких фраз, как «UML», «водопадный жизненный цикл проекта» или «CRUD-матрица». За пару минут находится PDF-версия прошлых изданий, можно воспользоваться поиском по документу, если нужны конкретные данные.

Для всех, кто в ИТ

Аналитики соприкасаются со всеми, кто участвует в проекте: заказчиками, дизайнерами, разработчиками, тестировщиками, продажниками, поддержкой и пользователями продукта. И каждая группа должна знать, как адекватно соотносить техническое задание с тем, что они делают. Неопытный сотрудник может спросить нечто вроде: «А где у нас прописано, что при нажатии на этот элемент не должно ничего происходить?» Если он прочитает книгу, то сам ответит на этот вопрос и оставит обоснованные комментарии к документу.

Пояснения терминов

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

Минусы

Многословие

Авторы злоупотребляют длинными предложениями и ненужной информацией. Из-за этого смысл уловить сложнее.

«Средства управления требованиями помогают отслеживать требования, давая возможность определять связи между различными типами требований, между требованиями в различных подсистемах и между отдельными требованиями и связанными системными компонентами (например, дизайном, модулями кода, тестами и пользовательской документацией)».
Лев Толстой, ты?
«… методы общения могут обеспечить эффективную синхронизацию во времени и пространстве внутри команды».
А на форзаце написано, что это руководство, а не философский трактат.
«Диаграмма состояний для состояния заказов блюд».
Авторы два раза не повторяют, не повторяют.
«Стивен Уитхолл (Stephen Withall, 2007) описывает много схем для точного документирования данных (которые также называют информацией)».
Данные = информация. А в этом что-то есть!
И такой смысловой шум по всей книге. Возникает подозрение, что авторам платили за строки.

Грамматические ошибки

По ходу чтения насчитал их более 160. Все ошибки в рамках школьной программы. Например: пропускаются слова, используется «-тся» вместо «-ться», повторяются предложения в одном абзаце, встречаются банальные опечатки, пропускаются запятые, путаются понятия, которые пишутся похожим образом.
Первая ошибка встречается, как только открываешь книгу. У Крис нет мании величия, просто её перепутали с Карлом, который посвятил ей книгу. Они супруги.

А как вам такая фраза?
«Перепроектировать систему для более качественной обработки изменчивых бизнес-правил, которые был сложны проект поддержке».

Product placement

По ходу изложения авторы неоднократно упоминают продукты Microsoft. Они настолько известны, что нет смысла писать про них. А когда надо назвать системы управления требованиями (СУТ), то авторы о них умалчивают. Я же только ради них эту главу и читал. Просто книгу выпускала Microsoft Press, а у «мелкомягких» нет полноценной СУТ. Лояльность компании перевесила профессиональный долг.

Недосказанность

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

Что актуально для России?

Перед прочтением думал примерно так: «Что американец может посоветовать нам? У них всё в цифре, и нет никаких проблем». Выяснилось, что проблемы примерно одинаковые.

Нет культуры уважения к требованиям

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

Не вырабатываются бизнес-требования

Бизнес-требования (business requirements) описывают, почему организации нужна система, то есть цели, которые компания намерена достичь с её помощью. Но если посмотреть на средние российские компании, то создаётся странное впечатление. Одни непонятно зачем производят, а другие непонятно зачем покупают. Зато раздуваются амбиции и делается ставка на котиков в Instagram. Бывает, общаешься с очередным гением из «Сколково», а он пассионарно навязывает клиентам выдуманные потребности. В результате компания выглядит как овощ, а бюджет – как дырявое ведро.

«Привязываются» к дизайну

Так нельзя, потому что после редизайна приходится править ТЗ. Это ненужная трата времени. Не надо, чтобы спецификация зависела от дизайна. Пускай у дизайнеров будет выбор, как реализовать то или иное требование. Например, управляющий элемент «Удалить» можно представить в виде кнопки, иконки, ссылки, смахивания, пункта контекстного меню. Лучше описывать это через функции и схемы, а не интерфейсы. Не «система отображает раскрывающийся список», а «система предоставляет выбор».

Нет понимания специфики работы аналитика

Например, в одной компании аналитикам расширили обязанности. Им поручили информировать начальство о том, когда реализуется то или иное требование и кем. Если происходила задержка, то выясняли почему. Переводили задачу по этапам и назначали ответственных из других отделов. В итоге пострадала содержательная часть. Всё описанное — обязанности менеджера проектов. Менеджер отвечает за обмен информации о проекте, аналитик — за обмен информации о продукте. Это два разных направления деятельности.

Не используется инструментарий

Один начальник хотел, чтобы те, кто работает с ТЗ, знали их близко к тексту. Это нереально. В компании несколько десятков ТЗ, и их число увеличивается. Если ты сам закончил составлять ТЗ месяц назад, ты всё равно его забываешь, потому что потом погружаешься в 2-3 новых. Проблема решается не за счёт памяти, а за счёт внедрения систем управления требованиями (СУТ). Они поддерживают выявление, управление, отслеживание и вывод требований. Но за них надо платить, и работодатели предпочитают работать по старинке, как в поговорке:
Два солдата из стройбата заменяют экскаватор.
А один из ВДВ заменяет их вдвойне.
Post Scriptum
Я написал издателям варианта книги на русском языке по поводу ошибок и предложил вместе их исправить. Запрос прочитали, но сотрудники ничего не ответили. Значит, они считают нормой безграмотность. Это печально, потому что оригинал годный.

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