При "проработке нефункциональных требований", ИТ аналитик сталкивается с проблемой: "надежность/доступность системы должна быть 99.5%", "время открытия страницы должно быть 3 секунды". А почему не 99.9% или 99.99999% или не 1 или 0.0001 секунды ? В реальности, должен быть достигнут баланс обеспечения качества между потерями бизнеса от необеспечения и расходами на обеспечение.

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

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

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

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

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

Кто-то сказал “Аналитик разрабатывает требования”. За ним повторили. Много-много раз. Тысячу раз. Но это не так.

Проектировщик-аналитик выявляет потребности, выявляет/проектирует требования и разрабатывает модели решения.

А есть разница ? Давайте разберемся (истиной мы будем считать то, что работает, а не то, что повторили за кем-то тысячу раз).

Вопрос обязательности умения/знания/понимания программирования для ИТ-аналитика-проектировщика вызвал жаркие дебаты в профильных группах. Приводились два вида аргументов:

Люди не всегда понимают, что им говорят/передают другие люди. Например, читая книги я частенько сталкиваюсь с сплошными абстракциями (что авторы на самом деле имели в виду - неясно, ты должен догадаться сам, при этом авторы оставляют за собой право судить, правильно ли ты догадался или нет). Как же передавать смысл понятным образом и давать понятные определения - вот о чем статья.

“Аналитик, проанализируй мне эту задачу” - говорит бизнес-заказчик. Что он имеет в виду? Анализ - это всего лишь  метод исследования, характеризующийся выделением и изучением отдельных частей объектов исследования (по википедии), но бизнес в своих словах подразумевает нечто большее, чем просто анализ.

Что делает ИТ-аналитик и в чем ценность его работы для бизнеса? Пробуем разобраться. 

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

Забегает молодой парень в больницу:
— Доктор, сделайте мне кастрацию, срочно!
— ???
— Срочно, доктор, некогда объяснять!
Доктор делает кастрацию. Наутро парень приходит в себя от наркоза, его спрашивают, в чем дело, собственно?
— Понимаете, я собираюсь жениться на еврейке, у них так принято по религии.
— Так может быть Вам нужно было обрезание?
— А я что сказал?!!!