В современной промышленности у компаний существует несколько проблем: успевать за стремительными технологическими изменениями, время выхода на рынок и др. Еще одной серьезной проблемой для компаний является поиск качественных и экономически эффективных решений с соответствующим балансом. Одним из последствий этих проблем является то, что компании больше не предлагают своим клиентам продукцию, а скорее комплексные решения. Эти решения является интегрированной системой, состоящие из комбинации различных подсистем или отдельных элементов.
Например, программного обеспечения, услуг и продуктов, элементы которых были разработаны для интеграции и оптимизации с учетом потребительской ценности.
Вместо того, чтобы продавать только отдельные продукты, эти решения обеспечивают функции, обслуживание и производительность. Разработка такого рода решений создает сложность требований в отношении нескольких различных аспектов и субъектов, которые необходимо учитывать.
Интеграция и сотрудничество с соответствующими субъектами рассматривается как важный аспект создания успешного предложения. С другой стороны, понимание основных потребностей является ключом к успешному системному проектированию. Поэтому крайне важно иметь подходящий процесс определения требований, который мог бы охватить все потребности соответствующих субъектов и связанные с ними требования.
Проблема здесь заключается в процессе интеграции перспективы различных областей в общее представление. Для обеспечения последовательности и прослеживаемости в выявлении и управлении требованиями неизбежно возникает постоянное взаимодействие между проектированием требований и разрабатываемыми элементами.
Компании работают внутри с требованиями, которые распространяются на специфические инженерные области и отделы, с точки зрения инженеров и их руководителей.
Теоретические рамочные требования к проектированию определены в ISO/IEC/IEEE 24765, и выступают, как наука и дисциплина, связанная с анализом и документированием требований. Исследователи предлагают разделить разработку требований на две части:
- разработку;
- управление .
Разработка требований включает в себя деятельность по созданию основы для того, какие функции должно выполнять планируемое предложение, например, получение информации и документация.
Управление требованиями, с другой стороны, подразумевает мероприятия по поддержанию требований на других этапах проектирования предложения, например, управление изменениями и проверка выполнения требований.
Разработка требований - шаг в процессе проектирования продукта, в то время как управление требованиями - это непрерывная деятельность, которая продолжается на последующих этапах процесса проектирования продукта. Существует множество различных процессов, связанных с требованиями, и что эти процессы плохо переносятся между организациями.
Выявление потребностей - это ранняя деятельность в процессе разработки требований, которая в основном заключается в приобретении знаний. Первым шагом для эффективного приобретения знаний является определение правильных действующих лиц.
Требования инжиниринга - это больше, чем просто понимание пользователя, понимание ограничений и последствий домена также важно.
Анализ требований должен быть проведен сразу же после сбора первоначальных требований. При анализе следует учитывать конфликты, совпадения, упущения и несоответствия. Важной частью анализа потребностей является также решение о том, какие из возможных требований будут включены в спецификацию. Если делается вывод, что не все требования могут быть выполнены, то должны быть критерии, оценивающие, какие требования должны быть приоритетными.
Сложная система будет иметь много участников, и у этих участников в определенный момент возникнут разногласия относительно системных требований, и они будут расставлять приоритеты в зависимости от их формирования. Это означает, что переговоры о требованиях всегда будут необходимы. Конфликты потребностей и дублирование функций решаются путем обмена информацией, обсуждения и разрешения разногласий.
Документация по требованиям желательна, так как количество требований может быть много.
Более мелкий проект может быть задокументирован в простом текстовом редакторе, а для более сложных наборов требований необходимы различные программные решения.
Документация по требованиям должна описывать:
- какие услуги и функции должна обеспечивать система,
- эксплуатационные ограничения системы,
- общие свойства системы,
- определения систем, с которыми система будет интегрироваться,
- область применения системы,
- ограничения на процесс разработки системы.
Валидация требований является завершающим видом деятельности по разработке требований.
Цель валидации состоит в том, чтобы контролировать требования, удостоверится, что они представляют собой нужную систему.
Валидация направлена на то, чтобы убедиться, что развиваются правильные направления. Она включает в себя несколько различных участников, включая, например, инженеров по требованиям и разработчиков систем. А для проверки достоверности требуется непосредственное участие субъектов для пересмотра этого требования.
Управление изменениями касается необходимости изменений вовремя и после процесса разработки требований. Если процесс хорошо структурирован и рассчитан на модификацию, изменения обычно могут вноситься на местном уровне.
Прослеживаемость способствует простоте локализации изменений, которые необходимо внести.
Проверка требований является важным шагом и уже при определении требований, зная, как продукт должен быть протестирован, чтобы проверить соответствие каждому определенному требованию. Система должна быть протестирована на соответствие требованиям различными способами в зависимости от характеристик системы.
Документация может помочь увязать требования с результатами испытаний и результатами испытаний, позволяя установить связь между результатами испытаний и выполнением требований. Однако может возникнуть сомнительной действительности такого типа связи в случае внесения изменений в требования.
