stringtranslate.com

Требование

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

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

При итеративной и инкрементальной разработке , такой как agile software development , требования разрабатываются параллельно с проектированием и реализацией. При каскадной модели требования завершаются до начала проектирования или реализации.

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

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

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

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

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

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

Это определение основано на IEEE 610.12-1990: Стандартный глоссарий терминов программной инженерии IEEE. [4]

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

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

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

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

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

Архитектурные требования
Архитектурные требования объясняют, что должно быть сделано, путем определения необходимой интеграции структуры системы и поведения системы , т. е. системной архитектуры системы.
В программной инженерии они называются архитектурно значимыми требованиями , которые определяются как те требования, которые оказывают измеримое влияние на архитектуру программной системы . [6]
Бизнес-требования
Высокоуровневые заявления о целях, задачах или потребностях организации. Обычно они описывают возможности, которые организация хочет реализовать, или проблемы, которые она хочет решить. Часто излагаются в бизнес-кейсе .
Требования пользователя (заинтересованной стороны)
Заявления среднего уровня о потребностях конкретного заинтересованного лица или группы заинтересованных лиц. Они обычно описывают, как кто-то хочет взаимодействовать с предполагаемым решением. Часто выступают в качестве промежуточного звена между высокоуровневыми бизнес-требованиями и более подробными требованиями к решению.
Функциональные (решение) требования
Обычно подробные описания возможностей, поведения и информации, которые потребуются для решения. Примеры включают форматирование текста, вычисление числа, модуляцию сигнала. Иногда их также называют возможностями .
Требования к качеству обслуживания (нефункциональные)
Обычно подробные заявления об условиях, при которых решение должно оставаться эффективным, качествах, которые должно иметь решение, или ограничениях, в рамках которых оно должно работать. [7] Примеры включают: надежность, тестируемость, ремонтопригодность, доступность. Они также известны как характеристики , ограничения или возможности .
Требования к внедрению (переходу)
Обычно подробные описания возможностей или поведения требуются только для обеспечения перехода от текущего состояния предприятия к желаемому будущему состоянию, но впоследствии они больше не потребуются. Примерами служат набор персонала, изменение ролей, образование, миграция данных из одной системы в другую.
Нормативные требования
Требования, определенные законами (федеральными, государственными, муниципальными или региональными), контрактами (условиями) или политиками (на уровне компании, департамента или проекта).

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

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

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

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

Проверка

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

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

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

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

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

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

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

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

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

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

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

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

Проблемы

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

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

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

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

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

Требования растут

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

Таксономии множественных требований

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

Процессы искажения

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

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

Смотрите также

Ссылки

  1. ^ Форма и стиль стандартов, ASTM Blue Book (PDF) . ASTM International . 2012 . Получено 5 января 2013 .
  2. ^ Boehm, Barry (2006). «Взгляд на программную инженерию 20-го и 21-го века». ICSE '06 Труды 28-й международной конференции по программной инженерии . Университет Южной Калифорнии, кампус University Park, Лос-Анджелес, Калифорния: Ассоциация вычислительной техники, ACM New York, Нью-Йорк, США. стр. 12–29. ISBN 1-59593-375-1. Получено 2 января 2013 г. .
  3. ^ "1.3 Ключевые концепции - IIBA | Международный институт бизнес-анализа". www.iiba.org . Получено 25.09.2016 .
  4. ^ "IEEE SA - 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology". Архивировано из оригинала 10 января 2011 г.
  5. ^ Iiba; Анализ, Международный институт бизнеса (2009). Руководство по своду знаний по бизнес-анализу® (BABOK® Guide) Версия 2.0. ISBN 978-0-9811292-1-1. {{cite book}}: |first2=имеет общее название ( помощь )
  6. ^ Чен, Ляньпин; Али Бабар, Мухаммад; Нусейбех, Башар (2013). «Характеристика архитектурно значимых требований». IEEE Software . 30 (2): 38–45. doi :10.1109/MS.2012.174. hdl : 10344/3061 . S2CID  17399565.
  7. ^ Ральф, П. и Ванд, И. Предложение по формальному определению концепции дизайна. В Lyytinen, К., Loucopoulos, П., Mylopoulos, Дж . и Robinson, В., (ред.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, стр. 103-136
  8. ^ Дэвис, Алан М. (1993). Требования к программному обеспечению: объекты, функции и состояния, второе издание. Prentice Hall. ISBN 978-0-13-805763-3.
  9. ^ IEEE Computer Society (1998). IEEE Рекомендуемая практика для спецификаций требований к программному обеспечению . Институт инженеров по электротехнике и электронике, Inc. ISBN 978-0-7381-0332-7.
  10. ^ Стеллман, Эндрю; Грин, Дженнифер (2005). Управление прикладными программными проектами. O'Reilly Media. стр. 98. ISBN 978-0-596-00948-9. Архивировано из оригинала 2015-02-09.
  11. ^ Wiegers, Karl E. (2003). Требования к программному обеспечению, второе издание . Microsoft Press. ISBN 978-0-7356-1879-4.
  12. ^ Янг, Ральф Р. (2001). Эффективные требования практики. Addison-Wesley. ISBN 978-0-201-70912-4.
  13. ^ Чекленд, Питер (1999). Системное мышление, системная практика . Чичестер: Wiley.
  14. ^ Ральф, Пол; Моханани, Рахул (май 2015 г.). «Является ли разработка требований по своей сути контрпродуктивной?». Труды 5-го международного семинара по двойному пику требований и архитектуры . Флоренция, Италия: IEEE. стр. 20–23.
  15. ^ Янссон, Д.; Смит, С. (1991). «Фиксация дизайна». Исследования дизайна . 12 (1): 3–11. doi :10.1016/0142-694X(91)90003-F.
  16. ^ Перселл, А.; Геро, Дж. (1996). «Дизайн и другие типы фиксации». Design Studies . 17 (4): 363–383. doi :10.1016/S0142-694X(96)00023-3.
  17. ^ Моханани, Рахул; Ральф, Пол; Шрив, Бен (май 2014 г.). «Фиксация требований». Труды Международной конференции по программной инженерии . Хайдарабад, Индия: IEEE. С. 895–906.
  18. ^ Ральф, Пол (2012). «Иллюзия требований в разработке программного обеспечения». Требования к инженерии . 18 (3): 293–296. arXiv : 1304.0116 . doi : 10.1007/s00766-012-0161-4. S2CID  11499083.

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

Найдите требование в Викисловаре, бесплатном словаре.