Так что лучше не использовать слово “требования” (ибо непонятно, о чём идёт речь), а использовать уточняющие определения: в системной инженерии принято говорить о требованиях к продукту (требованиях стейкхолдеров) и требованиях к системе (системные требования), а всякие остальные “требования” (требования стандартов, требования системной архитектуры, требования чертежей, требования проектной документации и т.д.) просто означают, что “система должна удовлетворить этим описаниям”, но это не будет “требованиями” в смысле системной инженерии.
Содержание
Требования к продукту
Требования к продукту (бизнес-требования, требования стейкхолдеров) — это описания “черного ящика”, которые формулируются пользователями, рынком, внешними регуляторами, и, обычно, описывают проблемную область:
Требования к продукту от разных стейкхолдеров могут быть противоречивы, разрознены и неполны. Обычно от инженера по требованиям требуется документировать (в тексте или какой-то модели) требования стейкхолдеров, а затем завизировать эти требования у них — чтобы подтвердить правильность понимания.
Каждый клиент мнит себя инженером (а иногда не мнит, а является ещё и инженером, более знающим, чем инженеры команды проекта). Такой клиент не только будет формулировать требования стейкхолдера, а также требования к системе, но обязательно попытается сформулировать конкретные инженерные решения “прозрачного ящика” (например, из каких частей должна составлять система, какое в ней должно быть использовано оборудование).
Формально высказывания о “прозрачном ящике” не называются требованиями, поэтому некоторые авторы предлагают называть их “ограничениями” (свободы творчества инженерной команды). Неплохо бы понимать в каждом проекте, что является требованиями, а что является ограничениями. Прежде всего вы должны удовлетворить требования. И если придуманное вами инженерное решение лучше того, которое требует клиент в своих ограничениях, попытаться убедить клиента снять эти ограничения. Но нужно понимать, что иногда эти ограничения отражают какой-то опыт клиента, неизвестный команде, или они появляются из неинженерных (политических, финансовых, логистических и т.д.) соображений. Поэтому по поводу ограничений нужно каждый раз понимать, почему они были прописаны, почему клиент без них не может обойтись (см. GORE).
Требование к требованиям стейкхолдеров: их понятность самим стейкхолдерам. Стейкхолдеры нуждаются в требованиях, которые сфокусированы их нуждами.
Требования к системе
Требования к системе (system requirements) — требования, достаточные для разработки системы, которые формулируются архитекторами, проектировщиками и аналитиками на основе анализа требований к продукту и описывают:
Их разрабатывает инженер по требованиям в ходе так называемой “аналитической” работы (хотя в этой работе кроме анализа требований стейкхолдеров и присутствует синтез системных требований).
К требованиям к системе предъявляют множество самых разных требований:
Требования по ГОСТ 34
ГОСТ 34.602 устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы». Техническое задание определяет требования и порядок создания системы, в соответствии с которым проводится её разработка и приемка при вводе в действие. Техническое задание содержит следующие разделы:
Модальность
Чтобы понять природу требований, нужно разобраться с логическими модальностями высказываний о системе (модальная логика):
доксическая (doxastic) модальность, связанная с верой. «Я верю, что длина дана как 16». Доксическая модальность важна для квалификации (удостоверения того, что требования выполнены — вера в то, что система соответствует её определению).
Требования довольно трудно формализовать именно потому, что нужно разбираться с их модальностями.
Требования связаны с инженерными обоснованиями: они переформулируются как «декларации» (claim) разработчиков о соответствии — т.е. «я верю, что длина равна 16», а затем это высказывание доказывается по логическим правилам рациональной аргументации (помним, что логика — это дисциплина, занимающаяся правильностью рассуждений). Эти доказательства проводятся “как в суде” — и для этого даже заводится “дело” (assurance case, как раз от “судебного дела” — с вариантами dependability case, safety case, security case, requirement case, architectural quality case). Обзор по инженерным обоснованиям приведён тут.
Виды требований
Но есть замечание Donald Firesmith, что “не бывает нефункциональных требований” — ибо все эти «требования качества» это абсолютно функциональные требования, характеризующие функции системы с точки зрения каких-то стейкхолдеров, обычно не рассматривающихся в сценариях “пользования”.
Главный источник ошибок в проекте — это неведение относительно наличия каких-то требований. Впрочем, классификация может помочь, если вы зададите себе вопрос: какие виды требований вы ещё не рассматривали для вашего проекта?
Свойства качества (внешние)
Подробнее про требования защитоспособности (выделенные на рисунке выше) можно посмотреть в презентации Дональда Файерсмита — и там же можно посмотреть на презентацию по целеориентированной инженерии требований Яна Александера.
Стандарты представления требований
Практики ЖЦ требований по ISO 15288
Жизненный цикл требований стейкхолдеров
Жизненный цикл требований к системе
Рабочие продукты требований
Рабочие продукты требований могут быть самые разные — и чаще всего они не называются “требования”. Так, требования можно обнаружить в:
Важно понимать, что:
Управление требованиями и инженерия требований
Требования к требованиям
Требования к требованиям по ISO 29148
Требования к группе требований:
Требования к одному требованию:
Другое
Состояния
OMG Essence определяет следующие состояния для альфы «Требования» и контрольные вопросы для проверки каждого состояния:
№
Состояние
State
Описание состояния
Контрольные вопросы
1
Замыслены
Conceived
Согласована потребность в новой системе.
❑ Начальное множество стейкхолдеров согласно, что система должна быть произведена.
❑ Стейкхолдеры, которые будут использовать новую систему, определены.
❑ Стейкхолдеры, которые профинансируют начальную работу по созданию новой системы, определены.
❑ Есть ясная возможность, которую будет адресовывать новая система.
2
Ограничены
Bounded
Назначение и тема новой системы ясны.
❑ Стейкхолдеры, вовлечённые в разработку новой системы определены.
❑ Стейкхолдеры согласны с назначениемновой системы.
❑ Ясно, что будет считаться успехом для новой системы.
❑ Стейкхолдеры имеют одинаковое понимание пределов предлагаемого решения.
❑ Технология описания требований согласована.
❑ Механизмы управления требованиями наличествуют.
❑ Приоретизационная схема ясна.
❑ Ограничения определены и приняты во внимание.Допущения ясно сформулированы.
3
Непротиворечивы
Coherent
Требования обеспечивают непротиворечивое описание существенных характеристик новой системы.
❑ Требования документированы и доступны команде и стейкхолдерам.
❑ Происхождение требований ясно.
❑ Обоснование требований ясно.
❑ Противоречивые требования идентифицированы и ими занимаются.
❑ Требования сообщают существенные характеристики поставляемой системы.
❑ Наиболее важные сценарии использования системы могут быть объяснены.
❑ Приоритетность требований ясна.
❑ Влияние реализации требований понимается.
❑ Команда понимает, что должно быть обеспечено и соглашается обеспечить это.
4
Приемлемы
Acceptable
Требования описывают систему, которая будет приемлема для стейкхолдеров.
❑ Стейкхолдеры принимают, что требования описывают приемлемое решение.
❑ Скорость изменений к согласованным требованиям относительно низка и под контролем.
Управление системами фильтрации электронной почты и веб-трафика
АУТСОРСИНГ DLP ДЛЯ ЗАЩИТЫ БИЗНЕСА
О бычно небольшой бизнес начинается с 1-2 компьютеров, по мере роста компании их число увеличивается, и они объединяются в сеть. На определенном этапе у фирмы появляется необходимость увеличить свои ресурсы, и этот этап начинается с разработки требований к информационной системе. В ходе его реализации проводится опрос заинтересованных подразделений, собираются заявки, составляется техническое задание.
Понятие информационной системы
В предпринимательской деятельности под информационной системой (ИС) понимается совокупность компьютеров, дополнительного оборудования, сетей, программного обеспечения, которая призвана хранить и обрабатывать информацию компании, позволяя максимально полезным образом использовать ее в целях бизнеса.
Соответственно, разрабатывая требования к ИС, необходимо учитывать, что они будут складываться из требований к ее составляющим:
Отдельные элементы системы подбираются в зависимости от размера компании и специфики ее деятельности. Главная задача ИС – обработка информационных потоков: входящих в компанию из внешнего мира, исходящих вовне, а также протекающих внутри компании. Это обработка заказов и документов, внутренние аналитические и учетные операции, вычисления, анализ финансовой эффективности, генерация отчетов об итогах производственной деятельности. Для слаженной работы необходимо правильно выбрать специализированные программные продукты и настроить их под потребности организации. Поэтому для успешной разработки требований к ИС часто приглашают сторонних специалистов.
Отличия информационных систем для компаний разной величины
Архитектура системы зависит от того, каким бизнесом занимается фирма, Жизнеспособность ИС опирается на два фактора:
Для небольшого бизнеса будет достаточно выстроенной системы учета, возможности описывать и администрировать бизнес-процессы, наличия мобильного приложения для обработки заказов. Крупной компании дополнительно к этому необходима собственная CRM-система, а также средства, обеспечивающие безопасность ИС, например, DLP.
Как разработать требования к ИС
К разработке требований к информационной системе, необходимо привлечь IТ-специалистов, системных администраторов, специалистов финансовых служб и служб безопасности. Но только персонала фирмы для успешной разработки требований может быть недостаточно. Нередко требуется пригласить профессионалов, зарекомендовавших себя опытом успешных внедрений информационных систем.
На первом этапе необходимо собрать запросы от подразделений, которые станут пользователями системы:
Свои задачи к программному обеспечению поставят отделы НИОКР, юристы, маркетологи. Дополнительные требования заявят IТ-службы, работающие с системой.
Помимо сотрудников, которые заинтересованы во внедрении системы, есть и те, чьим интересам она противоречит, например, подразделения, которые должны быть сокращены, если их задачи сможет решить продвинутая модель ИС. По этой причине необходимо выявить завышенные или некомпетентные требования и в работе над ТЗ снизить их значимость.
Запросы пользователей выявляются различными способами, среди которых:
Полученная информация может быть взаимоисключающей, возникает необходимость увязать ее в стройную систему с учетом минимизации затраченных ресурсов. Каждое отдельное требование нужно уточнить, отсечь все лишние потребности, которые станут дополнительной нагрузкой на систему. Такой подход к сбору требований позволит выявить и заложить в архитектуру системы действительные бизнес-цели, а не представления отдельных подразделений о том, как все должно работать на максимальном уровне.
Собранная информация документируется в виде технического задания (ТЗ) – приложения к договору на разработку, что снижает риски, связанные с несогласованностью действий сторон в процессе дальнейшей работы. Составлению ТЗ предшествует этап переговоров, в которых задача по уравновешиванию интересов ложится на разработчика, обязанного осветить все плюсы и минусы заявленных требований с точки зрения целесообразности и бюджетирования.
В системе Requirements Analysis по SWEBOK, описывающей параметры создания ИС, уточняется, что требования бывают функциональными и нефункциональными, зависящими от внутренних и внешних факторов, приоритетными или вторичными, изменяемыми и стабильными. Каждая заявка анализируется по этим параметрам.
Требования к информационной системе, описанные в ТЗ, на практике должны отвечать следующим критериям:
После того, как все эти факторы учтены в ТЗ и проведен анализ требований, оно наполняется конкретными параметрами и требованиями к разработке информационной системы. Требования должны опираться на:
Данные ложатся в основу модели ИС, которая согласовывается вновь и наполняется конкретными цифрами и сроками. Бюджетные и временные характеристики опираются на необходимость установки конкретного оборудования или программного обеспечения и стоимость оборудования, лицензий, учитывают потребность в доработке программных продуктов, время на монтаж и внедрение элементов. При разработке требований можно руководствоваться и ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». Если требования ГОСТа учитываются, снижается риск конфликта интересов и разработка системы идет быстрее. Если модель системы подлежит согласованию, например, с вышестоящими организациями, утвердить предложенное решение будет легче.
Умение работать с требованиями по созданию ИС станет основой для формирования работоспособного инструмента который облегчает работу компании и приносит ей прибыль.
Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.
Если коротко, то основные этапы разработки требований — это:
Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель, либо вы некорректно поставили задачу.
Как известно, неверная задача может обойтись довольно дорого. Например, если полгода команда из 5 программистов разрабатывала систему, которая никому не была нужна.
В наш беспокойный век Agile разработкой требований часто пренебрегают. Но гибкие методологии не всегда спасают от больших потерь. Поэтому, даже если у вас нет аналитика на проекте, даже если вы вообще не IT — не забывайте про здравый смысл и берите из лучших практик то, что нужно в данный момент.
Так что же такое требования и почему важно уметь их разрабатывать?
Итак, обратимся к истокам:
То есть о требованиях можно говорить, как о будущих свойствах. Как о том, каким будет продукт, удовлетворяющий целям разработки.
С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.
1. Зачем?
Как бы “ASAP. ” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.
Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.
Заказчик попросит срочно показывать ему все заказы, которые были сделаны в системе. Допустим, мы напряглись и впихнули посреди спринта задачу на отображение всех заказов для администратора. После этого заказчик просит выводить в отдельном окне список всех компаний, чьи заказы он видит. Сделали и это. Потом заказчик просит выводить дополнительно вообще все компании-партнеры. Окей… Через какое-то время мы встречаемся с заказчиком и видим, как он выгружает оба списка в эксель, ВПРит разницу и начинает обзванивать компании, у которых нет заказов, чтобы напомнить им, что нужно делать заказы через нашу систему.
Если бы мы с самого начала спросили у заказчика, какую цель он хочет достичь, просматривая все заказы — мы бы сэкономили кучу времени и сил, сразу сделав отчет с компаниями, которые не делали пока заказы.
Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.
Определившись с целью необходимо четко ее обозначить и установить критерии, по которым вы сможете точно сказать, что цель достигнута.
Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.
Это облегчает понимание задач и в то же время развязывает руки в выборе средств достижения цели.
И да, не забывайте согласовывать эту красоту с заказчиками. Вообще не забывайте согласовывать требования со всеми заинтересованными сторонами.
2. Что?
Цель достигается разными путями. И второй важный шаг при разработке требований как раз про выбор пути — что конкретно мы будем делать, чтобы прийти к цели.
Чтобы сократить процесс согласования счетов, мы можем:
А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.
Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.
В. Автоматически распознавать сканы счетов и сравнивать данные с цифрами из системы закупок. Ручная проверка и согласование не потребуются.
Чтобы продумать все варианты, надо разобраться — а что же происходит сейчас? Как устроен процесс без вашей системы, как работают пользователи и заказчики? Даже если процесса еще нет, подробная информация про текущее состояние очень важна. Так мы поймем, какое решение устранит проблему, а не создаст еще одну.
У каждого варианта реализации свои плюсы и минусы, свои необходимые ресурсы и свой уровень результата. Смоделировав все опции, проработав или хотя бы просто проговорив с заинтересованными сторонами эту информацию — вы сможете сделать взвешенный и обоснованный выбор.
3. Как?
Итак, мы поняли нашу цель и что мы будем делать, чтобы ее достичь. Осталось разобраться с тем — как мы это реализуем: какие страницы будем показывать пользователям, в каком виде отобразим отчет для заказчика, как получим данные из другой системы, как будем хранить их у себя и так далее.
Этот этап — дело техники. И если вы успешно прошли предыдущие два — будет гораздо проще. Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса и других умных людей. Если для вас какой-то тип требований сейчас не актуален — окей, не описываем. Но важно не забыть и проверять себя.
На каждое бизнес-требование, как правило, приходится несколько пользовательских. Пользовательское требование декомпозируется на какое-то число функциональных. К каждому функциональному требованию нужно продумать нефункциональные требования и ограничения.
Также нефункциональные требования и ограничения могут напрямую вытекать как из пользовательских требований, так и из бизнес-требований и правил. Таким образом получаются деревья из требований, в вершине каждого из которых — бизнес-требование.
4. Когда?
В “лесу” ваших требований скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно всю эту красоту документировать и представлять в виде таблиц и диаграмм.
Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.
Если у вас получается объяснять всем, что и как вы хотите сделать с системой, при помощи салфетки и 3х пятен от кофе — значит вы Джон Уик от аналитики и это потрясающе.
Однако, как правило, «пятенный» уровень детализации не позволяет увидеть подводные камни и продумать все возможные сценарии. Ведь вроде и так все понятно, а нарисовал схемку — и вот тебе и бесконечный вызов, и забытая ветка процесса, и кратчайший путь к золоту. Поэтому полезно знать, какие есть инструменты для обращения хаоса в порядок.
В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).
А дальше можно уже раскидывать по спринтам/этапам разработки и внедрения. Ну и повторять эти упраженения в рамках каждой итерации. И будет вам счастье — никаких переделок, довольный заказчик, счастливая команда, работающий и приносящий пользу продукт, эльфы играют на арфе на фоне радуги.
Конечно, проблемы будут всегда. Будут переделки, сгоревшие дедлайны и баги. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.
Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.
Системные требования и требования к программному обеспечению
Существуют различные трактовки понятия «Системные требования» ( system requirements ).
INCOSE (International Council on Systems Engineering ) дает более детальное определение системы: «комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы». Таким образом, происходит разделение между системными требованиями, как обобщающему понятию и требованиями к программному обеспечению, как выделенному подмножеству системных требований, направленных исключительно на программные компоненты системы. Этот же подход прослеживается в стандарте ГОСТ Р ИСО/МЭК 12207/99 [2.8]: работы, связанные с системой в целом и с программным обеспечением выделяются в отдельные группы в целях удобства оперирования.
Функциональные, нефункциональные требования и характеристики продукта
Функциональные требования регламентируют функционирование или поведение системы (behavioral requirements). Функциональные требования отвечают на вопрос «что должна делать система» в тех или иных ситуациях. Функциональные требования определяют основной «фронт работ» Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.
Нефункциональные требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы. К. Вигерс [2.2] выделяет следующие основные группы нефункциональных требований:
Среди внешних интерфейсов в большинстве современных АИС наиболее важным является интерфейс пользователя (User Interface, UI). Кроме того, выделяются интерфейсы с внешними устройствами (аппаратные интерфейсы), программные интерфейсы и интерфейсы передачи информации (коммуникационные интерфейсы).
Основные атрибуты качества:
достаточно хорошо раскрыты в модели FURPS (см. ниже).
Существует и более общий взгляд на данное понятие [2.9]: «features могут быть как относящимися к функциональным, так и к нефункциональным требованиям и могут изменяться от версии к версии продукта».
С.Орлик в [2.6] отмечает, что «с точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными».
Роль характеристик проявляется в первую очередь в области маркетинга: не всякий потенциальный потребитель продукта станет читать его функциональные описания, а набор ключевых характеристик, характеризующих конкурентные преимущества, можно сделать лаконичным и уместить на одной странице рекламной листовки, либо напечатать на компакт-диске.
Классификация RUP
В спецификациях Rational Unified Process при классификации требований используется модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990 [2.1].
Акроним FURPS обозначает следующие категории требований:
Символ «+» расширяет FURPS-модель, добавляя к ней:
часть из которых уже была рассмотрена выше.
Кроме того, в спецификациях RUP выделяются такие категории требований, как
FURPS (Functionality Usability Reliability Performance Supportability: функциональность, удобство использования, надежность, производительность, удобство сопровождения)— классификация требований к программным системам, разработанная в Hewlett-Packard. Согласно классификации, все требования подразделяются на 5 категорий, непосредственно следующих из составляющих наименования классификации. В настоящее время используется, как составная часть более общей классификации FURPS+.
FURPS+ (Functionality Usability Reliability Performance Supportability +: функциональность, удобство использования, надежность, производительность, удобство сопровождения, дополнительные требования) — расширенная версия классификации требований FURPS. Дополнительно включает в себя ограничения, разделенные на следующие группы требований:
Подробно описана в работе Роберта Грейди.
Методологии и стандарты, регламентирующие работу с требованиями
Среди основополагающих нормативных документов в области работы с требованиями можно выделить следующие.
