Решения Visure


Поддержка
Зарегистрируйтесь
Логин
Начните бесплатную пробную версию

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

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

Содержание

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

Что такое требования и разработка требований?

Здесь есть два термина: «Требование» и «Разработка требований». Требование точно определяется как условие или возможность, которые необходимы пользователю для решения проблемы или достижения цели. Другими словами, требования — это условия или возможности, которым должна соответствовать система, чтобы соответствовать контракту, стандартам, спецификациям и другой официальной документации. 

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

В целом, разработка требований — это набор действий, связанных с определением и сообщением цели системы или программного обеспечения и контекста, в котором они будут использоваться. 

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

Каковы принципы разработки требований?

Два основных принципа разработки требований — это проблема и решение разработки требований. 

  • При сборе требований полезно разделять проблему и решение.
  • Это разделение никогда не может быть полностью достигнуто в практической жизни.

Разработка требований заключается в построении правильной системы. По сути, речь идет о построении системы, которая соответствует проблемам пользователя. Это проблемно-ориентированная часть. В основном речь идет о разработке, проверке, внедрении и обслуживании системы, созданной для обеспечения того, чтобы она соответствовала проблемам пользователя. Это часть, ориентированная на решение.

Процесс разработки требований

Есть несколько действий, с которыми мы сталкиваемся при работе с требованиями. В цикле разработки требований есть пять основных видов деятельности, а именно:

  1. Выявление требований – это процесс рассмотрения, документирования и понимания потребностей и ограничений заинтересованных сторон и пользователей в течение сезона. Пользователям нужна информация о домене, информация о существующей системе, правила, стандарты и т. д. На основе этой информации мы выявляем требования. После этого мы переходим к анализу требований и согласованию. 
  2. Анализ требований и переговоры – анализ – это процесс уточнения потребностей и ограничений пользователя на основе собранной и полученной информации. Затем мы переходим к работе с документацией. 
  3. Требования Документация/спецификация – после получения технического задания переходим к части документации. Мы четко и точно документируем потребности и ограничения пользователей. 
  4. Проверка требований – наконец, в процессе проверки мы указываем, что сезонные требования полны, кратки и ясны. 
  5. Управление требованиями – Управление требованиями – это способ сбора, анализа, уточнения и приоритизации всех продуктов или требований на этапе разработки.

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

Выявление требований

Как мы обсуждали ранее, выявление требований — это процесс анализа, документирования и понимания потребностей и ограничений пользователей на текущий сезон. Пользователям нужна информация о домене, информация о существующей системе, правила, стандарты и т. д. На основе этой информации мы выявляем требования. Мы используем слово «выявление» вместо «сбор», потому что сбор интерпретируется как просто сбор требований и помещение их в документ. С другой стороны, выведение — более сложный процесс. Вы не получаете требования так легко, как во время сбора. Это требует дополнительных усилий. 

Во время опроса вы спрашиваете пользователя или покупателя:

  • Каковы их цели для системы/продукта? 
  • Что должно быть выполнено?
  • Как сезонные потребности вписываются в потребности бизнеса?
  • Как использовать сезонный продукт/систему на регулярной основе?

Звучит просто, но это совсем не так!

По словам Яна Соммервилля и Пита Сойера, выявление требований — это процесс выявления требований к системе путем общения с клиентами, пользователями системы и другими лицами, заинтересованными в разработке системы. Поскольку «сбор» или «захват» звучит не очень точно, мы используем слово «выявление». 

«Я знаю, что вы считаете, что поняли то, что, по вашему мнению, я сказал, но я не уверен, что вы понимаете, что то, что вы услышали, не то, что я имел в виду», — Роберт Макклоски, официальный представитель Госдепартамента.

Под своей цитатой он имел в виду, что иногда люди неправильно понимают, что им говорят другие. Иногда то, что они говорят, не то, что они имеют в виду. В конце концов, все это недопонимание привело к неправильному сбору требований.

Каковы шаги во время выявления?

ШАГ 1 

Источник требований:

Существуют различные источники, из которых мы можем собирать наши требования. Некоторые из них включают:

  • Заинтересованные стороны
  • Существующие системы
  • Существующие документы
  • Конкуренты и другие подобные системы
  • Интерфейсы с системами
  • Законы и стандарты
  • Политика компаний

ШАГ 2

Установите объем проекта:

Следующие шаги могут быть выполнены для того, чтобы настроить масштаб проекта:

  1. Узнайте, почему проект инициирован 
  2. Свойство определяет ключевые цели, которые должны быть достигнуты в рамках проекта. 
  3. Составьте техническое задание для проекта, которое поможет вам правильно распределить работу между членами команды.
  4. Перечислите элементы, которые должны быть доставлены в конце проекта.
  5. Выберите ключевые вехи, которые должны быть достигнуты
  6. Определите основные препятствия и ограничения, с которыми команда может столкнуться во время разработки проекта.
  7.  Создайте список элементов, которые исключены из списка элементов области действия.
  8. Попросите заинтересованные стороны подписать документ о содержании, поскольку он обеспечивает подтверждение того, что они проинформированы о проекте и его содержании. 

ШАГ 3

Выявительные задачи:

Планирование выявления:

  • Почему это конкретное требование должно быть реализовано и преимущества, которые оно даст? – Цели проекта 
  • Кто будет отвечать за его создание? – Профессионалы по привлечению внимания
  • Когда будет лучшее время для его реализации? - Запланировать смету источников 
  • Как это будет реализовано? – Стратегии и процедуры
  • И риски 

Во время выяснения:

  • Подтвердить жизнеспособность проекта. Узнайте, действительно ли проект того стоит или нет
  • Понимание проблем и вопросов с точки зрения заинтересованной стороны
  • Извлечь суть требований, заявленных заинтересованными сторонами
  • Узнайте, как лучше выполнять работу для пользователей
  • Инновации – ключ к победе

После выяснения:

  • Проанализируйте результаты, чтобы правильно понять собранную информацию
  • Обсудите согласованный набор требований, приемлемых для заинтересованных сторон. Также расставьте приоритеты
  • Зафиксировать результаты в спецификациях требований

Выявление — это постепенный процесс. Вы должны повторять этот шаг столько раз, сколько требуется. 

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

ШАГ 4

Документация требований – 

Последним шагом в процессе выявления является завершение всех требований в виде документа. Этот документ в основном содержит примечания и требования пользователя. И эти требования будут неполными, непоследовательными и неорганизованными. Но это только отправная точка. Документ можно время от времени редактировать, что-то добавлять или изменять.

Анализ требований и переговоры

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

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

Следует иметь в виду, что выявление требований и анализ требований работают вместе. Они двое кормят друг друга. Когда мы начинаем собирать требования, мы одновременно их выявляем и анализируем.

Цели анализа требований

  1. Первая и главная цель анализа требований — понять требования и нужды пользователей. 
  2. Когда мы используем разные источники для сбора требований, между ними могут возникнуть некоторые конфликты. Анализ требований заключается в поиске этих конфликтов между требованиями, заявленными пользователями, и их разрешении. 
  3. Обсудите требования с пользователями и заинтересованными сторонами. Наша система никак не может удовлетворить все требования именно так, как они объясняются заинтересованными сторонами и пользователями. 
  4. Нам придется вести переговоры и расставлять приоритеты в требованиях. Некоторые требования могут быть незначительными для нас, но они могут быть очень важны для конечных пользователей. Чтобы понять их, мы должны проанализировать и расставить приоритеты требований заинтересованных сторон. 
  5. Мы должны уточнить требования, заявленные пользователями и системой. Это помогает при документировании требований в спецификациях требований. Кроме того, это помогает разработчикам лучше разрабатывать, проектировать и тестировать, поскольку они лучше понимают требования. 
  6. Мы должны классифицировать требования по различным категориям и подкатегориям, а затем распределять эти требования по разным подсистемам. 
  7. Мы также должны оценить требования к качеству, которое желательно для организации. 
  8. Наконец, мы должны убедиться, что не пропустите ничего важного.

Требования Документация/спецификация

Спецификация требований, также известная как документация, представляет собой процесс записи всех системных и пользовательских требований в форме документа. Эти требования должны быть четкими, полными, всеобъемлющими и последовательными. 

В процессе захвата мы собираем все требования из разных источников. В ходе анализа и переговоров мы анализируем и понимаем эти требования. Теперь мы должны подготовить официальный документ, объясняющий эти требования. Вот что такое техническое задание. Если быть точным, это процесс четкого и точного документирования всех потребностей и ограничений пользователя и системы. 

Метод документирования требований

УШИ будет эффективной методологией здесь. Это означает Простой подход к синтаксису требований. В этом методе мы пишем четким, лаконичным и понятным языком. Это улучшает весь рабочий процесс разработки требований и упрощает работу, делая вещи довольно простыми для понимания. 

Чтобы достичь этого, вот несколько принципов, которые необходимо учитывать при написании требований. Они включают:

Каждое требование должно быть в форме полного предложения. Не следует использовать маркеры, аббревиатуры, аббревиатуры или модные словечки. Старайтесь составлять короткие, прямые и полные предложения. 

Убедитесь, что в каждом требовании есть правильное подлежащее, сказуемое и глагол. Субъектом будет тип пользователя или система, о которой мы говорим. Предикатом могут быть условия, действия или желаемые результаты, которые мы ожидаем. Мы должны использовать такие слова, как «должен», «будет» и «должен», чтобы выразить некоторую необходимость, и такие слова, как «может», чтобы выразить необязательность в требовании. 

Каждое требование должно эффективно объяснять конечный результат, который мы ожидаем от системы. 

Кроме того, требование должно описывать качество, которое мы ожидаем от системы. Это помогает, когда мы измеряем конечный результат и видим, правильно ли реализовано требование или нет.

Проверка требований

Валидация — это процесс, используемый для проверки того, соответствует ли система требованиям или нет. Валидация отвечает на вопрос: «Разрабатываем ли мы правильную систему?» Речь идет о тестировании и проверке системы, а также о том, является ли система, которую мы построили, правильной или нет, и соответствует ли она ожиданиям клиента или нет. Различные методы, которые используются для проверки системы, включают тестирование черного ящика, тестирование белого ящика, интеграционное тестирование и модульное тестирование. Валидация всегда приходит после верификации. 

Верификация — это процесс, используемый для проверки того, достигает ли система ожидаемых целей или нет без каких-либо ошибок или проблем. Верификация отвечает на вопрос: «Правильно ли мы создаем продукт?» Речь идет о тестировании и проверке того, соответствует ли система требованиям без каких-либо проблем. Различные методы, которые используются для проверки системы, включают обзоры, обходы, инспекции и кабинетные проверки. Проверка — это ручной процесс, выполняемый перед проверкой.

Методы проверки

Существуют различные методы, которые можно использовать для проверки требований. Они включают:

  • Проверки – Во время проверки требований мы корректируем документы с требованиями, чтобы убедиться, что ни одно уточнение не пропущено. Во время этих проверок мы также проверяем уровень прослеживаемости между всеми требованиями. Для этого требуется создание матрицы прослеживаемости. Эта матрица гарантирует, что все требования рассматриваются серьезно и все, что указано, оправдано. Мы также проверяем формат требований во время этих проверок. Мы смотрим, ясны и хорошо написаны требования или нет. 
  • Макетирования – Это способ построения модели или симуляции системы, которую предстоит построить разработчикам. Это очень популярный метод проверки требований среди заинтересованных сторон и пользователей, поскольку он помогает им легко выявлять проблемы. Мы можем просто связаться с пользователями и заинтересованными сторонами и получить их отзывы. 
  • Дизайн теста — При разработке тестов мы следуем небольшой процедуре, в которой сначала дорабатываем команду тестирования, а затем создаем несколько сценариев тестирования. Функциональные тесты могут быть получены из самой спецификации требований, где каждое требование имеет связанный с ним тест. Напротив, нефункциональные требования трудно тестировать, поскольку каждый тест должен быть отслежен до его требования. Целью этого является выявление ошибок в спецификации или упущенных деталей. 
  • Обзор требований – Во время обзора требований группа знающих людей анализирует требования структурированным и подробным образом и выявляет потенциальные проблемы. После этого они собираются, чтобы обсудить проблемы и найти способ их решения. Готовится контрольный список, состоящий из различных стандартов, и рецензенты ставят галочки, чтобы провести формальную проверку. После этого происходит окончательное утверждение.

Управление требованиями

По словам Яна Соммервилля, «управление требованиями — это процесс управления изменяющимися требованиями в процессе разработки требований и разработки системы».

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

Основные проблемы управления требованиями

Есть некоторые опасения по поводу управления требованиями. Они включают:

  • Управление изменениями в согласованных требованиях
  • Управление взаимосвязью между всеми требованиями
  • Управление зависимостями между документами требований, которые создаются в процессе системного проектирования.

Типы требований

Обычно существует два типа требований:

  1. Системные требования — Системные требования можно назвать расширенной версией пользовательских требований. Системные требования служат отправной точкой для любого нового проектирования системы. Эти требования представляют собой подробное описание требований пользователя, которым должна удовлетворять система. 
  2. Требования пользователя – Пользовательское требование представляет собой комбинацию функциональных и нефункциональных требований. Эти пользовательские требования должны быть разработаны таким образом, чтобы они были легко понятны пользователям, не обладающим какими-либо техническими знаниями. Следовательно, они должны быть написаны на естественном языке с использованием простых таблиц, форм и диаграмм. Кроме того, убедитесь, что в документе нет сведений о конструкции системы, программном обеспечении или формальных обозначениях.

Платформа ALM для требований Visure

Платформа ALM для требований Visure — одна из самых надежных современных платформ ALM, специализирующаяся на управлении требованиями для организаций любого размера по всему миру. 

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

Visure Requirements — это проверенный гибкий и полный инструмент разработки требований, способный оптимизировать процесс разработки требований к программному обеспечению как часть процесса определения аппаратного и механического оборудования. Требования Visure способствуют эффективному сотрудничеству в проектах и ​​повышают качество программного обеспечения за счет сбора требований, анализа, спецификации, проверки и проверки, управления и повторного использования.

Решения Visure могут помочь преодолеть проблемы разработки продуктов и встроенных систем,

  • Повышение качества определения как важный первый шаг к повышению качества программного обеспечения
  • Восстановите контроль над процессами разработки и регулирования
  • Стандартизация и обеспечение соблюдения определения требований во всей организации
  • Поддержка эффективного повторного использования требований в проектных группах, а также в линейках продуктов и вариантах.
  • Формализовать общую структуру спецификации требований и обрабатывать изменения на протяжении всего жизненного цикла.
  • Достигать полная прослеживаемость через все элементы, от требований до тестирования и исполнения
  • С легкостью отслеживайте все аспекты разработки, от графиков расчета рисков до отчетов о необоснованных требованиях
  • Избегайте ловушек и снижайте риски на всех уровнях, от составления более качественных требований и определения приоритетов потребностей до изменения возможностей анализа воздействия.
Программные инструменты ALM

Преимущества использования требований Visure для разработки продуктов и встроенных решений

  • Сертификационная поддержка отраслевые стандарты, такие как DO-178B/C, IEC 61508, ISO 26262, IEC 62304, FMEA и GAMP5
  • Единая полная платформа для всех действий, связанных с требованиями
  • Применение процессов с помощью гибкого решения, поддерживающего различные модели процессов, включая Automotive SPICE, CMMI, V-модель, Agile и ad hoc.
  • Улучшенное командное взаимодействие и сотрудничество благодаря ролевым возможностям
  • Поддержка продуктов более высокого качества и снижение дефектов программного обеспечения.

Компании, которые активно используют Visure, заявляют о явном влиянии на своевременную реализацию проекта, соблюдение требований проекта и снижение затрат на разработку и времени цикла.

Заключение

Инжиниринг требований — критически важный процесс для обеспечения того, чтобы продукты и системы, которые мы создаем, соответствовали потребностям наших клиентов. Пятиэтапный процесс, описанный в этой статье, может помочь вам успешно начать проект, получая отзывы от заинтересованных сторон на раннем этапе и часто и используя эти отзывы для создания четких и кратких требований. Если вы ищете инструмент, который поможет вам управлять процессом разработки требований, вам может помочь платформа Visure Requirements ALM. Запросить Бесплатная пробная версия 30 сегодня, чтобы увидеть, как наша платформа может сделать ваш следующий проект успешным.

Не забудьте поделиться этим постом!

Топовое