Два понимания требований

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

1. Требования (requirements) – это часть определения системы, определяющая систему как «чёрный ящик», т.е. что делает система по отношению к её системному окружению, без описания внутренней структуры системы, происходящих внутри системы взаимодействий частей системы. Прежде всего тут важно поведение системы, выполнение ей своего назначения, функции в использующей системе. Поэтому основные требования называют функциональными требованиями. Нефункциональных требований не бывает, хотя в литературе этот термин регулярно встречается, но он считается некорректным: все требования описывают какое-то поведение системы, ожидания этого поведения. Но речь не всегда идёт о поведении в использующей системе. Требования качества в отличие от функциональных, относятся прежде всего к поведению в обеспечивающих системах, в том числе обслуживающих уже готовую систему: по-английски их иногда называют – ilities (reliability, accessability и т.п.), а по-русски – ости (надёжность, доступность, и т.п.).

Требования отличают от потребностей (stakeholder needs, stakeholder requirments) как требований внешних стейкхолдеров к использующей системе. Если мы выходим за пределы инженерии, то у требований могут быть другие имена. Например, для организаций речь может идти о стратегии – но суть тут будет та же самая: описание того, что хотелось бы получить от организации. Требования, взятые вместе со временем их выполнения, называют контрольными точками (milestone). Если требование – это «помидор красный», то «помидор красный, 10 мартобря 2019 года» будет контрольной точкой. Очень часто на контроле стоят не сами требования, а контрольные точки: «дорога ложка к обеду».

2. Альтернативное понимание требования уже не имеет отношения к системному подходу, не связано с границами системы. Это просто любое утверждение, данное в деонтической модальности. Любое высказывание из описания системы (например, «X=10») невозможно как-то понять по отношению к деятельности без указания на модальность (modality)134: то, как нужно понимать значения высказывания. Скажем, «в системе [существует] X=10» это алетическая (aletic) модальность, модальность существования. «Я верю, что в системе X=10» – это модальность доксическая (doxastic), веры. Деонтическая (deontic) модальность говорит о долженствовании, разрешении, рекомендации135: «Я требую, чтобы X=10». В этом втором понимании требований можно потребовать что угодно – и оно станет требованием, даже если речь идёт не о чёрном ящике. Например, «в автомобиле должен быть корпус из углепластика», «в смартфоне должны быть использованы отечественные микропроцессоры» относятся к «прозрачному ящику», но слова «должен» и «должны» указывают на деонтическую модальность.

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