Сбор требований для систем с поддержкой машинного обучения

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

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

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

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

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

Пример работы: Обнаружение падения

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

Требования к распутыванию

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

Мир и машина

Чтобы распутать эти опасения, полезно очень внимательно отнестись к тому, какие утверждения относятся к реальному миру («миру»), а какие — к программному обеспечению («машине») и как они соотносятся. В программной инженерии это различие часто обсуждается под названием «Мир и машина» после влиятельной статьи с таким названием. Распутывание обсуждений требований с этим различием может внести большую ясность.

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

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

Итак, чтобы добиться желаемого поведения системы в реальном мире, нам нужно учитывать не только то, как программное обеспечение вычисляет выходные данные из входных данных, но и то, что означают эти входные данные и как интерпретируются выходные данные. Обычно это включает в себя различные допущения, например, что гироскоп в умных часах надежно фиксирует движение часов в физическом пространстве или что вызов службы экстренной помощи принесет помощь упавшему человеку. Чтобы создать надежную систему, важно критически проанализировать предположения и подумать, как спроектировать мир за пределами программного обеспечения, например, какое оборудование установить в устройстве и как обучить аварийно-спасательных служб. Исследователь инженерии требований Майкл Джексон в своей оригинальной статье, посвященной различиям мира и машин, делает следующий вывод: «Решения многих проблем разработки связаны не только с проектированием в мире, но также проектирование мира». То есть одного понимания и проектирования программного обеспечения недостаточно, нам также необходимо понять и спроектировать то, как программное обеспечение взаимодействует с миром, что может включать в себя изменения в мир вне программного обеспечения.

Требования, предположения и спецификации

Важно отметить, что четкое размышление о мире и машине и о том, как машина может взаимодействовать с миром только через датчики и приводы, позволяет нам различать:

Системные требования (REQ) описывают, как система должна работать, полностью выраженные в понятиях мира. Например, умные часы должны вызывать экстренных служб, когда пользователь упал. Системные требования отражают то, что должно происходить в реальном мире, а не то, как программное обеспечение должно обрабатывать данные.
Спецификации (SPEC) описывают ожидаемое поведение программного компонента с точки зрения входных и выходных данных. Например, мы ожидаем, что модель сообщит «обнаружено падение» в качестве выходных данных, если входные данные датчика аналогичны ранее предоставленным данным обучения; или компонент контроллера должен выводить вывод «вызов аварийной службы» через 30 секунд после получения от модели ввода «обнаружено падение», если только другие входные данные не указывают на то, что пользователь нажал кнопку «все в порядке». Спецификации относятся только к концепциям в мире программного обеспечения, таким как входные и выходные данные, но не к концепциям в реальном мире. Спецификации иногда также называют требованиями к программному обеспечению или требованиями к компонентам, чтобы отличать их от системных требований.
Предположения (ASM) выражают отношение реальных концепций к входным и выходным данным программного обеспечения. Например, мы предполагаем, что гироскоп правильно отображает движение смарт-часов, что координаты GPS представляют место падения, введенный вручную контактный адрес для экстренных служб правильно отражает намерение пользователя, и что экстренные службы действительно реагируют на вызов. Предположения — это то, что связывает реальные концепции в системных требованиях с концепциями программного обеспечения в спецификациях.
Реализации (IMPL) обеспечивают фактическое поведение программной системы, которое должно соответствовать спецификации (SPEC), обычно предоставляемой некоторым кодом или исполняемой моделью. Обнаруженное несоответствие между реализацией и спецификацией считается ошибкой. Например, переполнение буфера в контроллере приводит к сбою системы, поэтому выходная команда «вызвать аварийную службу» (выход) не создается, если входные значения, представляющие показания гироскопа, превышают определенное значение (например, из-за необычно сильного падения).

Логически мы ожидаем, что предположения и спецификации программного обеспечения вместе должны гарантировать требуемое поведение системы в реальном мире (ASM ∧ SPEC ⊨ REQ) и что спецификация реализована правильно (IMPL ⊨ SPEC). Однако проблемы возникают, когда…

… системные требования (REQ) совершенно неверны. Например, мы забываем отметить, что смарт-часы не должны вызывать экстренных служб в дом пользователя, если за пределами дома зафиксировано падение.
… предположения (ASM) неверны, нереалистичны, изменяются или отсутствуют. Например, мы (неявно) предположили, что датчик GPS надежен в пределах зданий и что пользователи всегда правильно вводят контактную информацию для аварийно-спасательных служб, но позже обнаруживаем, что это не всегда так. В результате система может не соответствовать системным требованиям, даже если реализация идеально соответствует спецификации.
… спецификация программного обеспечения (SPEC) неверна. Например, в спецификации забыто указать, что вывод «вызов аварийной службы» не должен создаваться, если обнаружен ввод, представляющий, что пользователь нажал кнопку отмены. Опять же, реализация может полностью соответствовать спецификации, но снова привести к поведению, которое не соответствует системным требованиям.
…любая из этих частей внутренне несовместима или несовместима с другими. Например, спецификации программного обеспечения (SPEC) вместе с предположениями (ASM) недостаточно, чтобы гарантировать системные требования (REQ), если указанная логика при вызовах (SPEC) не учитывает механизм повторных попыток или резервный канал связи для возможные проблемы со связью (ASM), чтобы обеспечить фактическую связь с аварийно-спасательными службами (REQ).
… система реализована (IMPL) неправильно, поведение отличается от заданного (SPEC), например, переполнение буфера или неверные выражения в логике управления, например, фактическое ожидание 120 секунд, а не указанные 30 секунд.

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

Катастрофа самолета Lufthansa 2904 на взлетно-посадочной полосе

Классический (не ML) пример того, как неправильные предположения (ASM) могут привести к катастрофе, — это Lufthansa Flight 2904, который потерпел крушение в Варшаве, когда он пересек взлетно-посадочную полосу после того, как пилот не смог вовремя включить реверсоры тяги после приземления.

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

В сравнении с типичным миром и машиной ключевой вопрос заключается в том, что требование безопасности написано в терминах явлений реального мира («самолет в воздухе»), но программное обеспечение просто не может знать, находится ли самолет в воздухе, и должно полагаться на сенсорные входы, чтобы понять мир. С этой целью программное обеспечение Airbus в самолете определяет вес шасси и скорость вращения колес самолета. Идея — предположение (ASM) — заключалась в том, что самолет находится на земле, если на каждую опору шасси приходится не менее 6,3 тонны веса или скорость вращения колес превышает 72 узла. Оба казались довольно безопасными ставками на то, как понять мир с точки зрения доступных сенсорных входов, обеспечивая даже некоторую избыточность, чтобы быть уверенным в том, как интерпретировать состояние мира. Спецификация программного обеспечения (SPEC) тогда заключалась в том, чтобы просто выводить команду на блокировку реверсоров тяги, если ни одно из этих условий не выполняется на измеренных значениях.

К сожалению, в роковой день 1993 года из-за дождя и сильного ветра ни одно из условий не было выполнено в течение нескольких секунд после того, как рейс 2904 авиакомпании Lufthansa приземлился в Варшаве. После приземления из-за аквапланирования колеса недостаточно быстро крутились, а из-за ветра нагружалась только одна стойка шасси. Предположение о том, что значит находиться на земле, было просто неверным для сопоставления состояния в реальном мире с входными сигналами датчиков. Таким образом, программное обеспечение определило на основе своих входных данных, что самолет все еще находится в воздухе, и, таким образом (точно так, как указано), указало, что реверсоры тяги не должны включаться. Здесь реальный мир и то, что программа предполагала о реальном мире, просто не совпадали. Кроме того, система была разработана так, чтобы доверять выходным данным программного обеспечения (предположение о приводе) и, следовательно, не позволяла пилоту перезаписывать программное обеспечение.

Таким образом, системные требования (REQ) были хорошими — самолет действительно не должен был включать реверсоры тяги в воздухе. Реализация (IMPL) правильно соответствовала спецификации (SPEC) — система выдавала ожидаемый результат для заданных входных данных. Проблема заключалась в предположениях (ASM) о том, как система будет интерпретировать реальный мир — думает ли она, что самолет находится в воздухе, или нет.

Вопросы о предположениях в машинном обучении

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

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

Ненадежная человеческая обратная связь: пользователи системы обнаружения падения могут смутиться при падении и решить не звать на помощь после падения. С этой целью пользователь может указать, что он не падал, что может заставить систему интерпретировать прогноз как ложноположительный, что, кроме того, может привести к неправильной маркировке обучающих данных для будущих итераций модели. Понимая это предположение, мы могли бы, например, уточнить пользовательский интерфейс, чтобы различать «я не падал» и «мне сейчас не нужна помощь», или более внимательно относиться к просмотру производственных данных, прежде чем использовать их для обучения.
Дрейф данных. Тренировочные данные были собраны после падений в одной сети домов престарелых в течение длительного периода времени. Мы предположили, что эти места представляют будущую клиентскую базу, но следили за тем, чтобы у пользователей в других местах (например, дома) могли быть плюшевые ковры, что приводило к другим схемам ускорения. Проверка предположений о том, какие обучающие данные являются репрезентативными для целевого распределения, является распространенной проблемой в проектах машинного обучения.
Цикл обратной связи. Мы предполагаем, что пользователи будут повсеместно носить смарт-часы для обнаружения падений. Однако из-за череды ложных срабатываний, возможно, даже связанных с расходами или стрессом от ненужного вызова смотрителей или аварийно-спасательных служб, пользователи могут неохотно носить часы в определенных ситуациях, например, при работе в саду. Как следствие, у нас может быть еще менее надежные обучающие данные и больше ложных срабатываний для таких ситуаций, в результате чего больше пользователей отказываются от своих часов. Мы могли бы пересмотреть наши предположения, чтобы лучше понять, когда и почему пользователи перестают носить часы.
Атаки. Возможно, надуманные, но злоумышленники могут искусственно трясти смарт-часы на тумбочке другого пользователя, чтобы активировать обнаружение падения, пока этот пользователь спит. В зависимости от того, насколько мы обеспокоены такими случаями, мы можем пересмотреть наше предположение о том, что все движения часов происходят, когда часы надеты, и использовать дополнительные датчики для идентификации пользователя и определения того, что падение произошло, когда часы фактически находились на дне. запястье правого пользователя.

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

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

Атаки. При построении системы рекомендаций мы можем (неявно) предположить, что прошлые отзывы отражают честное мнение прошлых клиентов и что прошлые отзывы соответствуют репрезентативной или случайной выборке прошлых клиентов. Даже просто явно записывая такие предположения, можно обнаружить, что они, вероятно, проблематичны и что можно преднамеренно влиять на систему с помощью вредоносных испорченных входных данных (например, фальшивых обзоров, бомбардировок отзывов), тем самым нарушая системные требования, когда продукты с высоким рейтингом могут на самом деле не относятся к продуктам, которые нравятся многим клиентам в реальном мире. Размышляя над этими предположениями, мы можем рассмотреть другие проектные решения в системе, такие как принятие отзывов только от прошлых клиентов, система репутации для оценки отзывов от клиентов, пишущих много отзывов, или использование различных механизмов обнаружения мошенничества. Такие альтернативные проектные решения часто основаны на более слабых или меньшем количестве предположений.
Дрейф концепции: мы можем понять, что не должны предполагать, что отзывы двухлетней давности обязательно отражают сегодняшние предпочтения клиентов, и должны соответствующим образом скорректировать нашу модель, чтобы учесть возраст отзывов. Опять же, мы пересматриваем наши предположения и корректируем спецификацию, чтобы система по-прежнему соответствовала системным требованиям.
Цикл обратной связи. Мы можем понять, что можем ввести цикл обратной связи, поскольку предполагаем, что рекомендации влияют на покупательское поведение, а рекомендации также основаны на покупательском поведении. То есть мы можем сформировать систему таким образом, чтобы продукты, получившие ранние ранние позиции, оставались высоко оцененными, потому что их покупают и оценивают больше всего. Непреднамеренные петли обратной связи часто возникают из-за неправильных или отсутствующих предположений, которые не отражают правильно процессы в реальном мире.

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

Поведенческие требования и требования к качеству

В качестве последнего измерения для распутывания требований системные требования и спецификации программного обеспечения обычно подразделяются на требования к поведению и требования к качеству (также часто называемые функциональными и нефункциональными требованиями). Хотя для некоторых требований различие может быть размытым, поведенческие требования обычно описывают, что должно делать программное обеспечение, тогда как требования к качеству касаются того, как программное обеспечение должно это делать или как оно должно быть построено. Например, в сценарии обнаружения падения спецификацией поведенческой системы является вызов экстренных служб после падения, а спецификацией поведенческого программного обеспечения может быть при получении входных данных «обнаружено падение, активировать выход вызов аварийных служб через 30 секунд»; требованием к системе качества может быть система должна иметь эксплуатационные расходы менее 50 долларов в месяц, а спецификацией качественного программного обеспечения может быть датчик падения должен иметь задержку менее 100 мс. Для всех требований к качеству важно определение четких мер для установления конкретных ожиданий, так же как и для обсуждения целей (см. главу Постановка и измерение целей, чтобы узнать, как определить и оценить меры).

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

Выявление требований

Понимание требований системы, как известно, сложно.

Клиенты часто дают расплывчатое описание того, что они хотели бы, только чтобы потом жаловаться «нет, не так». Например, когда мы спрашиваем потенциальных пользователей умных часов с функцией обнаружения падения, они могут сказать, что предпочитают полностью автоматизировать вызов экстренных служб, но пересматривают это, как только они обнаруживают, что система иногда ошибочно определяет жест рукой как падение. Кроме того, клиенты, как правило, сосредотачиваются на конкретных проблемах со статус-кво, а не думают более широко о том, как могло бы выглядеть хорошее решение. Например, клиенты могут изначально сосредоточиться на сокрытии функции обнаружения падения в смарт-часах, чтобы избежать клейма текущих решений, но не беспокоиться о каких-либо дополнительных функциях.
Трудно охватить требования в целом и легко игнорировать конкретные проблемы. Мы можем построить систему, которая сделает непосредственных клиентов довольными, но все остальные, взаимодействующие с системой, будут жаловаться. Например, дизайн смарт-часов нравится пожилым пользователям, покупающим часы, но раздражает аварийно-спасательных служб плохо разработанными уведомлениями. В частности, проблемы меньшинств или проблемы регулирующих органов (например, конфиденциальность, безопасность, справедливость) могут быть легко упущены, если они не подняты клиентами.
Инженеры могут смириться с нечеткостью требований, предполагая, что они уже понимают, что требуется, и могут заполнить пробелы. Например, инженеры могут предположить, что у них есть хорошая интуиция относительно того, как долго ждать подтверждения о падении, прежде чем звонить в службу экстренной помощи, вместо того, чтобы действительно исследовать проблему, скажем, с помощью пользовательского исследования.
Инженеры любят сосредотачиваться на технических решениях. Когда технически подкованные люди, в том числе инженеры-программисты и специалисты по данным, думают о требованиях, они, как правило, сразу же сосредотачиваются на программных решениях и технических возможностях, опираясь на прошлые решения, а не на всестороннем понимании более крупных системных потребностей. Например, они могут сосредоточиться на том, какая информация доступна и может быть показана в уведомлении, а не на определении того, какая информация действительно необходима аварийно-спасательным службам.
Инженеры предпочитают элегантные абстракции. Заманчиво предложить общие и простые решения, которые игнорируют беспорядок реального мира. Например, толчки от болезни Паркинсона могут сделать показания гироскопа проблематичными, но их можно отбросить как неудобный частный случай, поскольку он не вписывается в общий дизайн системы.

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

Определение заинтересованных сторон

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

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

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

Методы выявления требований

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

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

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

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

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

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

Согласование требований

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

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

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

Требования к документации

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

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

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

Оценка требований

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

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

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

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

Сколько инженерных требований и когда?

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

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

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

Краткое содержание

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

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

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

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

Дальнейшее чтение

Хороший стандартный учебник по разработке требований, в котором гораздо больше подробностей, чем здесь: 🕮 Van Lamsweerde, Axel. Инженерия требований: от системных целей к UML-моделям и программному обеспечению. Джон Уайли и сыновья, 2009 г.
Основополагающий документ по разработке программного обеспечения о проблемах в разработке требований, в частности, о нечетком различии явлений мира и машин: 🗎 Джексон, Майкл. «Мир и машина.» В материалах Международной конференции по программной инженерии. ИИЭР, 1995.
Документ, убедительно доказывающий важность разработки требований при создании программного обеспечения с компонентами машинного обучения, включая обсуждение различных дополнительных качеств, которые следует учитывать, таких как качество данных, происхождение и мониторинг: 🗎 Фогельсанг, Андреас и Маркус Борг. «Разработка требований для машинного обучения: взгляды специалистов по данным.» В проц. 6-го Международного семинара по искусственному интеллекту для разработки требований (AIRE), 2019 г.
В документе описывается, как инженерия требований может быть полезна для лучшего понимания предметной области и контекста проблемы, а также как это помогает лучше курировать высококачественный набор данных для обучения и оценки модели: 🗎 Рахими, Мона, Джин Л.С. Го, Сахар Кокали и Марша Чечик. «На пути к спецификации требований к компонентам с машинным обучением.» В 2019 г. на 27-й Международной конференции по разработке требований (REW) IEEE, стр. 241–244. ИИЭР, 2019.
Документ по машинному обучению, в котором явно рассматривается разница между миром и машиной и то, как справедливость следует рассматривать как системную проблему, а не просто проблему модели: 🗎 Кулинич, Богдан, Ребекка Овердорф, Кармела Тронкосо и Седа Гюрсес. «ПОЦ: защитные технологии оптимизации.» В материалах конференции 2020 г. по справедливости, подотчетности и прозрачности, стр. 177–188. 2020.
Документ с изложением позиции, в котором доказывается важность разработки требований и учитывается множество различных заинтересованных сторон при создании продуктов с поддержкой ML в медицинских учреждениях: 🗎 Винс, Дженна, Сучи Сариа, Марк Сендак, Марзиех Гассеми, Винсент X. Лю, Финале Доши-Велес. , Кеннет Юнг и др. «Не навреди: дорожная карта ответственного машинного обучения для здравоохранения». Природная медицина 25, вып. 9 (2019): 1337–1340.
Документ, иллюстрирующий важность участия в разработке требований на системном уровне и обсуждения предпочтений различных заинтересованных сторон, когда речь идет о справедливости в машинном обучении: 🗎 Биетти, Элеттра. «От мытья этики к избиению этики: взгляд на техническую этику изнутри моральной философии.» В материалах конференции 2020 г. по справедливости, подотчетности и прозрачности, стр. 210–219. 2020.
Пример использования персонажей для рассуждения о требованиях с точки зрения другого человека: 🗎 Гуизани, Мариам, Лара Летоу, Маргарет Бернетт и Анита Сарма. «Гендерная инклюзивность как требование качества: практика и подводные камни.» Программное обеспечение IEEE 37, вып. 6 (2020).

Как и все главы, этот текст выпущен под лицензией Creative Commons 4.0 BY-SA.