Разработка требований - Requirements engineering

Разработка требований (RE)[1] это процесс определения, документирования и поддержки требования[2] в процесс инженерного проектирования. Это обычная роль в системная инженерия и программная инженерия.

Первое использование термина разработка требований был, вероятно, в 1964 году в документе конференции «Техническое обслуживание, ремонтопригодность и разработка системных требований»,[3] но он не стал широко использоваться до конца 1990-х годов, когда был опубликован IEEE Computer Society руководство[4] в марте 1997 г. и учреждение серии конференций по разработке требований, которая превратилась в Международная конференция по разработке требований.

в модель водопада,[5] инженерия требований представлена ​​как первая фаза процесса разработки. Более поздние методы разработки, включая рациональный унифицированный процесс (RUP) для программного обеспечения, предполагается, что разработка требований продолжается в течение всего срока службы системы.

Управление требованиями, которое является подфункцией практики системного проектирования, также индексируется в Международный совет по системной инженерии (INCOSE) руководства.

Деятельность

Действия, связанные с разработкой требований, широко варьируются в зависимости от типа разрабатываемой системы и конкретных практик организации.[6] Они могут включать:

  1. Создание требований или же выявление требований - Встреча разработчиков и заинтересованных сторон; последних спрашивают об их потребностях и пожеланиях относительно программного продукта.
  2. Анализ требований и переговоры - Выявляются требования (включая новые, если разработка является итеративной), и разрешаются конфликты с заинтересованными сторонами. Как письменные, так и графические инструменты (последние обычно используются на этапе проектирования, но некоторые находят их полезными и на этом этапе) успешно используются в качестве вспомогательных средств. Примеры письменных инструментов анализа: сценарии использования и пользовательские истории. Примеры графических инструментов: UML[7] и LML.
  3. Системное моделирование - Некоторые инженерные области (или конкретные ситуации) требуют, чтобы продукт был полностью спроектирован и смоделирован до того, как начнется его строительство или изготовление. Поэтому этап проектирования нужно выполнять заранее. Например, до утверждения и подписания контракта необходимо разработать чертежи здания. Многие поля могут создавать модели системы с Язык моделирования жизненного цикла, тогда как другие могут использовать UML. Примечание. Во многих областях, таких как разработка программного обеспечения, большинство действий по моделированию классифицируются как действия по проектированию, а не как действия по разработке требований.
  4. Спецификация требований - требования документируются в формальном артефакте, называемом Спецификацией требований (RS), который станет официальным только после проверки. При необходимости РС может содержать как письменную, так и графическую (модели) информацию. Пример: Спецификация требований к программному обеспечению (SRS).
  5. Проверка требований - проверка того, что задокументированные требования и модели согласованы и соответствуют потребностям заинтересованных сторон. Только если окончательный проект проходит процесс проверки, RS становится официальным.
  6. Управление требованиями - Управление всеми действиями, связанными с требованиями, с момента создания, надзор по мере разработки системы и даже до ее ввода в эксплуатацию (например, изменения, расширения и т. Д.)

Иногда они представлены в виде хронологических этапов, хотя на практике эти действия в значительной степени чередуются.

Было показано, что разработка требований вносит свой вклад в успех программных проектов. [8]

Проблемы

Одно ограниченное исследование, проведенное в Германии, представило возможные проблемы при внедрении инженерии требований и спросило респондентов, согласны ли они с тем, что это действительно проблемы. Результаты не были представлены как обобщаемые, но предполагали, что основными воспринимаемыми проблемами были неполные требования, движущиеся цели и временные рамки, а меньшими проблемами были недостатки связи, отсутствие прослеживаемости, терминологические проблемы и нечеткие обязанности.[9]

Критика

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

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

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

  1. ^ Nuseibeh, B .; Истербрук, С. (2000). Разработка требований: дорожная карта (PDF). ICSE '00. Материалы конференции о будущем программной инженерии.. С. 35–46. CiteSeerX  10.1.1.131.3116. Дои:10.1145/336512.336523. ISBN  1-58113-253-0.
  2. ^
  3. ^ Дреснер, К. Х. Борхерс (1964). Техническое обслуживание, ремонтопригодность и разработка системных требований. Всемирный конгресс и выставка SAE 1964. Технический документ SAE 640591. Дои:10.4271/640591.
  4. ^ Тайер, Ричард Х .; Дорфман, Мерлин, ред. (Март 1997 г.). Разработка требований к программному обеспечению (2-е изд.). Пресса IEEE Computer Society. ISBN  978-0-8186-7738-0.
  5. ^ Ройс, У. (1970). Управление разработкой больших программных систем: концепции и методы (PDF). ICSE '87. Материалы 9-й международной конференции по программной инженерии. С. 1–9.
  6. ^ Соммервилл, Ян (2009). Программная инженерия (9-е изд.). Эддисон-Уэсли. ISBN  978-0-13-703515-1.
  7. ^ «Выявление требований с помощью диаграмм классов UML, часть 1». tynerblain.com. 7 марта 2008 г.. Получено 14 марта, 2018.
  8. ^ Hofmann, H.F .; Ленер, Ф. (2001). «Разработка требований как фактор успеха в программных проектах». Программное обеспечение IEEE. 18 (4): 58–66. Дои:10.1109 / MS.2001.936219. ISSN  0740-7459.
  9. ^ Мендес Фернандес, Даниэль; Вагнер, Стефан (2015). «Назвать боль в разработке требований: проект для глобального семейства опросов и первые результаты из Германии». Информационные и программные технологии. 57: 616–643. arXiv:1611.04976. Дои:10.1016 / j.infsof.2014.05.008. S2CID  1924926.
  10. ^ Ральф, Пол; Моханани, Рахул (май 2015 г.). «Является ли разработка требований контрпродуктивной по своей сути?». IEEE. Дои:10.13140/2.1.3831.6321. Цитировать журнал требует | журнал = (помощь)
  11. ^ Ральф, П. (сентябрь 2013 г.). «Иллюзия требований при разработке программного обеспечения». Разработка требований. 18 (3): 293–296. arXiv:1304.0116. Bibcode:2013arXiv1304.0116R. Дои:10.1007 / s00766-012-0161-4. S2CID  11499083.

внешняя ссылка