Что представляет собой управление требованиями к программному обеспечению

Обновлено: 18.05.2024

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

Требование техники

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

Требование инженерного процесса

Это четырехэтапный процесс, который включает в себя:

  • Технико-экономическое обоснование
  • Сбор требований
  • Спецификация требований к программному обеспечению
  • Проверка требований к программному обеспечению

Давайте посмотрим на процесс вкратце —

Технико-экономическое обоснование

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

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

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

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

Сбор требований

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

Спецификация требований к программному обеспечению

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

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

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

SRS должен придумать следующие функции:

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

Проверка требований к программному обеспечению

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

  • Если они могут быть практически реализованы
  • Если они действительны и согласно функциональности и области программного обеспечения
  • Если есть какие-то неясности
  • Если они завершены
  • Если они могут быть продемонстрированы

Процесс выявления требований

Процесс выявления требований можно изобразить с помощью следующей диаграммы:

Процесс выявления требований

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

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

Требования исходят от различных заинтересованных сторон. Чтобы устранить двусмысленность и конфликты, они обсуждаются для ясности и правильности. Нереальные требования разумно скомпрометированы.

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

Требования исходят от различных заинтересованных сторон. Чтобы устранить двусмысленность и конфликты, они обсуждаются для ясности и правильности. Нереальные требования разумно скомпрометированы.

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

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

Существуют различные способы определения требований

Интервью

Интервью являются сильной средой для сбора требований. Организация может проводить несколько типов интервью, таких как:

Обзоры

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

Анкетирование

Документ с предварительно определенным набором объективных вопросов и соответствующими вариантами передается всем заинтересованным сторонам для ответа, которые собираются и компилируются.

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

Анализ задач

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

Анализ предметной области

Каждое программное обеспечение попадает в какую-то доменную категорию. Опытные люди в этой области могут оказать большую помощь в анализе общих и конкретных требований.

мозговая атака

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

макетирования

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

наблюдение

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

Требования к программному обеспечению Характеристики

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

Полные спецификации требований к программному обеспечению должны быть:

  • Очистить
  • Правильный
  • последовательный
  • Последовательный
  • понятный
  • модифицируемый
  • проверяемый
  • Приоритетное
  • недвусмысленный
  • прослеживаемый
  • Достоверный источник

Требования к программному обеспечению

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

В целом требования к программному обеспечению следует разделить на две категории:

Функциональные требования

Требования, относящиеся к функциональному аспекту программного обеспечения, попадают в эту категорию.

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

Примеры —

Нефункциональные требования

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

Нефункциональные требования включают в себя —

  • Безопасность
  • логирование
  • Место хранения
  • конфигурация
  • Спектакль
  • Стоимость
  • Interoperability
  • гибкость
  • Аварийное восстановление
  • доступность

Требования классифицированы логически как

  • Должно быть : программное обеспечение не может работать без них.
  • Должно иметь : Расширение функциональности программного обеспечения.
  • Может иметь : Программное обеспечение все еще может нормально функционировать с этими требованиями.
  • Список пожеланий : эти требования не соответствуют каким-либо целям программного обеспечения.

Требования к пользовательскому интерфейсу

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

  • прост в эксплуатации
  • быстрый ответ
  • эффективно обрабатывать ошибки в работе
  • обеспечение простого, но последовательного пользовательского интерфейса

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

  • Содержание презентации
  • Простая навигация
  • Простой интерфейс
  • отзывчивый
  • Согласованные элементы интерфейса
  • Механизм обратной связи
  • Настройки по умолчанию
  • Целенаправленный макет
  • Стратегическое использование цвета и текстуры.
  • Предоставить справочную информацию
  • Ориентированный на пользователя подход
  • Групповые настройки просмотра.

Программный системный аналитик

Системный аналитик в ИТ-организации — это человек, который анализирует требования к предлагаемой системе и обеспечивает правильное и правильное оформление и документирование требований. Роль аналитика начинается на этапе анализа программного обеспечения SDLC. Аналитик обязан убедиться, что разработанное программное обеспечение соответствует требованиям клиента.

Системные аналитики имеют следующие обязанности:

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

Метрики и показатели программного обеспечения

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

Метрики программного обеспечения обеспечивают измерения для различных аспектов программного процесса и программного продукта.

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

Давайте посмотрим некоторые метрики программного обеспечения:

Размер метрики — LOC (Lines of Code), в основном рассчитывается в тысячах доставленных строк исходного кода и обозначается как KLOC.

Функция Point Count — это мера функциональности, предоставляемой программным обеспечением. Функция Point count определяет размер функционального аспекта программного обеспечения.

Метрики качества — Дефекты, их типы и причины, последствия, интенсивность и их значение определяют качество продукта.

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

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

Условие или возможность, которым должна соответствовать система.

С формальной точки зрения управление требованиями - это систематический подход к следующим процессам:

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

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

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

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

Анализ сложностей

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

Понимание потребностей заинтересованных лиц

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

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

Определение системы

Определением системы называется преобразование информации о потребностях заинтересованных лиц в осмысленное описание системы, которую требуется создать. На ранних этапах определения системы принимаются решения о составе требований, формате документации, степени формальности языка, подробности требований (сколько формулируется требований и насколько подробно они формулируются), приоритете запросов, объеме работ по созданию системы (обычно используются две разные оценки, полученные разными людьми разными способами), управленческие риски и начальное содержание проекта. В ходе этой процедуры могут создаваться первые прототипы и модели, напрямую связанные с важнейшими запросами заинтересованных лиц. Результатом процесса определения системы служат графическое описание системы и описание системы на естественном языке.

Управление содержанием проекта

Для эффективного выполнения проекта нужно продуманно установить приоритеты требований с учетом информации, полученной от всех заинтересованных лиц, и определить охват системы. Многие проекты страдают из-за того, что разработчики занимаются "пасхальными яйцами" (функциями, интересными разработчикам) вместо того, чтобы с самого начала сконцентрироваться на задачах, представляющих максимальный риск для проекта или необходимых для стабилизации архитектуры приложения. Для максимально быстрого устранения или нейтрализации рисков нужно организовать поэтапную разработку системы, тщательно отбирать требования для реализации на каждом этапе, руководствуясь при отборе принципом минимизации рисков. Подобная организация процесса требует согласования содержания всех итераций с заинтересованными лицами. Для этого нужны хорошие навыки по управлению ожиданиями от различных этапов проекта. Кроме того, нужно поддерживать контроль над источниками требований, состоянием рабочих продуктов и собственно процессом разработки.

Уточнение определения системы

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

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

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

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

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

См. также Операция: управление изменением требований .

Дополнительная информация

Дополнительные сведения по данному вопросу можно найти в следующих источниках:

Прежде чем приступить непосредственно к обзору TopTeam Analyst, хотелось бы сказать пару слов о requirements management systems (системы управления требованиями). Многим будет полезно узнать, что на рынке IT анализа данная категория программного обеспечения уже давно нашла свою нишу. Все же, несмотря на это, количество компаний, активно использующих подобные системы для поддержки процесса работы с требованиями, в Беларуси мало. Среди причин можно выделить следующие:

Итак, что же такое RMS (requirements management systems/tools/software) и с чем их едят?

Наиболее известные системы управления требованиями на данный момент – Borland CaliberRM, IBM Rational DOORS и Rational RequisitePro, Case Complete. Также — правда условно — сюда можно отнести Sparx Enterprise Architect, который, являясь по большей части инструментом для UML моделирования, все же предоставляет некоторые возможности для работы непосредственно с требованиями.

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

Новые проекты создаются с использованием Quick либо Advanced Wizard. Advanced Wizard, в отличие от Quick Wizard, попросит вас указать имя проекта, выбрать проектного менеджера из созданных заранее пользовательских аккаунтов, выбрать участников проекта и настроить элементы работы с требованиям на проекте: работу с вариантами использования, тест кейсами, глоссарием и т.д.

В процессе работы над проектом TopTeam Analyst позволяет следующее:


1) Хранение и управление требованиями. Требования представлены довольно удобно, в виде дерева по иерархии, и основываются на типах требований, которые задаются администратором при конфигурации системы. В связи с этим, никто не мешает настроить связку Business requirement -> User requirement -> Functional + Non-functional requirements + Business Rules + Use Cases и т.д., и, как следствие, иметь вполне сносное дерево требований разных уровней. Для каждого требования имеется возможность заполнить большое количество как полезных , так и не очень атрибутов: версия, статус, источник, приоритет, итерация и т.п. Также можно назначить на работу над требованием определенного участника проекта, что отразится в его разделе Dashboard , который представляет список ваших задач, встреч и т.д. При работе над текстом требования имеется возможность использовать встроенный WYSIWYG-редактор, который, конечно, гораздо слабее MS Word, но все же позволяет довольно сносно отформатировать текст. Также имеется встроенная история, позволяющая отслеживать любые изменения в требовании.

Отдельно стоит отметить Traceability Matrix, которая позволяет взглянуть на требования в разрезе их взаимосвязи друг с другом. Данный функционал уже зарекомендовал себя в Sparx Enterprise Architect. Стоит отметить, что в TopTeam Traceability Matrix реализована на порядок приятнее и мощнее, чем в EA.
Также присутствует возможность выстраивать baselines требований по итерациям, релизам и т.д. и использовать довольно удобные средства сравнения baselines.

2) Глоссарий. Глоссарий позволяет хранить список терминов, использующихся в проекте. Также содержит встроенный spell checker (вроде бы, с поддержкой только английского языка) и позволяет разбивать термины на категории.

3) Разработка вариантов использования. TopTeam предлагает очень неплохую поддержку управления вариантами использования и актерами. Для вариантов использования можно задавать практически все возможные атрибуты и описания. Также имеется встроенная возможность создать и отредактировать UML activity diagram для сценариев варианта использования.

5) Моделирование. Из того, что было замечено: система позволяет строить неплохие контекстные диаграммы, диаграммы вариантов использования на основе заранее заданных use cases и actors (принцип и процесс построения диаграмм приятен и нареканий к нему нет), диаграммы навигации между экранами интерфейса, UML State и Activity диаграммы, а также free-form диаграммы (к сожалению, набор элементов для рисования маловат и с MS Visio абсолютно не сравнится).

6) Своеобразное моделирование пользовательских интерфейсов. Заметим, что TopTeam, видимо, не позволяет рисовать с нуля красивые эскизы. Вместо этого TopTeam позволяет снимать скриншоты (причем есть возможность скриншотить области экрана наподобие того, как это позволяет SnagIt) и заливать свои картинки. Все эти элементы привязываются к требованиям, и с помощью контролов Button и Text field в прототипы можно внести интерактивность.

7) Возможность создания и отправки на членов проекта issues, change requests, problem reports и др. В целом, если правильно настроить и организовать участие заказчика в использовании TopTeam (например, участие в обсуждениях, процесс review требований и т.д., наряду с классической отправкой CR и проблем), то можно добиться очень впечатляющих результатов в плане удобства организации рабочего процесса.

Проблемы, которые приходится решать специалистам в процессе создания программного обеспечения, обычно очень сложны. Природа этих проблем не всегда ясна, особенно если разрабатываемая программная система инновационная. В частности, трудно четко описать те действия, которые должна выполнять система. Описание функциональных возможностей и ограничений, накладываемых на программную систему, называется требованиями к этой системе, а сам процесс формирования, анализа, документирования и проверки этих функциональных возможностей и ограничений — разработкой требований (requirements engineering).

Термин требования (к программной системе) может трактоваться по-разному. В некоторых случаях под требованиями понимаются высокоуровневые обобщенные утверждения о функциональных возможностях и ограничениях системы. Другая крайняя ситуация— детализированное математическое формальное описание системных функций

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

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

Некоторые проблемы, возникающие в процессе разработки требований, порождены отсутствием четкого понимания различия между этими разными уровнями требований. Чтобы различить требования разных уровней, здесь используются термины пользователь­ские требования (user requirements) для обозначения высокоуровневых обобщенных требований и системные требования (system requirements) для детализированного описания вы­полняемых системой функций. Кроме требований этих двух уровней, применяется еще более детализированное описание системы — проектная системная спецификация (software design specification), которая может служить мостом между этапом разработки требований и этапом проектирования системы. Три перечисленных вида требований можно определить следующим образом.

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

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

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

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

Пример. Пользовательские и системные требования

Пользовательские требования

1. ПО должно предоставить средство доступа к внешним файлам, созданным в других программах.

Спецификация системных требований

Пользователь должен иметь возможность определять тип внешних файлов.

Для каждого типа внешнего файла должно иметься соответствующее средство, при­менимое к этому типу файлов.

Внешний файл каждого типа должен быть представлен соответствующей пикто­граммой на дисплее пользователя.

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

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

Пользовательские требования пишутся для заказчика ПО и для лица, заключающего контракт на разработку программной системы, причем они могут не иметь детальных технических знаний по разрабатываемой системе (рис. 4.2). Спецификация системных требований предназначена для руководящего технического состава компании-разработчика и для менеджеров проекта. Она также необходима заказчику ПО и субпод­рядчикам по разработке. Эти оба документа также предназначены для конечных пользо­вателей программной системы. Наконец, проектная системная спецификация является документом, который ориентирован на разработчиков ПО.



Разработка требований - это первая из основных фаз процесса создания программных сис­тем. Этот фаза состоит из следующих основных работ (рис. 5).

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

Анализ осуществимости. Должен выполняться для новых программных систем. На основании анализа предметной области, общего описания системы и ее назна­чения принимается решение о продолжении или завершении проекта.

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

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

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

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



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

понимание пользователями возможностей системы, решаемых ею задач, может из­мениться;

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

понимание разработчиками поставленных перед ними задач меняется.

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

К действиям по управлению требованиями относятся:

определение основной (базовой) версии спецификации требований для конкретной версии продукта;

анализ предлагаемых изменений требований, оценка воздействия и стоимости каж­дого изменения до его принятия;

включение одобренных изменений при помощи определенной процедуры;

согласование плана проекта с требованиями;

отслеживание отдельных требований от проектирования до кода приложения и его тестирования;

отслеживание статуса требований и действий по изменению на протяжении всего проекта.

В организации (или в проекте) должны быть определены действия по управлению требо­ваниями. Эти действия должны быть документированы и должны выполняться всеми уча­стниками проекта. При разработке процесса нужно определить:

методы и средства управления версиями спецификации и отдельных требований;

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

процесс присвоения, контроля и изменения статуса требования;

процесс передачи новых требований и изменений существующих требований заин­тересованным лицам;

методы анализа влияния и стоимости внесения изменения.

Кроме этого описание процесса должно содержать определение участников проекта, от­ветственных за выполнение каждой конкретной задачи.

Минимальной единицей управления в спецификации требований является отдельное тре­бование, поэтому вопрос идентификации требования достаточно важен. Форма представления требования может быть различной (текстовая, графическая и т.д.), поэтому для идентификации требования обычно используют связанный с ним набор атри­бутов. Атрибутами могут быть: дата создания требования, номер текущей версии требо­вания, номер версии продукта, для которой предназначено требование, автор требования, ответственный за реализацию требования, состояние требования, происхождение и обос­нование требования, подсистема, для которой предназначено требование и т.д. Главное при выборе атрибутов, чтобы они однозначно идентифицировали требование и его со­стояние.

Таблица 1. Состояния требования

Определение

Требование запрошено авторизированным источником

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

Код, реализующий требование разработан, написан и протестирован. Требование отслежено до соответствующих элементов дизайна и кода.

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

Утвержденное требование удалено из базовой версии. Следует зафикси­ровать причины и лицо, принявшее это решение.

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

После разработки, согласования и утверждения спецификация требований становится ос­новным документом в проектировании системы (версии системы). Изменения в этот до­кумент разрешается вносить только через определенный в организации (или проекте) процесс внесения изменений.

Диаграмма состояний для типового процесса внесения изменений в спецификацию приве­дена на рис. 6.

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

Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.

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

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

Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и не­функциональными.

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

Группа функциональных требований

Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.

Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases).

Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

Группа нефункциональных требований (Non-Functional Requirements)

Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.

Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.

Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.

Ограничения (Constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, . ), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.

Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функциисистемы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.

Управление требованиями на платформе T-FLEX PLM

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

Комплексный взгляд на проблему привёл к пониманию того, что работа с требованиями – это постоянный процесс, начинающийся задолго до начала проектирования изделия и завершающийся только после полного прекращения его эксплуатации. На самом деле, ведь если любая работа начинается с технического задания (а иногда работа над требованиями даже предшествует формированию технического задания), то это и есть, по сути, та самая спецификация требований верхнего уровня. Т.е. появление ТЗ – это первый шаг в работе над требованиями. Фактически, формирование структуры требований на самом начальном этапе проектирования позволяет сформировать начальный облик изделия. И дальше, по мере конкретизации проекта и подбора подходящих типовых компонентов и решений, работа с требованиями является основной всего процесса проектирования.

Общая логика разработки изделия на основе требований представлена на рисунке 1.


Рис1. Разработка изделия на основе требований в T-FLEX PLM

По мере продвижения проекта разработчики проводят декомпозицию первичных, часто слишком общих, требований и постепенно наполняют спецификацию требований необходимыми деталями. В соответствии с этой спецификацией всё более и более детально прорабатывается и конструкция будущего изделия. Но процесс разработки не является однонаправленным. Для снижения рисков и стоимости проекта на каждом шаге идёт постоянный процесс выявления несоответствия предъявляемым требованиям, и вносятся коррективы. Так, например, на этапе эскизного проектирования происходит, с одной стороны, верификация требований верхнего уровня, а с другой - формирование частных спецификаций требований на отдельные подсистемы и компоненты изделия. А на этапе разработки КД и инженерных расчётов уже выполняется верификация отдельных технических решений и формируются требования к компонентам и технологиям производства. По мере создания изделия процессы верификации и валидации проходят уже снизу-вверх, т.е. контроль требований к компонентам, контроль отдельных узлов и агрегатов, проверки межсистемных взаимодействий и наконец, приёмка изделия заказчиком.

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


Рис.2. Модель данных системы управления требованиями

Как видно, цикл работы с требованиями довольно прост. Любые исходные данные могут быть структурированы и помещены в специальный раздел хранилища документов. В процессе структурирования специальные инструменты платформы T-FLEX PLM обеспечивают автоматический разбор исходного файла на отдельные элементы (заголовки, пункты нумерованных списков, картинки, формулы и т.п.), после чего структурированный документ и помещается в хранилище и его фрагменты могут быть использованы в качестве исходных данных для создания требований.

Работа с требованиями предполагает большой набор развитых инструментов. Среди них:

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

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

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

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

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

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

Говоря об организации работы с требованиями в комплексе T-FLEX PLM, необходимо обратить внимание на то, что возможности современной PLM-платформы обеспечивают не только работу с требованиями, но и все сопутствующие процессы. Мы уже говорили о том, что все этапы работ могут проходить под контролем единой многоуровневой системы управления проектами, которая выступает в качестве единой управляющей оболочки. Но с технической точки зрения разработка изделия на основе требований выглядит как единая модель данных, объединяющая три основных составляющих: требования, архитектуру (функциональную модель) и электронный макет изделия. Объединённая на базе платформы T-FLEX PLM, эта модель данных представлена на рисунке 3.


Рис.3. Единая среда проектного управления на основе требований

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

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

На начальном этапе мы вводим требуемые характеристики, как специальный вид требований. Работа с ними происходит по общей для всех требований схеме: исходные данные – требования – согласование – проверка соответствия – подтверждение выполнения требования. Но тут в действие вступают другие инструменты, привнесённые платформой T-FLEX PLM. Спецификация требований связана с изделием - а значит сформировать перечень основных характеристик изделия на основе подтверждённых требований мы сможем автоматически. Именно так это и работает. Конечно, подготовить список характеристик изделия можно и вручную. Но гораздо удобнее и правильнее, если основной набор характеристик изделия сформируется автоматически. Мало того – у вас всегда будет возможность увидеть не только значения, полученные в результате проектирования изделия, но и всю информацию о том, какие требования предъявлялись, при помощи каких расчётов, испытаний или измерений были получены итоговые значения характеристик, увидеть акты и протоколы этих испытаний и получить соответствующие документы. Для решения задач приёмки и сертификации изделий – необходимый инструмент.

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

И наконец, нельзя не отметить ещё один важный аспект единой модели изделия, создаваемой под управлением требований. Это возможность сквозного управления конфигурациями изделия, которая в полной мере распространяется и на требования к этому изделию. Такой подход позволяет говорить о разработке целых серий или нескольких параллельных веток в классификаторе изделий. Разнообразные инструменты конфигурирования предоставляют пользователю возможность гибко управлять применяемостью отдельных компонентов, узлов или даже отдельных деталей, автоматически формировать структуру изделия на основе опций, вести параллельную разработку нескольких решений в рамках одного проекта. Всё это требует более гибкого управления требованиями, нежели просто разработка жёсткой спецификации требований. Для этого в решении T-FLEX PLM имеются инструменты конфигурирования спецификации требований, позволяющие увязать в единое целое иерархию проектов, серий и конфигураций изделий с автоматически конфигурируемым электронным макетом и спецификацией требований.

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

Читайте также: