Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

В области проектирования требований , требования выявление практик исследования и обнаружения требований системы от пользователей, клиентов и других заинтересованных сторон. [1] Эту практику также иногда называют « сбором требований ».

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

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

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

Проблемы [ править ]

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

В 1992 году Кристель и Канг определили проблемы, которые указывают на трудности при выявлении требований: [3]

  1. « Проблемы масштаба» . Границы системы нечетко определены или клиенты / пользователи указывают ненужные технические детали, которые могут запутать, а не прояснить общие цели системы.
  2. Проблемы понимания . Заказчики / пользователи не полностью уверены в том, что им необходимо, плохо понимают возможности и ограничения своей вычислительной среды, не имеют полного представления о проблемной области, испытывают проблемы с сообщением о потребностях системному инженеру, упускают информацию которые считаются « очевидными », определяют требования, которые противоречат потребностям других клиентов / пользователей, или определяют требования, которые являются неоднозначными или непроверяемыми.
  3. Проблемы волатильности . Требования меняются со временем. Скорость изменения иногда называют уровнем волатильности требований.

Качество требований можно улучшить с помощью следующих подходов: [4]

  1. Визуализация . Использование инструментов, способствующих лучшему пониманию желаемого конечного продукта, таких как визуализация и моделирование.
  2. Единый язык . Использование простых, последовательных определений требований, описанных на естественном языке, и использование бизнес-терминологии, распространенной на предприятии.
  3. Рекомендации . Соблюдение организационных принципов, описывающих методы сбора и типы требований, которые необходимо собрать. Эти руководящие принципы затем последовательно используются во всех проектах.
  4. Последовательное использование шаблонов . Создание согласованного набора моделей и шаблонов для документирования требований.
  5. Документирование зависимостей . Документирование зависимостей и взаимосвязей между требованиями.
  6. Анализ изменений . Выполнение анализа первопричин изменений требований и внесение корректирующих действий.

Рекомендации [ править ]

В 1997 году Соммервилль и Sawyer предложил набор руководящих принципов для выявления требований, для решения проблем , таких как те , которые были определены Кристел и Кан: [5]

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

Последовательность шагов [ править ]

В 2004 году Голдсмит предложил «пирамиду проблем» из «шести шагов, которые необходимо выполнять последовательно»: [6]

  1. Определите реальную проблему, возможность или вызов
  2. Определите текущие меры, которые показывают, что проблема реальна.
  3. Определите целевые меры, чтобы показать, что проблема решена, и ценность ее решения.
  4. Определите «как есть» причину (ы) проблемы, поскольку устранять необходимо именно причины, а не непосредственно проблему.
  5. Определите бизнес-«желания», которые должны быть выполнены для достижения поставленной цели.
  6. Определите дизайн продукта, который соответствует реальным бизнес-требованиям.

Однако Голдсмит отмечает, что выявить настоящую проблему «чрезвычайно сложно». [6]

Дополнительные подходы [ править ]

В 2009 году Александер и Беус-Дукич предложили набор дополнительных подходов к обнаружению требований: [7]

Александер и Беус-Дукич предположили, что эти подходы могут быть реализованы с отдельными людьми (как в интервью ), с группами (как на целевых встречах, известных как семинары, или через электронные системы встреч ), или из «вещей» (артефактов), таких как прототипы . [7]

Нефункциональные требования [ править ]

В 2009 году Миллер предложил набор из более чем 2000 вопросов для выявления нефункциональных требований. [8] Ее подход состоит в том, чтобы составить профиль заинтересованной стороны, а затем провести подробное интервью с ней. Вопросы сгруппированы в три раздела, все ориентированы на потребности пользователей: [8]

  1. Операция: насколько хорошо используется [требуется редактирование]?
  2. Доработка: насколько легко исправить ошибки и добавить функции?
  3. Переход: насколько легко адаптироваться к изменениям в технической среде?

В 2013 году Мурали Чемутури предложил использовать требования к вспомогательной функциональности вместо нефункциональных требований, поскольку «нефункциональные» означает «никогда не работоспособные». Во-вторых, эти требования фактически выполняют некоторые требования, которые поддерживают основные или основные функциональные требования. [9]

Библиография [ править ]

  • Александр, Ян Ф .; Беус-Дукич, Лерка (март 2009 г.). Обнаружение требований: как указать продукты и услуги . Джон Вили. ISBN 978-0-470-71240-5.
  • Голдсмит, Робин Ф. (2004). Обнаружение требований реального бизнеса для успеха программного проекта . Артек Хаус. ISBN 1-58053-771-5.
  • Миллер, Роксана Э. (2009). Поиски требований к программному обеспечению: вопросы исследования, чтобы сфокусировать внимание на нефункциональных требованиях; Проверенные методы для вовлечения нужных заинтересованных сторон . Книги MavenMark. ISBN 978-1-59598-067-0.
  • Соммервилль, Ян ; Сойер, Пит (май 1997). Разработка требований: руководство по передовой практике . Джон Вили. ISBN 0-471-97444-7. CS1 maint: обескураженный параметр ( ссылка )
  •  Гобов, Денис, Гученко, Инна. (2020). Методы выявления требований для программных проектов в украинских ИТ: исследовательское исследование. http://dx.doi.org/10.15439/2020F16 .

Ссылки [ править ]

  1. ^ Разработка требований, руководство по хорошей практике, Рамос Роуэл и Куртс Алфеш, Джон Вили и сыновья, 1997
  2. ^ Kusiak, январь «Как Интервью вашего босса» . IRM обучение .
  3. ^ Кристель, Майкл и Кио К. Канг (сентябрь 1992 г.). «Проблемы при выявлении требований» . Технический отчет CMU / SEI-92-TR-012 . CMU / SEI . Проверено 14 января 2012 года . CS1 maint: обескураженный параметр ( ссылка )
  4. ^ «Веб-семинар практикующего специалиста по требованиям PMI по требованиям. Качество» .
  5. Перейти ↑ Sommerville and Sawyer, 1997.
  6. ^ a b Goldsmith, 2004. Стр. 12
  7. ^ a b Александр и Беус-Дукич, 2009.
  8. ^ a b Миллер, 2009.
  9. ^ Chemuturi, М. (2013). Разработка требований и управление проектами разработки программного обеспечения . DOI : 10.1007 / 978-1-4614-5377-2 . ISBN 978-1-4614-5376-5. S2CID  19818654 . CS1 maint: обескураженный параметр ( ссылка )