DRAKON.SU

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

Глава 1. Требования. Виды Требований. Спецификации требований

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

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

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

Виды требований. Требования делятся на два класса: функциональные и нефункциональные. Функциональные требования определяют поведение реактивной системы. Есть разные подходы к описанию функциональных требований. Наиболее популярной формой являются сценарии использования (use case): на каждое событие в окружении определяется реакция реактивной системы с указанием всех вариантов. Виды нефункциональных требований следующие:

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

Кроме Википедии есть неплохая переводная книга Карла Вигерса.

Какими должны быть спецификации требований? На этот вопрос отвечает стандарт: 830-1998 — IEEE Recommended Practice for Software Requirements Specifications. Появился русский перевод. Хорошие спецификации должны быть: корректными, однозначными, полными, согласованными, ранжированы по значимости и обязательности, проверяемыми, модифицируемыми, хорошо организованы для анализа.

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

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

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

Глава 2. Пример. Освещение в отсеках подлодки

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

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

Функциональные требования управления освещением (релиз 1). Имеется кнопка для включения и выключения лампочки. Нажатие кнопки включает лампочку. Она горит слабым светом. Двойное нажатие кнопки зажигает лампочку ярким светом. Повторное нажатие кнопки выключает лампочку.

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

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

Не надо лампочки с двойной спиралью. Проще использовать вторую лампочку.
Не надо второй лампочки. Кто не видит пусть фонариком подсветит.
Не надо фонарика и лампочки тоже. Все наши матросы отлично видят в темноте.

Кнопка. Слишком примитивно. А что взамен?

Лучше тумблер или простой выключатель.
Выключатель? Еще хуже. Используйте панель. Касание -- лампочка зажгись!, двойное касание -- зажгись ярким светом.
Панель? Это нам известно. Двойное касание на смартфоне. А в ответ тишина.
Есть лучшее решение. Сказал ласковое слово -- лампочка зажглась, сказал второе -- зажглась ярко.

Объявится Системщик и скажет: "Все вы тут безнадежные теоретики. Жизни не знаете". Разумеется, реализация в железе (материале) -- не наша задача. Это предмет системной инженерии.

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

Надо проверить, что определенные выше функциональные требования (релиз 1) являются правильными. Программа верифицируется по отношению к своей спецификации, а требования сверять не с чем. Требований проверяются на предмет соответствия потребностям пользователей, а также некоторым общим нормам и правилам. Этот процесс называется валидацией требований. Чем отличается валидация от верификации, разъясняется в обзорной статье Виктора Кулямина.

Проверим функциональные требования на соответствие общим правилам, изложенным в стандарте IEEE-830-1998. Хорошие требования должны быть: корректными, однозначными, полными, непротиворечивыми и т.д. Оказывается, наша формулировка требований (релиз 1) не удовлетворяет данным правилам.

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

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

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

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

Требования. Релиз 2

Требования управления освещением (релиз 2). Имеется кнопка для включения и выключения лампочки. Нажатие кнопки включает лампочку. Она горит слабым светом. Повторное нажатие на кнопку выключает лампочку. При двойном нажатии (быстрым нажатием на кнопку дважды) лампочка включается и загорается ярко. Нажатие считается двойным, если второе нажатие запаздывает по отношению к первому не более чем на две секунды.

Требования. Релиз 3

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

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

Управляющие состояния:

темно – лампочка выключена
тускло – лампочка включена и горит слабым светом
ярко – лампочка включена и горит ярким светом

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

Окружение:

нажатие -- сигнал, возникающий при нажатии кнопки

Используется оператор приема сигнала "нажатие". Оператор ждет нажатия кнопки, после чего передает управление следующему действию.

Описание требований представим в виде следующей Дракон-схемы.

Требования. Релиз 4

Формализация требований (релиз 3) не полна. В ней полностью формализовано управление. Однако одно действие определено содержательно. Это проверка "прошло менее двух секунд". Для формализации этого действия необходимо завести переменную, в которой замеряется время после первого нажатия кнопки. Значение этой переменной определяет состояние процесса, представляемого требованиями.

Состояние:

таймер t -- время в миллисекундах от первого нажатия кнопки

Здесь обнаруживается, что начальное значение переменной t должно быть задано, и это действие ошибочно пропущено в требованиях (релиз 3).

Окончательная версия требований представлена Дракон-схемой:

Замечания

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

Кроме естественного языка существует много формальных языков, текстовых и графических, используемых для описания требований. Требования (релиз 3) определяют промежуточный уровень, в котором полностью формализовано управление, а реализация действий и состояние процесса определены содержательно. Язык Дракон -- один из немногих, допускающих промежуточный уровень формализации. В большинстве числе случаев Дракон применяется именно в стиле релиза 3. Например: фрагмент программы из сообщения "ИС Дракон на Луне".

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

Не возражаю по существу Владимиру Шелехову.
Но хотел бы предложить несколько изменённую схему.

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

Кстати, сам DRAKON Editor (онлайн-версия) тоже сгенерирован из схем подобного вида.

Ожидание — это состояние!
Данный подход позволяет визуализировать все значимые сочетания событий и состояний.

С Новым годом!

http://forum.oberoncore.ru/viewtopic.php?p=94392#p94392
Из за общения с мышами, у современного человека сформировался рефлекс двойного нажатия.

1. В текстовом функциональном требовании не описана реакция на двойное нажатие для каждого состояния.
Следовательно Дракон-схему нельзя построить.

2. В Дракон-схемах не определены иконы Действия для исполнения включения и выключения ламп освещения.

RESPECT.
Я ждал такой реакции. К счастью, дождался.
Вы спасли участников Форума от несправедливого вердикта Системщика.

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

Требования. Релиз 5

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

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

Изначально системная инженерия и инженерия требований разрабатывались в рамках NASA и лишь в 1990-х эти области приобретают широкое распространение в мире. В нашей стране можно говорить лишь об ограниченном точечном распространении. Отставание от мирового уровня примерно лет на 15.

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

В настоящее время инженерия требований преподается в составе курсов по программной инженерии лишь в четырех-пяти Российских университетах. Впервые такой курс появился в 2006г.: Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии программного обеспечения. Тема 3. Методы определения требований ... и долгое время оставался единственным.

В этих условиях зарубежные и отечественные фирмы, специализирующиеся в разработке информационных систем, вынуждены самостоятельно проводить обучение своих сотрудников методам инженерии требований. Это, например, Российская IT-компания Webis group, обеспечившая перевод стандарта 830-1998 — IEEE. Еще раньше практику колониального культурного просвещения в области инженерии требований начали проводить для своих сотрудников зарубежные фирмы, как например, Scade, основавшие филиалы своих фирм в России. Пользуясь нашей отсталостью они небезуспешно сумели продлить жизнь своим продуктам и технологиям, потерявшим спрос на мировом рынке.

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

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

Материалы по инженерии требований и системной инженерии

1. Книга Анатолия Левенчука Системноинженерное мышление

2. Лекции Левенчука А.И. по системной инженерии и инженерии требований

3. Слайды по инженерии требований

4. Учебное пособие: Анализ требований к информационным системам

Имеется Форум Сообщества Аналитиков, в нем подфорум Системный Анализ и Требования по тематике ближе ко второй части инженерии требований.

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

Мне кажется, что инженерия требований должна развиваться в сторону формального описания требования и формальной верификации требований (что разные требования не противоречат друг другу, что они полны и так далее).
На практике, я видел только неформальные спецификации, которые написаны в виде Use Case, и вроде бы всё хорошо написано, соответствует best practices, которые используются в компаниях, разрабатывающих софт. Но когда начинаешь разрабатывать программу по этим спецификациям, выясняется, что какие-то требования могут противоречить друг другу и нужно решать этот конфликт, иногда выясняется, что не все случаи описываются (допустим, есть 3 логических значения, и возможно 8 разных случаев, но в спецификации могут описываться, например, только 3 из 8 случаев, а что делать в остальных случаях не понятно).
Думаю, если бы спецификации были более формальные, то неполноту и противоречивость спецификации можно было бы заменить раньше.

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

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

Спасибо, это интересные материалы.


Ещё одна "протухшая CASE-система"? Надеюсь, нет. Но в чём её выгодные отличия от "протухших"?

"взяли" из суровой реальности
после отмены двухстадийного проектирования П и РД во многих случаях стали делать одновременно.
и получилось:
"сквозное проектирование" - т.е. способ организации работ с возможностью передачи и учёта проектных измененний не только внутри одного уровня проектирования, но и между уровнями работ - в обоих направлениях по иерархии проекта.
Благодаря существующим CASE-системам, в большинстве случаев, это выполняется вручную - с сопутствующими ошибками и утечками.

Собственно, требования на уровне бывших стадий известны давно и в большинстве своём озвучены теперь простой перепевкой иеее и гостов. Читать же очередную пачку/*мишуры*/ ISO, внедряемых для извлечения разведданых, можно очень долго, поэтому гораздо интереснее спросить,

определена ли формальная модель взаимного преобразования разноуровневых требований?

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

Не знаю, вряд ли.

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

Статья по управлению требованиями
 http://drakon.su/_media/biblioteka/upra ... a_2010.pdf

Это перевод руководства "Ten steps to better requirements management", в конце которого автор Д. Тавассоли рекламирует IBM Rational software, а русский перевод рекламирует компанию SWD. Наверное, автор хотел написать что-то новое, интересное и в другом ракурсе, а получился примитив в кондовом американском стиле, с моей точки зрения, бесполезный. Нехорошо, что автор не ссылается на первоисточники.

У кого-то может появиться иллюзия, что это руководство поможет достичь совершенства в области Requirements Engineering. Это не так. Лучше начать с изучения стандарта. В любом случае надо будет долго и серьезно учиться. Самостоятельно это способны немногие. Советую посещать курсы, выполнять учебные задания под присмотром опытного педагога, постепенно нарабатывая опыт и квалификацию.

Глава 3. Языки описания требований

Описание требований может быть дано содержательно на естественном языке или на одном из формальных языков спецификации требований. Исследования, проведенные в 2004г. по разным фирмам в среде инженеров требований дают следующую статистику: естественный язык, английский (80%), формализованное подмножество естественного языка (15%) и формальный язык (5%). Использование лингвистических процессоров позволяет транслировать требования на формализованном естественном языке в формальную модель с последующим применением различных инструментов анализа требований. Отметим, что 5% -- это среди квалифицированных специалистов по инженерии требований, а не программистов. В настоящее время, спустя 10 лет, статистика вряд ли намного лучше. Потому что писать требования на формальном языке способны лишь владеющие формальными методами.

Вернемся к нашему примеру определения требований к программе управления освещением в отсеках подлодки. Релизы 1 и 2 определены на естественном языке. Релизы 4 и 5 в виде Дракон-схем следует квалифицировать как формальные определения. А вот Релиз 3 в виде Дракон-схемы -- промежуточный уровень между содержательным и формальным описанием: управление строго определено, а действия процесса описываются содержательно. Этот уровень языка требований оказался неучтенным в приведенной статистике. В большинстве числе случаев Дракон применяется именно в стиле Релиза 3. Например: фрагмент программы из сообщения "ИС Дракон на Луне".

Поскольку написание формальных требований доступно для немногих, использование языка Дракон в качестве языка спецификации требований в гибридном стиле Релиза 3 приобретает интерес. Впрочем, в таком стиле можно использовать и другие графические языки, в частности широко известный UML, с диаграммами use case для описания требований, оснащенный множеством разнообразных инструментов. Однако меня тошнит от UML. Физически, чуть не до рвоты. Таких как я с резким неприятием UML, оказывается, достаточно много. К тому же выясняется, что UML применяется преимущественно в академической среде, не в индустриальном программировании. Скорее всего, UML обладает серьезными эргономическими недостатками и в этом плане заметно проигрывает менее известному языку Дракон.

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

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

<условие 1>, <условие 2>,…, <условие n> --> <действие 1>, …, <действие m>

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

Требования по управлению освещением в подлодке. Релиз 6

темно, нажатие --> таймер t=0, включить спираль 1, тускло
тускло, нажатие, t<2000 --> включить спираль 2, ярко
тускло, нажатие --> отключить спираль 1, темно
ярко, нажатие --> отключить спираль 1, отключить спираль 2, темно

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

На форуме программирование в соответствии с такими функциональными требованиями описано Геннадием Тышовым 27 Сентябрь, 2009 - http://forum.oberoncore.ru/viewtopic.php?p=35027#p35027. Техника программирования получила наименование: стиль - Скульптор.

Глава 4. Новый стандарт по инженерии требований

Стандарт 1998г. по инженерии требований для программной инженерии 830-1998 — IEEE Recommended Practice for Software Requirements Specifications отменен. Вместо него действует стандарт Systems and software engineering — Life cycle processes — Requirements engineering. ISO/IEC/ IEEE 29148. Это стандарт 2011г. по инженерии требований, причем сразу для системной и программной инженерии.

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

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

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

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

1. Общие регламентации
Степень обязательности требований регулируется модальностями "shall", "should" и "may".
Проблема здесь в том, как эти модальности адекватно отразить в русском языке.
Не рекомендуется использование "will" и "must", местоимений "он", "она", "этот", "тот",
а также формулировки утверждений в отрицательной или пассивной форме.
Это напоминает детскую считалку: черно с белым не берите, "да" и "нет" не говорите ...

2. Характеристики хороших требований
Хорошее требование должно быть:

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

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

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

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

Продолжение следует.

Новый стандарт по инженерии требований (Продолжение)

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

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

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

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

Правильно написанное требование должно сопровождаться набором атрибутов, перечисленных ниже:

уникальное имя требования
приоритет стейкхолдеров — от 1 до 5 или "высокий", "средний", "низкий"
зависимость от других требований
оценка риска — "низкая", "высокая", ...
автор требования
основание необходимости данного требования
трудность — "средняя", "высокая", ...
тип требования — см. ниже

Примерный список типов требований

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

требование качества (живучесть, гибкость, переносимость, сопровождаемость, переиспользуемость, надежность, секретность, ...)
гуманитарное требование (безопасность, эффективность, защищенность, ...)

Общая структура деятельности, определяющей контекст инженерии требований, представлена в Разделе 5.4 стандарта.
Разделы 6-9 определяют структуру и процесс разработки документов трех видов:

— спецификация требований стейкхолдеров;
— спецификация требований системы;
— спецификация требований программы (программного обеспечения).

Рисунки 4 и 5 Раздела 5.4 рельефно представляют взаимосвязь этих трех видов спецификаций в общем контексте.

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

Рекомендуемая структура и содержание указанных трех видов документов по спецификации требований вызывает много вопросов.
В целом, разделы 6-9 стандарта выглядят сумбурными и недоработанными.
Впрочем, описание многих разделов начинается "For example".
Это означает, что содержание материала является примерным и может меняться и дополняться в зависимости от конкретного приложения.
Поэтому многие рекомендации нельзя воспринимать буквально.
Например, описание очередного требования вряд ли следует снабжать полным набором всех указанных атрибутов требования.

По данному стандарту имеются комментарии Анатолия Левенчука.