Я также посмотрел “западные”источники. Получилось, что смыслы те же… — SA LEAD — TG.ME

SA LEADВсем привет! Я недавно участвовал в достаточно крупном чемпионате по системному анализу. В тройку победителей не попал (только 15-е место), но пообщался с классными ребятами, и посмотрел, как они пишут ТЗ или TDD (Technical Design Document) на разработку ИТ…
Я также посмотрел “западные”источники. Получилось, что смыслы те же, но структура попроще (без глубокого разбиения).
Очень обобщенно (выделив общие положения) могу дать еще такой шаблон:

Introduction: Обзор всего документа
System Overview: Общее описание и функциональные возможности программной системы
Design Considerations: Проблемы, которые необходимо решить перед созданием проектного решения:
- Предположения и зависимости
- Общие ограничения (все, что может повлиять на разработку ПО)
- Цели и рекомендации
- Методы разработки (для использования)
Architectural Strategies: Архитектурные стратегии, которые будут использоваться.
System Architecture: Общий обзор того, как функциональность и зоны ответственности системы были разделены, а затем распределены по подсистемам или компонентам.
Policies and Tactics: Любые политики и/или тактики проектирования, которые не имеют серьезных архитектурных последствий (то есть они не окажут существенного влияния на общую организацию системы и ее структуры высокого уровня).
Detailed System Design: Большинство компонентов, описанных в разделе «Архитектура системы», требуют более детального обсуждения. Возможно, потребуется описать и другие компоненты и подкомпоненты более низкого уровня.
Alternatives: Любые альтернативные решения в части дизайна + сравнительная таблица по критериям.
Glossary: Упорядоченный список определенных терминов и понятий, используемых в документе.

🔥Но ключевая прелесть подхода в том, что фокус прежде всего на Problem-solving. И никто кажется не заморачивается с тем, чтобы разложить это все по 100500 типам требований по Вигерсу и прочим классификациям. Безусловно это важно, но для
- самоконтроля, чтобы не забыть их многообразие на этапе сбора требований (если говорить о НФТ)
- для понимания связей и иерархии, чтобы случайно не сделать ложную подмену (если говорить о функциональных типах - бизнес, пользовательские, функциональные)
- для того, чтобы пройти собес.😄

Держите также другие вариации шаблонов и связанные с ними статьи.

Шаблоны:
🎯https://github.com/tensorflow/community/blob/master/rfcs/yyyymmdd-rfc-template.md
🎯https://terragrunt.gruntwork.io/docs/rfc/template/
🎯https://wiki.en.it-processmaps.com/index.php/Checklist_Request_for_Change_RFC
🎯https://gist.github.com/michaelcurry/e0132058fcd6d588a1299afd69638df4
🎯https://docs.google.com/document/d/1sUX-sm5qZ474PCQQUpvdi3lvvmWPluqHOyfXz3xKL2M/edit#heading=h.554u12gw2xpd

HowTo:
🎯https://www.industrialempathy.com/posts/design-docs-at-google/
🎯https://basecamp.com/shapeup/1.5-chapter-06#examples
🎯https://www.freecodecamp.org/news/how-to-write-a-good-software-design-document-66fcf019569c/
🎯https://medium.com/machine-words/writing-technical-design-docs-71f446e42f2e
GitHub
community/rfcs/yyyymmdd-rfc-template.md at master · tensorflow/community
Stores documents used by the TensorFlow developer community - tensorflow/community
❤5❤‍🔥2🥰2
May 28, 2024 623 18