Декомпозиция требований и примеры

Loading...

Из курса от партнера Moscow Institute of Physics and Technology

Введение в системное проектирование

31 оценки

Moscow Institute of Physics and Technology

Введение в системное проектирование

31 оценки

Развитие современных индустриальных технологий упрощает для человека исполнение производственных процессов. Входные барьеры в новейшее производство понижаются и становятся доступными для всё более широкого круга игроков. Наоборот, придумывание, проектирование и быстрое прототипирование новых вещей и технических систем, других рукотворных объектов, организация и управление подобными процессами и проектами требует все более развитых компетенций. И именно сюда сегодня смещаются центры получения прибыли и инкубаторы деловых карьер мировой экономики. Сами процессы придумывания инновационных идей и создания новых продуктов тоже претерпевают развитие и становятся объектом применения системных метаконструкторов. Основы современного системного проектирования представлены в этом курсе. Курс реализует функцию навигатора для тех, кто ориентирован на деловую карьеру в умных высокотехнологичных сферах экономики, включен в программу Системы инжиниринга, менеджмента и управления 2.0 (лэндинг Программы 2.0: http://artofsystems.ru/).

Из урока

РАЗРАБОТКА ТРЕБОВАНИЙ - ОСНОВА СИСТЕМНОГО ПРОЕКТИРОВАНИЯ

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

Правила формулирования хороших требований5:47

Декомпозиция требований и примеры9:37

Познакомьтесь с преподавателями

Романов Алексей Александрович
Доктор технических наук, профессор.
Кафедра радиотехнических космических систем
Кондратьев Вячеслав Владимирович
Доктор технических наук, профессор
Кафедра проблем управления, R&D ФРТК МФТИ

Как правильно декомпозировать требования и какие

примеры правильных требований существуют?

Вот на данном слайде мы видим перечень

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

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

Здесь очень большой спектр функций,

под каждой из которых существует свой набор требований

и их соотнесение необходимо строго соблюдать.

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

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

и в этом смысле мы видим,

что эти требования именно возникают как вторичный поток,

зависящий от специфики выполняемой функции.

Ну например: чтобы автомобиль мог иметь диапазон скоростей от 0 до 100 км/ч,

необходимо выполнить требования наличия

максимальной массы и минимальной мощности двигателя.

В противном случае, указанное требование соблюдено не будет.

Или есть другие варианты,

которые тоже можно рассмотреть.

Очень важный аспект: часто разработчики

путают понятия «требования» и «пожелания».

Вот «пожелание» – это нечто такое,

что было бы хорошо иметь, но необязательно достигать в реалии.

А «требование» – это как раз то,

что обязательно должно быть сделано для того,

чтобы созданная система была успешной.

Поэтому потребители и участники часто,

не различая, что необходимо, и что желательно,

путают эти понятия, а путать их ни в коем случае нельзя.

Еще одно важное обстоятельство: при формулировке проблем

необходимо абстрагироваться от возможного

пути решения данной проблемы.

И подобный подход

гарантирует вас от того, что вы,

рассматривая возможность решения,

можете сделать не очень правильную формулировку постановки задачи.

И в этом смысле, призыв,

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

аккуратны при выборе идеи для реализации,

потому что пользователи и заказчики часто могут иметь хорошую идею,

но быстро предложенное решение далеко не всегда оптимальное и может выявить,

в том числе, невозможность реализации,

а также непрактичность и неоптимальность.

Разобравшись в деталях, отбирайте только то,

что необходимо для достижения реального успеха и только потом

разрабатывайте конкретное решение, удовлетворяющее

подтвержденной необходимости ее реализации.

Требования также подразделяются на конкретные типы.

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

определяющие что данный элемент должен делать.

Точностные требования, которые определяют количественные

параметры соответствующих функций, выполняемых системой.

Ограничительные требования, которые вытекают из ограничений

решений в процессе эксплуатации системы.

Верификационные требования, которые обеспечивают то,

что можно доверять принятым решениям,

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

Далее мы приводим некоторые примеры,

которые возникают при неправильном формулировании требований.

Ну вот здесь показано, что три основные ошибки,

которые предъявлены в данной формулировке,

это: неопределенность, избыточность и незаконченность фразы.

Вот и первого, и второго, и третьего нужно избегать,

и на втором слайде уже представлены

скорректированные варианты этих определений,

где присутствуют и законченность требования, и конкретность требования,

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

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

обеспечивающих управление требованиями.

И, безусловно, разработчики очень часто их применяют.

К сожалению, далеко не все они легкодоступны,

но, тем не менее, они существуют.

Теперь посмотрим на примере гипотетического самолета

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

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

Самолет такой-то должен перевозить 200 пассажиров и багаж.

Самолет такой-то никогда не должен попадать в аварии.

Может везти 2 000 литров топлива и,

наконец, должен быть максимально комфортным в обслуживании самолетом,

начиная с 2010 года.

Вот давайте разберем: правильные требования или неправильные?

Требование № 1: самолет должен перевозить 200 пассажиров и багаж.

Правильное требование.

Потому что означает кто должен,

и данное требование легко проверить простой инспекцией.

Второе требование: никогда не должен попадать в аварии.

Неправильное требование, потому что использует при своем написании отрицание.

А мы говорили, что ни в коем случае формулировка требования

не должна содержать отрицания.

Может везти 2 000 литров топлива – тоже неправильное требование.

Потому что использование глагола «может»

означает цель, а не требование.

И наконец, последнее: должен быть максимально комфортным.

Также неправильная формулировка.

Комфорт определить нельзя.

Комфортабельно для кого?

Каким образом это проверить?

Как же правильно эти требования переделать?

Ну, первое требование, мы уже говорили,

что оно правильное и его переделывать не нужно.

Второе требование должно быть переписано так: самолет должен быть оборудован

системой предупреждения о сближении с землей для уменьшения риска

контролируемого полета на местности.

Третье требование.

Глагол «может» должен быть заменен на глагол «должен»,

и тогда оно становится правильным.

И, наконец, последнее требование: самолет такой-то должен

обеспечить на 50 %,

больше пространства, для чего минимально требуется,

что минимально требуется

для перевозки 90 % американских мужчин.

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

Ознакомьтесь с нашим каталогом

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

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

© Coursera Inc., 2018 Все права защищены.

Загрузить из App Store

Загрузить в Google Play