Комментарии 4
А вы не путаете требования с решением? Ни одного требования не увидел. И ещё - не понял, для какой целевой группы ваше описание. И сильно абстрактно. Даже и выделить особенно не могу что-то отдельное.
Предвидел вопрос. Зачастую в требованиях, передаваемых в разработку, описывается и решение.
Какой-то подвох здесь. Даже и не знаю, как это физически возможно. Ваш первый пример для приготовления пищи и требования очищения оперативной памяти как раз об этом. Тот, кто описывает требования для реализации - не может требовать очищения оперативной памяти, он даже о её существовании может и не знать. Может для реализации вообще без неё всё будет. В другом примере вы описываете, что "частично видимый объект распознаётся другим процессором". Что это? В требованиях описывают, что из себя представляет 'частично видимый объект', как его используют для той или иной функции. А тут - какая-то череда непонятно чего.
Хотя я понял, что это у вас? Это краткое описание решения на человеко/техническом языке, но именно тогда, когда решение уже существует. И с требованиеми это не имеет ничего общего. Погуглите по-больше, что из себя софтверные функциональные и не-функциональные требования представляют. Будет больше ясности.
Согласен с @Myclass
(статью смотрел по диагонали, такой формат тяжело воспринимаю, могу где-то ошибиться. Субъективно: попытки под хи-хи-ха-ха поработать с сущностью робота Фёдора воспринимаю как галимую попсню)
Заголовок статьи - про "улучшить читаемость ФТ", но в самом текте - как из Use Case вытащить эти ФТ.
И кто такой, внезапно, "читатель"?
Текст воспринял как мешанину и путаницу понятий и методов
Простые способы улучшить читаемость функциональных требований