Разработка требований
Эта статья содержит подробный перефраз несвободных источников, защищенных авторским правом . ( сентябрь 2020 г. ) |
Разработка требований ( RE ) [1] это процесс определения, документирования и поддержания требований [2] в процессе инженерного проектирования . Это обычная роль в системной инженерии и разработке программного обеспечения .
Впервые термин «инженерия требований» был использован, вероятно, в 1964 году в докладе на конференции «Техническое обслуживание, ремонтопригодность и разработка системных требований». [3] но он не получил широкого распространения до конца 1990-х годов, когда был опубликован IEEE Computer Society. учебник [4] в марте 1997 года и учреждение серии конференций по разработке требований, которая превратилась в Международную конференцию по разработке требований .
В водопада модели [5] Разработка требований представлена как первый этап процесса разработки. Более поздние методы разработки, включая Rational Unified Process (RUP) для программного обеспечения, предполагают, что разработка требований продолжается на протяжении всего срока службы системы.
Управление требованиями , которое является подфункцией практики системной инженерии, также включено в руководства Международного совета по системной инженерии (INCOSE).
Деятельность [ править ]
Действия, связанные с разработкой требований, широко варьируются в зависимости от типа разрабатываемой системы и конкретной практики организации. [6] Они могут включать в себя:
- Разработка требований или выявление требований – встречаются разработчики и заинтересованные стороны; последних спрашивают об их потребностях и желаниях относительно программного продукта.
- Анализ и обсуждение требований. Выявляются требования (в том числе новые, если разработка итеративная), а конфликты с заинтересованными сторонами решаются. В качестве вспомогательных средств успешно используются как письменные, так и графические инструменты (последние обычно используются на этапе проектирования, но некоторые считают их полезными и на этом этапе). Примеры письменных инструментов анализа: варианты использования и пользовательские истории . Примеры графических инструментов: UML. [7] и ЛМЛ .
- Системное моделирование . Некоторые области техники (или конкретные ситуации) требуют, чтобы продукт был полностью спроектирован и смоделирован до начала его проектирования или изготовления. Поэтому этап проектирования должен быть выполнен заранее. Например, перед утверждением и подписанием любого контракта необходимо разработать чертежи здания. Многие поля могут создавать модели системы с помощью языка моделирования жизненного цикла , тогда как другие могут использовать UML . Примечание. Во многих областях, таких как разработка программного обеспечения, большая часть деятельности по моделированию классифицируется как деятельность по проектированию, а не как деятельность по разработке требований.
- Спецификация требований . Требования документируются в формальном документе, называемом Спецификацией требований (RS), который станет официальным только после проверки. При необходимости ТЗ может содержать как письменную, так и графическую (модели) информацию. Пример: Спецификация требований к программному обеспечению (SRS).
- Проверка требований — проверка того, что документированные требования и модели последовательны и соответствуют потребностям заинтересованных сторон. Только если окончательный проект пройдет процедуру проверки, РС станет официальным.
- Управление требованиями — управление всеми действиями, связанными с требованиями, с момента создания, контроль за разработкой системы и даже до ее ввода в эксплуатацию (например, изменения, расширения и т. д.).
Иногда их представляют в виде хронологических этапов, хотя на практике эти виды деятельности значительно чередуются.
Было показано, что разработка требований явно способствует успеху программного проекта. [8]
Проблемы [ править ]
Одно ограниченное исследование, проведенное в Германии, представило возможные проблемы при реализации проектирования требований и спросило респондентов, согласны ли они с тем, что это реальные проблемы. Результаты не были представлены как поддающиеся обобщению, но предполагали, что основными воспринимаемыми проблемами были неполные требования, движущиеся цели и ограничения по времени, а меньшими проблемами были недостатки связи, отсутствие прослеживаемости, терминологические проблемы и неясные обязанности. [9]
Критика [ править ]
Было высказано предположение, что структурирование проблем, ключевой аспект разработки требований, снижает производительность проектирования. [10] Некоторые исследования показывают, что возможно, что если в процессе разработки требований есть недостатки, приводящие к ситуации, когда требования не существуют, требования к программному обеспечению могут быть созданы независимо от того, как иллюзия, искажающая проектные решения как требования. [11]
См. также [ править ]
- Список инструментов разработки требований
- Анализ требований , разработка требований, ориентированная на разработку программного обеспечения.
- Группа специалистов по разработке требований (RESG)
- Совет по разработке международных требований (IREB)
- Международный совет по системной инженерии (INCOSE)
- IEEE 12207 «Системная и программная инженерия. Процессы жизненного цикла программного обеспечения»
- ТОГАФ (Глава 17)
- Концепция операций (ConOps)
- Операционное управление
- Требования к программному обеспечению
- Спецификация требований к программному обеспечению
- Свод знаний по программной инженерии (SWEBOK)
- Спецификация дизайна
- Спецификация (технический стандарт)
- Формальная спецификация
- Качество программного обеспечения
- Управление качеством
- Управление объемом
Ссылки [ править ]
- ^ Нусейбе, Б.; Истербрук, С. (2000). Разработка требований: дорожная карта (PDF) . ММВБ '00. Материалы конференции о будущем программной инженерии . стр. 35–46. CiteSeerX 10.1.1.131.3116 . дои : 10.1145/336512.336523 . ISBN 1-58113-253-0 .
- ^
- Котоня, Джеральд; Соммервилл, Ян (сентябрь 1998 г.). Разработка требований: процессы и методы . Джон Уайли и сыновья . ISBN 978-0-471-97208-2 .
- Чемутури, М. (2013). Разработка требований и управление проектами разработки программного обеспечения . дои : 10.1007/978-1-4614-5377-2 . ISBN 978-1-4614-5376-5 . S2CID 19818654 .
- ^ Дрезнер, К. Х. Борхерс (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 . дои : 10.1016/j.infsof.2014.05.008 . S2CID 1924926 .
- ^ Ральф, Пол; Моханани, Рахул (май 2015 г.). «Является ли разработка требований по своей сути контрпродуктивной?» . IEEE. дои : 10.13140/2.1.3831.6321 .
{{cite journal}}
: Для цитирования журнала требуется|journal=
( помощь ) - ^ Ральф, П. (сентябрь 2013 г.). «Иллюзия требований при разработке программного обеспечения». Инженерия требований . 18 (3): 293–296. arXiv : 1304.0116 . Бибкод : 2013AIPC.1516..293R . дои : 10.1007/s00766-012-0161-4 . S2CID 11499083 .
Внешние ссылки [ править ]
- Системная и программная инженерия -- Процессы жизненного цикла -- Разработка требований . 2011. стр. 1–94. дои : 10.1109/IEESTD.2011.6146379 . ISBN 978-0-7381-6591-2 .
{{cite book}}
:|journal=
игнорируется ( help ) («Этот стандарт заменяет IEEE 830–1998, IEEE 1233–1998, IEEE 1362-1998 — http://standards.ieee.org/findstds/standard/29148-2011.html ») - Свод знаний по системной инженерии
- Справочник по управлению разработкой требований от FAA
- Совет по разработке международных требований (IREB)
- Библиотека ресурсов IBM Rational от IEEE Spectrum