Post #144

К вопросу про инженерные практики. Несомненно, одним из признаков инженерной деятельности, кроме справочников, являются стандарты. И по требованиям, конструированию и архитектурному проектированию систем стандарты как раз есть, и даже много. Причем не только ГОСТ 34 родом из 70-х, который только состав документов регламентирует (и который, вообще говоря, очень хорош, как чек-лист, если вы проектируете в целом систему, а не только ПО). Есть и более современные и интересные стандарты. Например, ГОСТ Р 59795-2021, заменяющий старый РД 50-34.698-90, в котором указано - что именно писать в разных документах, про которые рассказывает ГОСТ 34.201-2020 и, в частности, именно про документ Технического задания по ГОСТ 34.602-2020. Там, конечно, свой язык, и не всегда можно догадаться, что "Схема функциональной структуры" - это контекстная диаграмма + диаграмма контейнеров из модной C4model, "Ведомость покупных изделий" по сути является списком зависимостей, а "распределение действий между персоналом и техническими средствами при возникновении различных ситуаций при решении задачи (комплекса задач)" мы сейчас называем use case'ом. Но есть и более крутые стандарты! Например, горячо любимый мной ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. Меня часто спрашивают про книги, а я сам уже давно почти никаких книг не читаю, разве что по архитектуре (по ней пока мало стандартов). Я читаю стандарты и руководства, да ещё научные статьи. И по инженерии требований рекомендую в первую очередь ISO 29148 и Руководство по написанию требований от INCOSE. К сожалению, найти их в свободном доступе довольно сложно (если вы инженер, то вам компания этот стандарт купит за какие-то там жалкие 208 CHF). К счастью, пару недель назад Константин Валеев сделал прекрасный обзор этого стандарта на канале моего коллеги по Школе системного анализа и проектирования: https://www.youtube.com/live/H71XEhXBsHY Эти два документа - стандарт и руководство - единственные из известных мне говорят о том, как же, всё-таки, писать требования, а не просто о чём их писать. Какие формулировки использовать. Как управлять требованиями, какие у них есть атрибуты, и что писать в сами требования, а что в атрибуты. Как отличить качественные требования, и что вообще означает "качество" применительно к требованиям. На русский язык этот стандарт не переведен (в отличие от Руководства, которое, впрочем не так-то просто купить, хотя оно на русском как раз есть, я даже немного участвовал в его переводе). Зато на русском есть удивительный ГОСТ Р 59194―2020. Это стандарт представляет перевод некоторой части ISO 29148, касающуюся как раз формулировок и атрибутов требований (впервые на русском!). Например, там есть пункт "Каждое требование должно быть уникально идентифицировано для обеспечения прослеживаемости в ходе разработки. Уникальный идентификатор требования не изменяется в ходе ЖЦ объекта, в том числе при внесении изменений в требование.", что, по сравнению с ГОСТом 34 невероятный прогресс! (Ссылки на ГОСТы 34 серии там присутствуют, так что можно использовать их совместно, и перестать жаловаться на "морально устаревший" ГОСТ 34). Да что там, в этом стандарте даже есть разделение на исходные и проектные требования: "Для разрабатываемых объектов на основании утвержденной спецификации исходных требований разрабатывают спецификацию проектных требований, обусловленных принятыми при проектировании и в результате анализа исходных требований техническими решениями.", что совсем прекрасно! Та самая тема, о которой я давно говорю: как только вы принимаете какое-то техническое решение - например, "данные будут выводиться в виде таблицы" - тут же возникает целый куст новых требований, связанных с таблицей (перенос строк, отображение изображений и значков в ячейках таблицы, возможность сортировки и фильтрации, изменения ширины, скрытия и перестановки столбцов, и т.д. - требования, которые не возникли бы, если бы для вывода использовался другой способ).