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

редактировать

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

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

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

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

СОДЕРЖАНИЕ
  • 1 Мероприятия
  • 2 проблемы
  • 3 Критика
  • 4 См. Также
  • 5 ссылки
  • 6 Внешние ссылки
Деятельность

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

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

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

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

Проблемы

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

Критика

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

Смотрите также
Рекомендации
внешняя ссылка
Последняя правка сделана 2023-03-29 07:25:09
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте