Чтобы что - это что ? Как не быть попугаем-продактом? Как понимать, что является обоснованием функциональных требований, а что нет (с примерами) ? Читайте лонгрид автора - https://habr.com/ru/post/697444/
Хабр
Что есть обоснование функциональных требований (или что такое «Чтобы что»)
Вводная или почему этот вопрос важен Входящую задачу нужно проанализировать и спроектировать решение и это делает аналитик, затем программист ее программирует, тестировщик тестирует. Но если в...
👍1
Какая цель проекта "внедрения ИТ системы". Что это такое? Делитесь своими соображениями. (У меня есть свое представление о цели, я обязательно включусь в обсуждение)
За мной есть старый должок. Есть несколько эффектов возникающих при процессе проектирования, которые следуют из того, что обоснование детальных требований не есть недетальное требование. Я собрал их в статью, жду ваших комментов - https://docs.google.com/document/d/1wN527zpoRo4EONNDJqx_t_bwigDfCWsD5g7FQJT6jqs/edit?usp=sharing
Google Docs
u-принцип
Проявление детальных требований и потребностей при моделировании Для тех, кто рецензирует Если кто раньше сталкивался с описанными эффектами, дайте плиз ссылки. Вводная Как детализировать требования? Есть техника user story mapping: соберите пользователей…
Вчера на обучении по интеграциям с аналитиками разбирали задачу интеграцию с интернет-эквайером ЮMoney. И этот интернет-эквайер не сделал простую и удобную интеграцию по получению статуса платежа (кстати опишите в комментах как вы думаете какая самая оптимальная, вот интересно). Чесслово, эти интернет-эквайеры копируют неверное решение один у другого и думают, что это правильный метод проектирования?
Статья готова - https://habr.com/ru/post/706956/
Хабр
u-принцип и проявление детальных требований и потребностей ИТ-системы
Статья отражает как в общем случае прорабатывать детальные требования, откуда брать их обоснования (и почему OpenAI не может создать детальные требования). Дается ответ на вопрос: почему важно строить...
Прочитал книгу "Системная инженерия 2022" (Большое спасибо Анатолию Левенчуку за книгу). В книге дан широкий обзор современных мировых методик и практик системного анализа и инженерии. Здорово, что фокус сместился от разработки требований к разработке и проверке моделей решения (как я и писал в статьях и рассказывал в докладах - заказчику не нужны требования, ему нужна оптимальная модель решения его задачи). И вообще, я склоняюсь к тому, что содержательных требований не существует, на самом деле это части описания моделей использования и весь процесс проектирования состоит из дизайна моделей, преобразования одних моделей в другие под новый viewpoint с получением доп информации для замыкания новых моделей и применения приема обобщения плюс выработка viewpoint и моделей использования для проверки решения.
Проверил Postgre. Как и ожидалось, NULL занимает меньше места при хранении. Сделал две таблички. Каждая две колонки. Первая - число. Вторая - boolean. 17 млн строк. Во второй табличке хранятся числа и NULL. Тест 1: храним в первой табличке какое-то число и false. Занимает столько же места сколько и вторая. Тест 2. храним в первой табличке какое-то число и true. Таблица занимает в 2 раза больше места. Вывод - делайте булевы столбцы так, чтобы основной массе там был NULL или false.
🔥1
Читаю ISO 29148 (руки дошли). Иногда хочется выразится матом. Вот я и выражусь. Требование (Requirement) должно быть проверяемым, точным и т.п. Но как говорил Пендальф - "в далеком светлом будущем, а пока мочи всех направо и налево (с)". Проектирование состоит из принятия решений о том "как" и в процессе проектирование детализируется "что". Модель решения включает в себя какой то замысел. Замысел должен излагаться, связывая не более 10-20 обьектов мышления, иначе другой человек не поймет. Замысел создает требования. А значит пока не дошли до планирования деталей реализации, не может быть "проверяемым, точным, сравнительным, реализуемым и пр.". Хотя может быть я не дошел до нужного места.... а вы как считаете?
А давайте порассуждаем - на какой вопрос отвечает "центральная часть" технического задания ?
Forwarded from Events on Business/Systems Analysis/Design (Ilya Boborykin)
Во вторник 21 февраля в 18:00 пройдет бесплатный открытый вебинар, где тема технического задания будет рассмотрена с точки зрения системной инженерии. Спикером выступит Евгений Скориков: Lead аналитик, проектировщик, ведущий тренингов и автор статей.
Вебинар будет полезен:
— проектировщикам ИТ-систем,
— системным аналитикам,
— руководителям проектов.
О чем поговорим:
— Почему важна обоснованность моделей ИТ-системы
— Как обнаружить необоснованные решения в функциональных моделях системы?
— Откуда должно браться обоснование этих решений?
— Какова структура, связывающая функциональные модели, их обоснования и модели использования?
Ответим на вопросы участников вебинара в прямом эфире.
Спикером выступит Евгений Скориков:
— Enterprise архитектор и lead ИТ-аналитик в веб-интеграторе AWG
— Проектировщик ИТ-архитектур от уровня всего бизнеса до формирования ТЗ на разработку конкретных систем
— Создатель воркшопа «Техника усиления User Story» в Systems Education
Видеозапись вебинара будет доступна на нашем Youtube канале.
Регистрируйтесь на вебинар👈
Вебинар будет полезен:
— проектировщикам ИТ-систем,
— системным аналитикам,
— руководителям проектов.
О чем поговорим:
— Почему важна обоснованность моделей ИТ-системы
— Как обнаружить необоснованные решения в функциональных моделях системы?
— Откуда должно браться обоснование этих решений?
— Какова структура, связывающая функциональные модели, их обоснования и модели использования?
Ответим на вопросы участников вебинара в прямом эфире.
Спикером выступит Евгений Скориков:
— Enterprise архитектор и lead ИТ-аналитик в веб-интеграторе AWG
— Проектировщик ИТ-архитектур от уровня всего бизнеса до формирования ТЗ на разработку конкретных систем
— Создатель воркшопа «Техника усиления User Story» в Systems Education
Видеозапись вебинара будет доступна на нашем Youtube канале.
Регистрируйтесь на вебинар👈
🔥3
Евгений Скориков. Размышления про IT-аналитиз и проектирование
Проверил Postgre. Как и ожидалось, NULL занимает меньше места при хранении. Сделал две таблички. Каждая две колонки. Первая - число. Вторая - boolean. 17 млн строк. Во второй табличке хранятся числа и NULL. Тест 1: храним в первой табличке какое-то число и…
Итого, посмотрел стоимость на Яндекс.Облаке.1 Гб SSD = 11.91 руб/мес. Значит на одном поле таблицы с 17 млн записями экономия - 0.62Гб = 7.4 рубля / мес. Экономия на 10 млн записей = 4.37 руб / мес. Вобщем на одной таблице, на одном поле смысла экономить нет. Если есть 10 полей в таблицах, на обьеме в 100 млн строк, экономия 4 366 руб. В общем теперь есть ориентиры для принятия решений.
👍1
Но это только за боевую базу. Если добавить стоимость бакапов, то цена немного вырастет (три копии на HDD, которые сжатые и цена хранения на HDD меньше в 4 раза) - получается еще где-то на 25% выше (то есть получается 5 458 руб)
У вас в ТЗ есть дыры? А если найду ? Вот эту штуку я наблюдаю почти в каждом ТЗ, к сожалению, shift left нервно мнется в сторонке. Подробнее - в видео https://www.youtube.com/watch?v=M1dW3FE-C2o
YouTube
Ваше ТЗ бездоказательно, профессор! Как системному аналитику обосновать требования. Евгений Скориков
Как системному аналитику обосновать требования? Воркшоп «Техника усиления User Story» https://systems.education/userstory-workshop?utm_source=youtube&utm_medium=userstory-workshop&utm_campaign=systems_education&utm_content=ib-workshop_announ&utm_term=ho…
Два года назад в рамках проработки ИТ архитектуры одного ритейлера я предложил им определенный потребительский сегмент, который я делал в рамках курса создания обучения (чисто для демонстрации как меняется восприятие продукта в JTBD). Сейчас (я снова делаю ИТ стратегию для них), я вижу это в стратегии компании. Приятно ...
🔥4👍1
Буду выступать на ЛАФ 2023, спасибо организаторам !!! Тема - "НФТ - не НФТ". А вы знали, что почти бесполезно (а иногда вредно) писать требования качества в виде "система должна быть работоспособной в 99.5%", если при этом не прорабатывать модели "а как"
Anonymous Poll
0%
А зачем думать "как"?
57%
Что такое 99.5% вообще
29%
Да, проработка "как" дает правильный вопрос "а что требуется" и только так. Всегда так делаю
14%
Вообще это не задача аналитика, пусть другие думают
Офтоп. Цитирую. Есть два типа менеджеров. Одни верят в чудеса, вторые в статистику. Уже 50 лет минимум как этой теории управления. Увы, первых больше. Сегодня еще раз убедился. Ощущение статистики "непроизводственных затрат" оказалась в пять раз ниже реальной статистики. Хотя все отчеты под руками... в течении двух лет так велась оценка... эх (брюзга ли я после этого?)
Скоро на ЛАФ. Как и в прошлом году, буду повторять доклад еще на каналах AWG и Системный подход
Forwarded from Anna Raikova
#ПК_ЛАФ
Всем привет ) До лета 2 дня, до ЛАФа - 10, а мы успеваем представлять вам докладчиков :)
Евгений Скориков
Enterprise-архитектор и ИТ-аналитик-lead в AWG. 20 лет опыта в ролях ИТ-аналитика, разработчика, тестировщика, руководителя проектов, руководителя департамента в автоматизации ритейла. Опыт проектирования ИТ архитектур от уровня всего бизнеса до формирования ТЗ для разработки конкретных систем.
МК «Нефункциональные требования? Модели обеспечения качества!»
Аналитикам говорят “пишите НФТ”, и они их “пишут”. Разработчики разрабатывают систему и внезапно оказывается, что система не удовлетворяет этим “НФТ” (если “НФТ” вообще возможно проверить). Проблема кроется в пропущенном этапе проектирования - для удовлетворения “НФТ” недостаточно их заявить, нужно придумать “как это обеспечить” - создать подходящую модель системы, сталкиваясь с задачами поиска компромисса между потерями от необеспечения и расходами на обеспечение. Более того, детальное понимание потребностей качества мы можем зафиксировать только после проработки детальной модели их обеспечения. При этом, при проработке может оказаться так, что придется менять уже созданные функциональные модели системы или прорабатывать дополнительные модели системы.
На примерах разберем, как при разработке систем формулировать качественные НФТ в разрезе отказоустойчивости, производительности и быстродействия.
Всем привет ) До лета 2 дня, до ЛАФа - 10, а мы успеваем представлять вам докладчиков :)
Евгений Скориков
Enterprise-архитектор и ИТ-аналитик-lead в AWG. 20 лет опыта в ролях ИТ-аналитика, разработчика, тестировщика, руководителя проектов, руководителя департамента в автоматизации ритейла. Опыт проектирования ИТ архитектур от уровня всего бизнеса до формирования ТЗ для разработки конкретных систем.
МК «Нефункциональные требования? Модели обеспечения качества!»
Аналитикам говорят “пишите НФТ”, и они их “пишут”. Разработчики разрабатывают систему и внезапно оказывается, что система не удовлетворяет этим “НФТ” (если “НФТ” вообще возможно проверить). Проблема кроется в пропущенном этапе проектирования - для удовлетворения “НФТ” недостаточно их заявить, нужно придумать “как это обеспечить” - создать подходящую модель системы, сталкиваясь с задачами поиска компромисса между потерями от необеспечения и расходами на обеспечение. Более того, детальное понимание потребностей качества мы можем зафиксировать только после проработки детальной модели их обеспечения. При этом, при проработке может оказаться так, что придется менять уже созданные функциональные модели системы или прорабатывать дополнительные модели системы.
На примерах разберем, как при разработке систем формулировать качественные НФТ в разрезе отказоустойчивости, производительности и быстродействия.
👍2🔥2
Проработка НФТ (или более точно проектирование системы с точки зрения аспектов качества), (конкретно производительности) может влиять на функциональные модели реализации. Пример под руками: Если клиент может выбрать несколько любимых магазинов, то организовать триггерную рассылку клиенту, чтобы он получал рассылку в случае появления скидки в любом из своих любимых магазинов очень затратная штука если клиентов 10 млн, магазинов 5к, и товаров 5к в каждом. Проще и производительнее альтернатива - клиент выбирает один регион (0.5к) и получает рассылку при снижении цены хотя бы в одном магазине этого региона
🔥1