Требование

Набор критериев, которым должна соответствовать конкретная конструкция, продукт или процесс.

При разработке продукта и оптимизации процессов требование — это отдельная документированная физическая или функциональная потребность, которую призван удовлетворить конкретный проект, продукт или процесс. В формальном смысле он обычно используется в инженерном проектировании , в том числе, например, в системной инженерии , разработке программного обеспечения или проектировании предприятия . Это широкая концепция, которая может относиться к любой необходимой (или иногда желаемой) функции, атрибуту, возможности, характеристике или качеству системы, чтобы она имела ценность и полезность для клиента, организации, внутреннего пользователя или другой заинтересованной стороны. Требования могут иметь разный уровень специфичности; например, спецификация требований или «спецификация» требований (часто неточно называемая «спецификация/спецификации», но на самом деле существуют разные виды спецификаций) относится к явному, весьма объективному/четкому (и часто количественному) требованию (или иногда набор требований), которым должен удовлетворять материал, конструкция, продукт или услуга. ^[1]

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

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

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

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

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

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

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

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

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

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

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

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

Архитектурные требования

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

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

Бизнес-требования

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

Требования пользователя (заинтересованных сторон)

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

Функциональные требования (решение)

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

Требования к качеству обслуживания (нефункциональные)

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

Требования к внедрению (переходу)

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

Нормативные требования

Требования, определенные законами (федеральными, государственными, муниципальными или региональными), контрактами (положениями и условиями) или политиками (на уровне компании, департамента или проекта).

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

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

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

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

Проверка

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

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

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

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

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

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

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

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

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

Требования обычно пишутся как средство общения между различными заинтересованными сторонами. Это означает, что требования должны быть понятны как обычным пользователям, так и разработчикам. Одним из распространенных способов документирования требований является указание того, что должна делать система. Пример: «Подрядчик должен поставить продукцию не позднее даты 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 – техника расстановки приоритетов
• История пользователя
• Вариант использования

Рекомендации

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» .
5. Ииба; Анализ, Международный институт бизнеса (2009). Руководство по своду знаний по бизнес-анализу® (Руководство BABOK®), версия 2.0. ISBN 978-0-9811292-1-1. {{cite book}}: |first2=имеет общее имя ( справка )
6. Чен, Ляньпин; Али Бабар, Мухаммед; Нусейбе, Башар (2013). «Характеристика архитектурно значимых требований». Программное обеспечение IEEE . 30 (2): 38–45. дои : 10.1109/MS.2012.174. hdl : 10344/3061 . S2CID  17399565.
7. Ральф П. и Ванд Ю. Предложение по формальному определению концепции дизайна. Лютинен К., Лукопулос П., Милопулос Дж . и Робинсон В. (ред.), Разработка требований к проектированию: десятилетняя перспектива: Springer-Verlag, 2009, стр. 103–136.
8. Дэвис, Алан М. (1993). Требования к программному обеспечению: объекты, функции и состояния, второе издание. Прентис Холл. ISBN 978-0-13-805763-3.
9. Компьютерное общество IEEE (1998). Рекомендуемая практика IEEE для спецификаций требований к программному обеспечению . Институт инженеров по электротехнике и электронике, Inc. ISBN 978-0-7381-0332-7.
10. Стеллман, Эндрю; Грин, Дженнифер (2005). Управление проектами прикладного программного обеспечения. О'Рейли Медиа. п. 98. ИСБН 978-0-596-00948-9. Архивировано из оригинала 9 февраля 2015 г.
11. Вигерс, Карл Э. (2003). Требования к программному обеспечению, второе издание . Майкрософт Пресс. ISBN 978-0-7356-1879-4.
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.

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

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