Требование

Записаться

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

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

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

Жизненный цикл требования начинается в момент возникновения определенной идеи, направленной на повышение ценности выполняемой работы. Любое требование начинается с идеи. В этот момент идея – неформализованный набор гипотез и предположений о том, как можно сделать процесс или продукт более ценным. Чтобы идея продолжила развиваться и нашла своих приверженцев, необходимо оформить ее в концепцию, в которой приводится описание рабочего контекста и место в этом контексте для фактора или факторов, на которые мы хотим повлиять, внедряя и развивая нашу идею. На этой стадии необходимо учесть уже существующие в компании бизнес-правила, которые будут ограничивать и направлять нашу идею. Бизнес-правило – это конкретное проверяемое существующее управленческое указание, которое является условием или критерием принятия решения. Оно всегда понятно, конкретно, уже сформулировано в рабочей деятельности в виде используемого документа и не требует дополнительной интерпретации для применения в бизнес-деятельности. Бизнес-правила – это источник многих бизнес-требований, но не только источник, но и рамки, которые позволят вписать концепцию в конкретное рабочее окружение. Бизнес-требования должны соответствовать специфике компании и выполняемого вида деятельности. Они должны содержать обоснования и формализацию того, какую ценность можно будет достигнуть, выполнив конкретное бизнес-требование. Бизнес-требования должны быть понятны широкой аудитории пользователей и не содержать неясностей и множественных толкований. В их формулировке необходимо добиться ясности, понятности для специалистов, которые в последующем будут использовать бизнес-требования для своих рабочих активностей. Любые бизнес-требования вписываются в существующие ограничения и формулируют свои ограничения, которые дополняют или изменяют первоначальные. Эти ограничения могут стать новыми бизнес-правилами. Любые бизнес-требования реализуются за счет действий конкретных пользователей. Для того чтобы выполнить трассировку между бизнес-целями и регламентацией пользовательского процесса, формулируются пользовательские требования, которые описывают алгоритм и способ работы пользователей в конкретной информационной системе или наборе информационных систем. Пользовательские требования формулируются от имени пользователя. В них описываются факторы, которые наиболее важны с точки зрения выполняемых рабочих операций. Уж если мы говорим о пользователе, то важной частью его работы является интерфейс, через который он будет взаимодействовать в информационной системе. Этот интерфейс должен быть понятным, ясным и подходящим для решения конкретной задачи или набора задач конкретной целевой аудиторией пользователей. Направления деятельности, которые изучают эти аспекты, называются UI и UIH. Требования должны содержать информацию для запуска этих процессов. Требования к интерфейсам – это верхушка требований пользователей. Айсберг, который остался под водой, – функциональные требования. Это описание того, как система будет реализовывать заданные алгоритмы поведения пользователей. Это требования к способам обработки введенных с интерфейсов данных пользователей, требования к хранению этих данных, требования к тому, как эти данные будут жить и утилизироваться в конкретной информационной системе или наборе систем. Вот тут мы подошли к следующей группе требований. Требования к смежным системам – это требования к источникам данных и требования к потребителям данных, которые мы передаем после того, как они выполнили свое назначение в нашей информационной системе. Эти требования к поставщикам и потребителям на текущий момент развития отрасли информационных технологий являются самыми важными и бурно развивающимися. Как мы взаимодействуем с системами, в каком формате принимаем и передаем данные. Требования к интерфейсам, функциональные требования, требования к смежным системам в совокупности составляют функциональные требования – то есть требования к тому, как система работает с своими пользователями. Есть еще одна группа требований, которые по сложности и полноте описания, наверное, должны быть самыми объемными. Это требования к атрибутам качества, то есть к тому, как система функционирует. Основными группами атрибутов качества являются надежность, удобство использования, производительность, удобство сопровождения и переносимость. Работа с атрибутами качества предполагает наличие развитой культуры работы с требованиями и, как правило, является головной болью не аналитика, а архитектора программного обеспечения. Для того чтобы не запутаться в многообразии требований и дать несколько «якорей» к инженерии требований, попробуем дать несколько формальных определений.

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

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

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

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

После того как мы декомпозировали требования, нужно обратить внимание на активность приоритизации. Суть этого мы уже немного обсудили – она состоит в упорядочивании ценных требований по какой-то единой шкале. Шкала обсуждается и согласовывается для конкретного проекта, процесса или компании. Существует много подходов к приоритизации, но все они учитывают два основных фактора приоритизации. Первый – наличие данных для объективизации шкалы оценки. Второй – наличие экспертов, которые смогут на основе имеющихся данных или своих гипотез определить важность того или иного фактора. Эти две шкалы традиционно называют количественным и качественным взглядом на оценку. Любая приоритизация начинается с экспертной, то есть качественной оценки и постепенно движется в сторону числовой, то есть количественной оценки. Наиболее известные, используемые и хорошо себя зарекомендовавшие методы приоритизации – это финансово-стоимостной анализ, Balanced Scorecard (BSC), User Story Mapping (USM), матрица Эйзенхауэра, метод ABC, метод MoSCoW. Применение каждого метода должно быть обосновано с точки зрения условия работы с требованиями. Не имеет смысла выбирать количественные методы там, где не собираются данные и не выполняется подсчет прогнозируемой ценности. Но, как показывает практика, каждая организация по мере развития движется именно в сторону количественных методик. Чтобы правильно выбрать методику, нужно проанализировать рабочий контекст.

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

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

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

Самыми яркими представителями экспертных методов приоритизации являются Net-Promotion – решения на основе предпочтений клиентов, матрица Эйзенхауэра – приоритизированная по важности и срочности работа, Shortest Job First (SJF) – «сначала делайте наиболее простую работу, которая принесет быстрые результаты», метод MoSCoW – приоритизированная по ценности работа, User Story Mapping (USM) – методика приоритизации для agile-компаний и проектов, и ABC – субъективная приоритизация.

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

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

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

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

В области проектирования существуют более специализированные и формализованные инструменты, так как область проектирования более узконаправленна по сравнению с анализом и работает с его результатами. Традиционно лидер в области проектирования – это специализированное семейство диаграмм UML. Мы говорили об этих инструментах и будем продолжать это делать. Сейчас уточним, что наиболее важными для проектирования являются диаграммы из архитектурного фреймворка 4 + 1. Это диаграмма классов, диаграмма последовательности, Use Case и другие. Также для проектирования используются модели, которые позволяют свести требования в единую архитектурную модель. Существуют разные модели и представления. Наиболее популярными являются BPMN, EPC, User Story Map и, например, модная и эффективная модель представления продукта – Canvas. Разные аспекты системы можно представлять разными способами в виде схем, самыми популярными из которых являются нарисованные на доске или на листочке. Это очень мощные инструменты достижения консенсуса общего понимания. Но есть и более сложный инструмент ArchiMate, который агрегирует в себе множество уже рассмотренных схем в едином и сложном инструменте моделирования разных аспектов архитектуры.

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