Jump to content

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

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

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

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

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

Деятельность [ править ]

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

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

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

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

Проблемы [ править ]

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

Критика [ править ]

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

См. также [ править ]

Ссылки [ править ]

  1. ^ Нусейбе, Б.; Истербрук, С. (2000). Разработка требований: дорожная карта (PDF) . ММВБ '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 . ISBN  978-0-8186-7738-0 .
  5. ^ Ройс, WW (1970). Управление разработкой больших программных систем: концепции и методы (PDF) . МЦБИ '87. Материалы 9-й международной конференции по программной инженерии . стр. 1–9.
  6. ^ Соммервилл, Ян (2009). Программная инженерия (9-е изд.). Аддисон-Уэсли . ISBN  978-0-13-703515-1 .
  7. ^ «Раскрытие требований с помощью диаграмм классов UML, часть 1» . tynerblain.com . 7 марта 2008 года . Проверено 14 марта 2018 г.
  8. ^ Хофманн, ХФ; Ленер, Ф. (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 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  11. ^ Ральф, П. (сентябрь 2013 г.). «Иллюзия требований при разработке программного обеспечения». Инженерия требований . 18 (3): 293–296. arXiv : 1304.0116 . Бибкод : 2013AIPC.1516..293R . дои : 10.1007/s00766-012-0161-4 . S2CID   11499083 .

Внешние ссылки [ править ]

Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 79370c3b91580872d1265ae2353d61e9__1690260420
URL1:https://arc.ask3.ru/arc/aa/79/e9/79370c3b91580872d1265ae2353d61e9.html
Заголовок, (Title) документа по адресу, URL1:
Requirements engineering - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)