Роль и представление потребностей заказчика в системном проектировании с помощью Cradle

автор: Mark Walker
Перевод: Куксенок Ю.А.
Адаптация: Мадорская Ю.М.
Переведено и опубликовано с разрешения автора.

Введение

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

Темой данной статьи являются потребности (needs).

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

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

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

Терминология

Таблица 1: Терминология
Термин Определение
Продукт Физический или логический объект, обладающий поведением для изменения его окружения
Потребность То, что может быть достигнуто путем реализации требований в продуктах
Пользовательское
требование
Внешне видимый признак которыми обладает продукт
Системное
требование
Характеристика, которой  должен обладать компонент продукта, чтобы сам продукт мог удовлетворить требования пользователя
Валидация Проверка того, что внешне видимая характеристика продукта соответствует требованиям
Верификация Проверка того, что внутренняя характеристика компонента продукта соответствует требованиям
Тест Проверка компонента продукта, необходимая для подтверждения его поведения или структуры
Проект Ряд действий по созданию или обновлению продукта и соответствующей информации по нему

Концепция

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

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

Существует целый ряд таких комплексов потребностей:

  • сформированные внутри вашего бизнеса,
  • сформированные  из каждого запроса каждого клиента.

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

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

Примеры внутренних потребностей :

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

Потребности будут создаваться на основе:

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

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

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

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

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

Структура потребностей и организация в проектной базе

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

Таблица 1: Общая структура потребностей

Таблица 1: Общая структура потребностей

Если в проект включаются потребности от нескольких групп, как, например, в Проект P12 , то у такого проекта будет несколько иерархий потребностей, связанных с проектом, как описано в разделе 4 “Трассируемость” на странице 4.

Как организовывать потребности внутри иерархии – полностью зависит от вас. Так, например, потребности можно организовать по типам:

Таблица 2: Организация потребностей по типам

Таблица 2: Организация потребностей по типам

или же по инженерным дисциплинам:

Таблица 3: Организация потребностей по категориям

Таблица 3: Организация потребностей по категориям

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

Трассируемость потребностей

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

Таблица 4: Проекты и потребности

Таблица 4: Проекты и потребности

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

Представление в базе данных

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

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

организация.проект.иерархическое число

Например:

  • Внутренний.Проект-Р12.1.2
  • КлиентB.P4-2016.2.3.4

где имена элементов  1.2.3… в иерархии будут основываться на критерии структурирования, которые вы выберете. Если это тип, то значения элементов .1, .2, .3 …в каждой иерархии потребностей будут следующими: Коммерческий, Экологический и т.д.

Потребностям понадобятся атрибуты, чтобы :

  1. Поименовать потребность, сокращенно или просто кратко описав.
  2. Описать потребность, с помощью:
    1. Простого текста или rtf,
    2. схемы (JPEG) и таблицы (RTF),
    3. Excel, Word, Visio или PDF документов.
  3. Добавить заметки.
  4. Классифицировать:
    1. По дисциплине, например: Оборудование, Программное обеспечение, Механические средстваПродажи, Маркетинг, Прочее.
    2. По зрелости, например: Приятно, Новое, Отклонено, В процессе.
    3. По приоритету, например: Высокий, Средний, Низкий.

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

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

Схема базы данных

Потребности — один из наборов элементов базы данных. Ниже представлена простая схема для процессов разработки продукта (имя типа элемента в круглых скобках):

Таблица 5: Схема базы данных

Таблица 5: Схема базы данных

Верификация

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

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

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

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

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

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

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

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

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

Спецификация типа элемента для описания потребностей

Элемент – это базовая единица управления в базе данных Cradle. Каждая потребность будет представлять элемент типа NEED. Этот тип определяется следующим образом:

Таблица 1: Определение типа элемента
Имя типа Категории Фреймы Авто-нумерация Иерархия Адаптации История изменений
Имя Тип фрейма
NEED Дисциплина
Завершенность
Приоритет
Вычисления EXCEL (XLSX) ДаN-n n=1,2,3… Да, в Key Нет Да
Диаграмма VISIO
Документ WORD (DOCX)
Иллюстрация JPEG
Заметки Простой текст
Текст с форматированием RTF
Слайды POWERPOINT (PPTX)
Таблица RTF
Текст Простой текст

Коды категорий

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

Код категории определяется один раз и может быть использован для многих типов элементов.

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

Категории определены в следующей таблице:

Таблица 2: Определения кодов категорий
Имя Тип Значения (* = значение по умолчанию)
Дисциплина Список выбора Оборудование, Программное обеспечение, Механические средства, Продажи, Маркетинг, Прочее, TBD*
Зрелость Список выбора Принято, Новое, Отклонено, В процессе, TBD*
Приоритет Список выбора Высокий, Средний, Низкий, TBD*

Типы связей

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

Типы связей, используемые в схеме на рисунке 5 «Схема базы данных»:

Таблица 3: Определение типов ссылок
Имя Значение
РАСПРЕДЕЛЕНО В Описывает, как требования к продукту связаны со компонентами продукта
ИМЕЕТ ДОЧЕРНИЙ ЭЛЕМЕНТ Описывает иерархическую взаимосвязь «родитель — дочерний элемент»
АДАПТАЦИЯ Указывает, что элемент — адаптация другого элемента, обычно в библиотеке
ПРОВЕРЯЕТСЯ Описывает, как подтверждается, что элемент реализован
ССЫЛАЕТСЯ Указывает, что элемент использует другой элемент для достижения цели
СООТВЕТСТВУЕТ Показывает переход одного набора данных в другой в ходе проектирования

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

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

Правила связей

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

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

Они могут влиять на:

  • Один или несколько типов элементов.
  • Элементы со стереотипами, (являются частью поддержки Cradle MBSE), на один или все стереотипы, или стереотип и его иерархия.
  • Элементы одного типа или элементы, соответствующие заданным критериям.
  • Всех пользователей, группу пользователей или одного пользователя.
  • Одну или несколько операций со связями.

Для определения правила связи для схемы, мы рекомендуем:

  • Определить правило связи, которое запрещает все операции для всех пользователей на все связи между всеми типами элементов.
  • Перед этим правилом создать правила, соответствующие каждой связи, отраженной на рискунке рисунке 5 «Схема базы данных».

Навигации

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

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

Таблица 4: Определение навигации
Имя Описание
Down No Adaptations by Key Следует за всеми типами связей, кроме тех, которые идут к источнику адаптации, сортируя соединенные элементы по Key
Via References Следует за ссылкой типа ССЫЛАЕТСЯ двунаправлено, сортируя соединенные элементы по Key
Via Adaptations Следует за ссылкой типа АДАПТАЦИЯ двунаправлено, сортируя соединенные элементы по Key

Заключение

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

Добавить комментарий