Software requirements & Separation of concerns
Часто замечаю, что многие разработчики функциональных требований не обладают функциональным мышлением, и как следствие, функциональные требования функциональнымы по сути и не являются.

В частности, вместо описания состояний, в которых может находится система, нужно описывать действия, которые с ней производит пользователь, например: требование «пользователь может быть авторизованным или неавторизованным» правильнее формулировать, например, так: «система проверяет введенный пользователем пароль, и в случае успешного результата пользователь сможет выполнять такие-то действия». (У меня где-то был более подробный разбор проблемы на примере из реального техзадания. Если кому-то будет интересно, то я опубликую его в следующих сериях).

Мне это казалось интуитивно понятным, и недавно я обнаружил похожую более обобщенную идею Separation of Concerns в авторитетных источниках:

The programmer is having to do several things at the same time, namely, 1. describe what is to be computed; 2. organise the computation sequencing into small steps; 3. organise memory management during the computation.

Ideally, the programmer should be able to concentrate on the first of the three tasks (describing what is to be computed) without being distracted by the other two, more administrative, tasks. Clearly, administration is important but by separating it from the main task we are likely to get more reliable results and we can ease the programming problem by automating much of the administration. The separation of concerns has other advantages as well. For example, program proving becomes much more feasible when details of sequencing and memory management are absent from the program. Furthermore, descriptions of what is to be computed should be free of such detailed step-by-step descriptions of how to do it if they are to be evaluated with different machine architectures. Sequences of small changes to a data object held in a store may be an inappropriate description of how to compute something when a highly parallel machine is being used with thousands of processors distributed throughout the machine and local rather than global storage facilities. Automating the administrative aspects means that the language implementor has to deal with them, but he/she has far more opportunity to make use of very different computation mechanisms with different machine architectures.

Chris Reade, Elements of Functional Programming, 1989

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

Но все-таки в первую очередь разработчик должен думать не только о том, что должна делать система, а о том, зачем, с какой целью она это будет делать. Это другой не менее важный concern, о котором советовал задумываться еще в 1974 году небезызвестный Дейкстра:

In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained ­— on the contrary! — by tackling these various aspects simultaneously.

Dijkstra, Edsger W., On the role of scientific thought

В этом состоит вторая простая и очевидная идея: описание целей и задач как неотъемлемых артефактов software requirements нужно всегда выделять в два отдельных документа.