Требование

В инженерии требование — это условие , которое должно быть удовлетворено, чтобы результат работы был приемлемым. Это явное, объективное, ясное и часто количественное описание условия, которому должен удовлетворять материал, конструкция, продукт или услуга. ^[1]

Спецификация или спецификация — это набор требований, который обычно используется разработчиками на этапе проектирования продукта и тестировщиками в процессе проверки.

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

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

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

Происхождение термина

Термин «требование» используется в сообществе разработчиков программного обеспечения по крайней мере с 1960-х годов. ^[2]

Согласно Руководству по Своду знаний по бизнес-анализу® версии 2 от IIBA (BABOK), ^[3] требование такое:

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

Это определение основано на IEEE 610.12-1990: Стандартный глоссарий терминологии разработки программного обеспечения IEEE. ^[4]

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

Можно сказать, что требования относятся к двум областям:

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

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

Типы требований

Требования обычно классифицируются по типам, создаваемым на разных этапах разработки, при этом таксономия зависит от используемой модели в целом. Например, следующая схема была разработана Международным институтом бизнес-анализа в их «Своде знаний по бизнес-анализу». ^[5] (см. также ФУРПС и Виды требований ).

Архитектурные требования: Архитектурные требования объясняют, что необходимо сделать, определяя необходимую интеграцию структуры системы и поведения системы , т. е. системную архитектуру системы.; В разработке программного обеспечения их называют архитектурно значимыми требованиями , которые определяются как те требования, которые оказывают измеримое влияние на архитектуру программной системы . ^[6]

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

Требования пользователя (заинтересованных сторон): Заявления среднего уровня о потребностях конкретной заинтересованной стороны или группы заинтересованных сторон. Обычно они описывают, как кто-то хочет взаимодействовать с предполагаемым решением. Часто выступает в качестве промежуточной точки между бизнес-требованиями высокого уровня и более подробными требованиями к решению.

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

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

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

Характеристики хороших требований

Характеристики хороших требований по-разному формулируются разными авторами, причем каждый автор обычно подчеркивает характеристики, наиболее подходящие для его общего обсуждения или конкретной рассматриваемой технологической области. Однако общепризнанными являются следующие характеристики. ^[8] ^[9]

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

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

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

Проверка

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

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

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

Действия, которые приводят к выработке требований к системе или программному обеспечению. Разработка требований может включать технико-экономическое обоснование или этап концептуального анализа проекта, а также выявление требований (сбор, понимание, анализ и формулирование потребностей заинтересованных сторон ) и анализ требований . ^[10] анализ (проверка последовательности и полноты), спецификация (документирование требований) и валидация (проверка правильности указанных требований). ^[11]^[12]

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

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

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

Гибкие подходы развивались как способ преодоления этих проблем путем определения базовых требований на высоком уровне и проработки деталей « точно в срок» или в последний ответственный момент .

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

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

Изменения в требованиях

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

Проблемы

Конкурирующие стандарты

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

Споры относительно необходимости и последствий требований к программному обеспечению

Многие проекты увенчались успехом при незначительном или полном отсутствии согласия по требованиям. ^[13] Кроме того, некоторые данные указывают на то, что уточнение требований может снизить креативность и эффективность проектирования. ^[14] Требования мешают творчеству и дизайну, потому что дизайнеры слишком озабочены предоставленной информацией. ^[15]^[16]^[17] В более общем плане некоторые исследования показывают, что требования к программному обеспечению — это иллюзия, созданная путем искажения проектных решений как требований в ситуациях, когда реальные требования не очевидны. ^[18]

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

Требования ползут

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

Таксономия нескольких требований

Существует несколько таксономий требований в зависимости от того, в какой структуре они работают. (Например, подходят заявленные стандарты IEEE, Vice IIBA или US DoD). Различный язык и процессы в разных местах или непринужденная речь могут вызвать путаницу и отклонение от желаемого процесса.

Повреждения процесса

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

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

В рамках процесса Министерства обороны США можно привести некоторые исторические примеры проблем с требованиями:

проблемы М-2 Брэдли, связанные с движением случайных требований, изображенные в «Войнах Пентагона» ;
рост F-16 из концепции легкого истребителя истребительной мафии , приписываемый программе F-15, пытающейся саботировать конкуренцию, или отдельным офисам, реализующим местные желания, подрывающим концепцию легкости и низкой стоимости.
энтузиазм ок. 1998 год для «Net-Ready» привел к тому, что его мандат в качестве ключевого параметра производительности был получен от офиса Net-Ready, вне процесса определения требований офиса и не соответствовал ранее определенному процессу этого офиса, их определению того, что такое KPP, или что некоторые усилия может оказаться неподходящим или неспособным определить, что представляет собой «Net-Ready».

См. также

Бизнес-требования
Требования к программному обеспечению
Разработка требований
Анализ требований
Выявление требований
Управление требованиями
Приоритизация требований
Отслеживаемость требований
Спецификация (технический стандарт)
Должен и будет - формулировка
Метод MoSCoW – техника расстановки приоритетов
История пользователя
Вариант использования

Ссылки

^ Форма и стиль стандартов, Синяя книга ASTM (PDF) . АСТМ Интернешнл . 2012 . Проверено 5 января 2013 г.
^ Бём, Барри (2006). «Взгляд на разработку программного обеспечения 20 и 21 веков» . ICSE '06 Материалы 28-й международной конференции по программной инженерии . Университет Южной Калифорнии, кампус Университетского парка, Лос-Анджелес, Калифорния: Ассоциация вычислительной техники, ACM Нью-Йорк, Нью-Йорк, США. стр. 12–29. ISBN 1-59593-375-1 . Проверено 2 января 2013 г.
^ «1.3 Ключевые понятия - IIBA | Международный институт бизнес-анализа» . www.iiba.org . Проверено 25 сентября 2016 г.
^ «IEEE SA-610.12-1990 — Стандартный словарь терминологии программной инженерии IEEE» . Архивировано из оригинала 10 января 2011 года.
^ Ииба; Анализ, Международный институт бизнеса (2009). Руководство по своду знаний по бизнес-анализу® (Руководство BABOK®), версия 2.0 . ISBN 978-0-9811292-1-1 . {{cite book}}: |first2= имеет общее имя ( справка )
^ Чен, Ляньпин; Али Бабар, Мухаммед; Нусейбе, Башар (2013). «Характеристика архитектурно значимых требований». Программное обеспечение IEEE . 30 (2): 38–45. дои : 10.1109/MS.2012.174 . hdl : 10344/3061 . S2CID 17399565 .
^ Ральф П. и Ванд Ю. Предложение по формальному определению концепции дизайна. Лютинен К., Лукопулос П., Милопулос Дж. и Робинсон В. (ред.), Разработка требований к проектированию: десятилетняя перспектива: Springer-Verlag, 2009, стр. 103–136.
^ Дэвис, Алан М. (1993). Требования к программному обеспечению: объекты, функции и состояния, второе издание . Прентис Холл. ISBN 978-0-13-805763-3 .
^ Компьютерное общество IEEE (1998). Рекомендуемая практика IEEE для спецификаций требований к программному обеспечению . Институт инженеров по электротехнике и электронике, Inc. ISBN 978-0-7381-0332-7 .
^ Стеллман, Эндрю; Грин, Дженнифер (2005). Управление проектами прикладного программного обеспечения . О'Рейли Медиа. п. 98. ИСБН 978-0-596-00948-9 . Архивировано из оригинала 9 февраля 2015 г.
^ Вигерс, Карл Э. (2003). Требования к программному обеспечению, второе издание . Майкрософт Пресс. ISBN 978-0-7356-1879-4 .
^ Янг, Ральф Р. (2001). Практика эффективных требований . Аддисон-Уэсли. ISBN 978-0-201-70912-4 .
^ Чекленд, Питер (1999). Системное мышление, системная практика . Чичестер: Уайли.
^ Ральф, Пол; Моханани, Рахул (май 2015 г.). «Является ли разработка требований по своей сути контрпродуктивной?» . Материалы 5-го международного семинара «Твин Пикс требований и архитектуры» . Флоренция, Италия: IEEE. стр. 20–23.
^ Янссон, Д.; Смит, С. (1991). «Фиксация дизайна». Дизайнерские исследования . 12 (1): 3–11. дои : 10.1016/0142-694X(91)90003-F .
^ Перселл, А.; Геро, Дж. (1996). «Дизайн и другие виды фиксации». Дизайнерские исследования . 17 (4): 363–383. дои : 10.1016/S0142-694X(96)00023-3 .
^ Моханани, Рахул; Ральф, Пол; Шрив, Бен (май 2014 г.). «Фиксация требований» . Материалы международной конференции по программной инженерии . Хайдарабад, Индия: IEEE. стр. 895–906.
^ Ральф, Пол (2012). «Иллюзия требований в разработке программного обеспечения». Инженерия требований . 18 (3): 293–296. arXiv : 1304.0116 . дои : 10.1007/s00766-012-0161-4 . S2CID 11499083 .

Внешние ссылки

Определение системных требований

[1] Форма и стиль стандартов, Синяя книга ASTM (PDF) . АСТМ Интернешнл . 2012 . Проверено 5 января 2013 г.

[2] Бём, Барри (2006). «Взгляд на разработку программного обеспечения 20 и 21 веков» . ICSE '06 Материалы 28-й международной конференции по программной инженерии . Университет Южной Калифорнии, кампус Университетского парка, Лос-Анджелес, Калифорния: Ассоциация вычислительной техники, ACM Нью-Йорк, Нью-Йорк, США. стр. 12–29. ISBN 1-59593-375-1 . Проверено 2 января 2013 г.

[3] «1.3 Ключевые понятия - IIBA | Международный институт бизнес-анализа» . www.iiba.org . Проверено 25 сентября 2016 г.

[4] «IEEE SA-610.12-1990 — Стандартный словарь терминологии программной инженерии IEEE» . Архивировано из оригинала 10 января 2011 года.

[5] Ииба; Анализ, Международный институт бизнеса (2009). Руководство по своду знаний по бизнес-анализу® (Руководство BABOK®), версия 2.0 . ISBN 978-0-9811292-1-1 . {{cite book}}: |first2= имеет общее имя ( справка )

[ASR_Chen-6] Чен, Ляньпин; Али Бабар, Мухаммед; Нусейбе, Башар (2013). «Характеристика архитектурно значимых требований». Программное обеспечение IEEE . 30 (2): 38–45. дои : 10.1109/MS.2012.174 . hdl : 10344/3061 . S2CID 17399565 .

[7] Ральф П. и Ванд Ю. Предложение по формальному определению концепции дизайна. Лютинен К., Лукопулос П., Милопулос Дж. и Робинсон В. (ред.), Разработка требований к проектированию: десятилетняя перспектива: Springer-Verlag, 2009, стр. 103–136.

[Davis93-8] Дэвис, Алан М. (1993). Требования к программному обеспечению: объекты, функции и состояния, второе издание . Прентис Холл. ISBN 978-0-13-805763-3 .

[IEEE_830-1998_standard-9] Компьютерное общество IEEE (1998). Рекомендуемая практика IEEE для спецификаций требований к программному обеспечению . Институт инженеров по электротехнике и электронике, Inc. ISBN 978-0-7381-0332-7 .

[10] Стеллман, Эндрю; Грин, Дженнифер (2005). Управление проектами прикладного программного обеспечения . О'Рейли Медиа. п. 98. ИСБН 978-0-596-00948-9 . Архивировано из оригинала 9 февраля 2015 г.

[Wiegers03-11] Вигерс, Карл Э. (2003). Требования к программному обеспечению, второе издание . Майкрософт Пресс. ISBN 978-0-7356-1879-4 .

[Young01-12] Янг, Ральф Р. (2001). Практика эффективных требований . Аддисон-Уэсли. ISBN 978-0-201-70912-4 .

[13] Чекленд, Питер (1999). Системное мышление, системная практика . Чичестер: Уайли.

[14] Ральф, Пол; Моханани, Рахул (май 2015 г.). «Является ли разработка требований по своей сути контрпродуктивной?» . Материалы 5-го международного семинара «Твин Пикс требований и архитектуры» . Флоренция, Италия: IEEE. стр. 20–23.

[15] Янссон, Д.; Смит, С. (1991). «Фиксация дизайна». Дизайнерские исследования . 12 (1): 3–11. дои : 10.1016/0142-694X(91)90003-F .

[16] Перселл, А.; Геро, Дж. (1996). «Дизайн и другие виды фиксации». Дизайнерские исследования . 17 (4): 363–383. дои : 10.1016/S0142-694X(96)00023-3 .

[17] Моханани, Рахул; Ральф, Пол; Шрив, Бен (май 2014 г.). «Фиксация требований» . Материалы международной конференции по программной инженерии . Хайдарабад, Индия: IEEE. стр. 895–906.

[18] Ральф, Пол (2012). «Иллюзия требований в разработке программного обеспечения». Инженерия требований . 18 (3): 293–296. arXiv : 1304.0116 . дои : 10.1007/s00766-012-0161-4 . S2CID 11499083 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]