Цель статьи — рассказать сложное простым языком, поэтому здесь минимум цитат из международных стандартов и максимум ассоциаций и упрощенных примеров. Не претендую на "истину в последней инстанции", поэтому если вам что-то из описанного в статье не подходит для работы, действуйте на свое усмотрение и смело забудьте всё, что написано ниже :)
Когда кто-то планирует создать информационную систему, то хочется убедиться, что все, что будет сделано, соответствует его ожиданиям и он готов за этот результат заплатить. Чтобы результат был максимально приближен к желаемому, принято все ожидания и требования к системе документировать. Чаще всего, процессом сбора, описания и управления требованиями к системе занимается аналитик (чаще, бизнес-аналитик, но о видах аналитиков напишу отдельно). Чтобы сделать проработку этих требований более качественной и структурированной принято говорить о нескольких видах:
- бизнес-требования (чаще, БТ);
- пользовательские требования (сокращают до ПТ);
- функциональные требования (сокращенно, ФТ);
- нефункциональные требования (НФТ).
Иногда отдельно выделяют системные требования, описывающие обмен информацией между системами. На базовом уровне погруженности в тему, их можно включить в описание ФТ или НФТ, поэтому не будем на них останавливаться отдельно.
Простыми словами, требования - это описанные в документах потребности причастных к созданию системы людей и обязательные условия, зафиксированные в формальных документах, которые должны выполняться в информационной системе.
Виды требований можно представить как пирамиду. Самые главные, с которых начинается создание информационной системы - это бизнес-требования, поэтому они на вершине пирамиды. Все последующие уровни зависят от предыдущих:
- БТ (бизнес-требования) - что хочет получить бизнес от создания информационной системы (или от проекта).
- ПТ (пользовательские требования) - какие цели пользователей из реального мира должна позволять достичь система, в результате чего будут достигнуты цели бизнеса, лежащие в основе проекта.
- ФТ (функциональные требования) - это детали работы функций системы, которые надо реализовать команде разработки, чтобы пользователи могли выполнять свои задачи из реального мира, в результате чего будут достигнуты цели бизнеса, лежащие в основе проекта.
- НФТ (нефункциональные требования) - характеристики (в основном, отражающие уровень качества решения), ограничения и особенности интерфейса, которые надо учесть команде разработки при создании функций системы, позволяющих пользователям выполнять свои задачи из реального мира, в результате чего будут достигнуты цели бизнеса, лежащие в основе проекта.
При этом каждый следующий уровень содержит в себе больше требований, чем предыдущий и поэтому в пирамиде он более широкий.
Они описывают ситуацию, в которой бизнес хочет решить свою существующую проблему и готов за это решение платить деньги, чтобы в будущем сократить свои расходы или увеличить доходы и не только вернуть вложенные деньги, но и получить больше. Если ради этой цели решено создать какое-либо ИТ-решение, то описание ситуации становится бизнес-требованием к информационной системе (далее - ИС).
Рассмотрим выдуманный пример (любые совпадения случайны)
Предположим, что есть авиакомпания, в которой регистрация на рейс происходит всегда у стойки регистрации. Так как авиакомпании приходится платить за аренду стойки, трапов и другого оборудования в аэропорту, а также за простой самолета на взлетной полосе, то очень важно посадку проводить в короткие сроки. Допустим, что именно такую цель (максимально быструю регистрацию) компания ставит перед своими сотрудниками. В результате сотрудники очень спешат, допускают ошибки, пассажиры опаздывают на рейс или не могут из-за ошибки улететь и т.д. В результате при таких форс-мажорах время регистрации, наоборот, только возрастает и компания теряет деньги буквально каждую минуту. Одним из решений может быть запуск проекта по созданию системы онлайн-регистрации пассажиров на рейс.
Грубо говоря, описание этой ситуации, подкрепленное расчетами со стороны бухгалтерии и будет "описанием контекста" или исходными данными.
Если решить для сокращения издержек создать систему регистрации на рейс онлайн и оформить эту идею по SMART (то есть дополнить конкретными, измеримыми, достижимыми, реалистичными и привязанными ко времени деталями), то мы можем получить "бизнес-цель".
Любая авиакомпания должна подчиняться требованиям законов о воздушных перевозках и многим другим. Часть из них будет зависеть от страны вылета или прилета. Подобные правила, которые необходимо соблюдать в жизни и, соответственно, во время проектирования ИС, называются "бизнес-правилами". Они также могут диктоваться самой компанией, которая решила создать информационную систему и регулироваться внутренними нормативами.
Совокупность всего вышеперечисленного можно отнести к "бизнес-требованиям", которые описывают потребности бизнеса, ради удовлетворения которых инициируют проект.
Бизнес-требования могут включать:
- Бизнес контекст
- Бизнес-цели
- Бизнес-правила
- Критерии успеха
- Видение решения
- Бизнес-риски
- Предположения и зависимости
- и другое.
Исчерпывающего списка, зафиксированного в международном стандарте, мне еще не встречалось. Авторы интерпретируют состав бизнес-требований по-разному. Ключевая задача БТ - описать существующую сейчас проблему и желаемый результат, который хочется достичь после создания ИС. Остальное не так важно.
Пользовательские требования (ПТ)
Выдуманный пример (продолжение)
Система считается работающей, когда она помогает людям в реальной жизни (пользователям) достигать их цели. В нашем случае примером может быть помощь пассажирам регистрироваться на рейс, выбирать место, заказывать тип еды и т.д.
"Пользовательские требования" можно представить себе, как задачи пользователя из реального мира, которые:
- Должны помочь выполнить все бизнес-требования, ради которых создается ИС;
- Должны быть достижимы при использовании в будущем этой ИС (то есть ИС и её функции должны помочь пользователю его задачи решить, желательно, наиболее эффективным способом).
Заметьте, все потребности пользователя лежат в реальном мире, у него нет каких-то потребностей от некой "системы", поэтому ничего про "регистрацию" или "вход" в систему к требованиям пользователя относить не стоит.
Чтобы узнать больше про то, кого можно считать пользователем, рекомендую ознакомиться с подходом системного мышления к описанию "стейкхолдера" (добавить ссылку).
Подходы, применяемые для описания пользовательских требований (из личного наблюдения):
- список возможностей (гл. + сущ.);
- User Story (USM);
- JTBD.
Функциональные требования (ФТ)
Функциональные требования становятся больше всего нужны в момент, когда можно переходить непосредственно к проектированию будущей системы и формированию её будущих возможностей (функций).
На этом этапе систему представляют как "черный ящик", то есть не важно как именно что-то в системе будет реализовано (какая база данных, какие сервера, какие алгоритмы шифрования, библиотеки и т.д.), важно только то, какая информация ей потребуется от пользователя, какие действия он должен будет предпринять, взаимодействуя с системой, и какую информацию система выдаст пользователю в результате выполнения функций.
Функция в системе - эта возможность пользователя достичь какую-то одну свою цель или выполнить одну свою задачу.
При этом к каждой функции может быть много функциональных требований, которые описывают детали работы этой функции без погружения в особенности реализации командой разработки.
Выдуманный пример (продолжение)
В случае онлайн-регистрации функцией может быть выбор места в салоне самолёта. При этом будут и функциональные требования, которые необходимо учесть при создании функции ИС:
Важно отличать пользовательские и функциональные требования. Пользовательские — формируются в терминах предметной области, а функциональные - в терминах системы.
Подходы к описанию функциональных требований, которые используют чаще всего (из личного наблюдения):
- Фразы, начинающиеся со слов "Система должна…" и дополненные деталями, которые необходимо учесть в ИС
- Сценарии использования - это подход, о котором поговорим отдельно в следующих статьях.
Нефункциональные требования (НФТ)
Описывают требования, которые надо учитывать при создании системы непосредственно командой разработки. В этом случае мы заглядываем внутрь "черного ящика" и описываем, как что работает.
Сам термин "НФТ" очень спорный, так как он не говорит четко, что именно надо описать, только о том, что это не про функции (не функции, не функциональные требования). Однако отказаться от него в ИТ пока не представляется возможным.
Чаще всего они описывают:
- Атрибуты качества:
- Характеристики, более важные для пользователей, например: доступность, надежность и т.д.
- Характеристики, более важные для разработчиков, например: тестируемость, возможность переиспользования и т.д.
- Внешние интерфейсы (взаимодействия с пользователем, то есть сами экранные формы, и при обмене данными с другими системами или между компонентами создаваемой системы).
- Ограничения, которые надо учитывать при создании системы.
Выдуманный пример (продолжение)
В случае системы онлайн-регистрации нам понадобится описать много разного вида НФТ, например:
- Из атрибутов качества — это количество одновременно работающих пользователей, которые успешно смогут регистрироваться в системе без «зависания», скорость ответа на запрос, поддерживаемые браузеры, требования к мобильным устройствам и т.д.
- Из внешних интерфейсов — это и сами экранные формы, включая их внешний вид, и API для обмена данными с другими системами (это для примера).
- Из ограничений могут быть какие-то ранее принятые решения, например, по возможности выбрать российское или зарубежное программное обеспечение для создания системы и т.д.
НФТ описываются, как правило, в свободной форме, то есть без строгих правил к оформлению, как это было у ПТ, например.
В сумме все эти виды требований, от БТ до НФТ, помогут вам описать будущую систему наиболее полно и получить больше уверенности в результате. При этом есть подходы к разработке ИС, когда процесс работы с требованиями может быть более строгим (например, водопадная модель) или более гибким (например, agile), но это уже выходит за рамки “базового” уровня, поэтому отличия постараюсь описать в следующих статьях.
Больше информации о работе с требованиями и примеры их описания в проектной документации вы найдете в книге Вигерса “Разработка требований к программному обеспечению” (около 600 страниц).
Ответы (0 )