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