Определение и поддержание требований в системной инженерии
Инженерия требований ( RE ) [1] — это процесс определения, документирования и поддержания требований [2] в процессе инженерного проектирования . Это обычная роль в системной инженерии и разработке программного обеспечения .
Впервые термин « инженерия требований» был использован, вероятно, в 1964 году в докладе на конференции «Обслуживание, ремонтопригодность и системные требования» [3] , но он не вошёл в общее употребление до конца 1990-х годов, когда была опубликована публикация IEEE Computer Society. учебник [4] в марте 1997 года и создание серии конференций по разработке требований, которая превратилась в Международную конференцию по разработке требований .
В водопадной модели [5] разработка требований представлена как первая фаза процесса разработки. Более поздние методы разработки, включая Rational Unified Process (RUP) для программного обеспечения, предполагают, что разработка требований продолжается на протяжении всего срока службы системы.
Управление требованиями , которое является подфункцией практики системной инженерии, также включено в руководства Международного совета по системной инженерии (INCOSE).
Деятельность
Действия, связанные с разработкой требований, широко варьируются в зависимости от типа разрабатываемой системы и конкретной практики организации. [6] К ним могут относиться:
- Разработка требований или выявление требований – встречаются разработчики и заинтересованные стороны; последних спрашивают об их потребностях и желаниях относительно программного продукта.
- Анализ и обсуждение требований. Выявляются требования (в том числе новые, если разработка итеративная), а конфликты с заинтересованными сторонами решаются. В качестве вспомогательных средств успешно используются как письменные, так и графические инструменты (последние обычно используются на этапе проектирования, но некоторые считают их полезными и на этом этапе). Примеры письменных инструментов анализа: варианты использования и пользовательские истории . Примеры графических инструментов: UML [7] и LML .
- Системное моделирование . Некоторые области техники (или конкретные ситуации) требуют, чтобы продукт был полностью спроектирован и смоделирован до начала его строительства или производства. Поэтому этап проектирования должен быть выполнен заранее. Например, перед утверждением и подписанием любого контракта необходимо разработать чертежи здания. Многие поля могут создавать модели системы с помощью языка моделирования жизненного цикла , тогда как другие могут использовать UML . Примечание. Во многих областях, таких как разработка программного обеспечения, большая часть деятельности по моделированию классифицируется как деятельность по проектированию, а не как деятельность по разработке требований.
- Спецификация требований . Требования документируются в формальном документе, называемом Спецификацией требований (RS), который станет официальным только после проверки. При необходимости ТЗ может содержать как письменную, так и графическую (модели) информацию. Пример: Спецификация требований к программному обеспечению (SRS).
- Проверка требований – проверка того, что документированные требования и модели последовательны и соответствуют потребностям заинтересованных сторон. Только если окончательный проект пройдет процедуру проверки, РС станет официальным.
- Управление требованиями – управление всеми действиями, связанными с требованиями, с момента создания, контроль за разработкой системы и даже до ее ввода в эксплуатацию (например, изменения, расширения и т. д.).
Иногда их представляют в виде хронологических этапов, хотя на практике эти виды деятельности значительно чередуются.
Было показано, что разработка требований явно способствует успеху программного проекта. [8]
Проблемы
В одном ограниченном исследовании, проведенном в Германии, были представлены возможные проблемы при реализации проектирования требований и задан вопрос, согласны ли они с тем, что это реальные проблемы. Результаты не были представлены как поддающиеся обобщению, но предполагали, что основными воспринимаемыми проблемами были неполные требования, движущиеся цели и ограничения по времени, а меньшими проблемами были недостатки коммуникации, отсутствие прослеживаемости, терминологические проблемы и неясные обязанности. [9]
Критика
Было высказано предположение, что структурирование проблем, ключевой аспект разработки требований, снижает производительность проектирования. [10] Некоторые исследования показывают, что возможно, что если в процессе разработки требований есть недостатки, приводящие к ситуации, когда требования не существуют, требования к программному обеспечению могут быть созданы независимо от того, как иллюзия, искажающая проектные решения как требования [11]
Смотрите также
Рекомендации
- ^ Нусейбе, Б.; Истербрук, С. (2000). Разработка требований: дорожная карта (PDF) . ММВБ '00. Материалы конференции о будущем программной инженерии . стр. 35–46. CiteSeerX 10.1.1.131.3116 . дои : 10.1145/336512.336523. ISBN 1-58113-253-0.
- ^
- ^ Дрезнер, К. Х. Борхерс (1964). Разработка технического обслуживания, ремонтопригодности и системных требований . Всемирный конгресс и выставка SAE , 1964 г. Технический документ SAE 640591 . дои : 10.4271/640591.
- ^ Тайер, Ричард Х.; Дорфман, Мерлин, ред. (март 1997 г.). Разработка требований к программному обеспечению (2-е изд.). Издательство Компьютерного общества IEEE . ISBN 978-0-8186-7738-0.
- ^ Ройс, WW (1970). Управление разработкой больших программных систем: концепции и методы (PDF) . МЦБИ '87. Материалы 9-й международной конференции по программной инженерии . стр. 1–9.
- ^ Соммервилл, Ян (2009). Программная инженерия (9-е изд.). Аддисон-Уэсли . ISBN 978-0-13-703515-1.
- ^ «Раскрытие требований с помощью диаграмм классов UML, часть 1» . tynerblain.com . 7 марта 2008 года . Проверено 14 марта 2018 г.
- ^ Хофманн, ХФ; Ленер, Ф. (2001). «Инженерия требований как фактор успеха в программных проектах». Программное обеспечение IEEE . 18 (4): 58–66. дои : 10.1109/MS.2001.936219. ISSN 0740-7459.
- ^ Мендес Фернандес, Даниэль; Вагнер, Стефан (2015). «Именуя боль в разработке требований: дизайн глобальной серии опросов и первые результаты из Германии». Информационные и программные технологии . 57 : 616–643. arXiv : 1611.04976 . doi :10.1016/j.infsof.2014.05.008. S2CID 1924926.
- ^ Ральф, Пол; Моханани, Рахул (май 2015 г.). «Является ли разработка требований по своей сути контрпродуктивной?». IEEE. дои : 10.13140/2.1.3831.6321.
- ^ Ральф, П. (сентябрь 2013 г.). «Иллюзия требований при разработке программного обеспечения». Инженерия требований . 18 (3): 293–296. arXiv : 1304.0116 . Бибкод : 2013AIPC.1516..293R. дои : 10.1007/s00766-012-0161-4. S2CID 11499083.
Внешние ссылки
- Системная и программная инженерия. Процессы жизненного цикла. Разработка требований. 2011. стр. 1–94. doi : 10.1109/IEESTD.2011.6146379. ISBN 978-0-7381-6591-2. («Этот стандарт заменяет IEEE 830–1998, IEEE 1233–1998, IEEE 1362-1998 — http://standards.ieee.org/findstds/standard/29148-2011.html»)
- Свод знаний по системной инженерии
- Справочник по управлению разработкой требований от FAA
- Совет по разработке международных требований (IREB)
- Библиотека ресурсов IBM Rational от IEEE Spectrum