Хорошие и плохие требования
Требования — основа любого проекта. Если они собраны плохо, система не будет соответствовать ожиданиям заказчика. Но что такое «плохо», а что «хорошо»? Существует ряд критериев, которым должны соответствовать требования: атомарность, полнота, корректность, недвусмысленность и др.
Теорию смотрите в картинках, а пример плохого требования ниже 👇
📌 Пример:
Система должна предоставлять возможность выбрать блюда и добавить дополнительные опции.
Почему это требование плохое?
* Полнота. Из требования не понятно, какие блюда можно выбрать? Куда они добавляются? Есть ли категории блюд со своими параметрами?
* Корректность. Как реализовать выбор блюд? Как это требование вписывается в полный процесс оформления заказа из ресторана? Всё это нужно, чтобы добавить блюда в корзину, нужно дописать это в требование.
* Недвусмысленность. Что подразумевается под «дополнительными опциями»? Это могут быть ингредиенты, способы оплаты, ввод промокода или что-то другое. Разработчики, тестировщики и заказчики могут по-разному понять это требование. Конкретизируйте, что такое «дополнительные опции»?
Перепишем требование:
Система должна предоставлять возможность выбрать блюда из категорий (салаты, основные блюда, десерты), с возможностью добавления ингредиентов к ним (соусы, специи), выбора количества порций и последующего добавления в корзину.
Уже лучше? 🤔
Да, но оно всё ещё не соответствует критерию атомарности.
Давайте разобьём требование на несколько и добавим каждому уникальный идентификатор, чтобы требование стало отслеживаемым:
* FR1 Система должна предоставлять возможность выбрать блюда из категорий (салаты, основные блюда, десерты) и автоматически добавлять их в корзину
* FR2 Система должна предоставлять возможность добавить ингредиенты (соусы, специи) к выбранным блюдам при их добавлении в корзину
* FR3 Система должна предоставлять возможность выбрать количество порций для каждого блюда как на этапе выбора в каталоге, так и при редактировании в корзине — это требование тоже можно разбить на два: 1) изменение количества порций в каталоге и 2) изменение количества порций уже в корзине.
Требования — основа любого проекта. Если они собраны плохо, система не будет соответствовать ожиданиям заказчика. Но что такое «плохо», а что «хорошо»? Существует ряд критериев, которым должны соответствовать требования: атомарность, полнота, корректность, недвусмысленность и др.
Теорию смотрите в картинках, а пример плохого требования ниже 👇
📌 Пример:
Система должна предоставлять возможность выбрать блюда и добавить дополнительные опции.
Почему это требование плохое?
* Полнота. Из требования не понятно, какие блюда можно выбрать? Куда они добавляются? Есть ли категории блюд со своими параметрами?
* Корректность. Как реализовать выбор блюд? Как это требование вписывается в полный процесс оформления заказа из ресторана? Всё это нужно, чтобы добавить блюда в корзину, нужно дописать это в требование.
* Недвусмысленность. Что подразумевается под «дополнительными опциями»? Это могут быть ингредиенты, способы оплаты, ввод промокода или что-то другое. Разработчики, тестировщики и заказчики могут по-разному понять это требование. Конкретизируйте, что такое «дополнительные опции»?
Перепишем требование:
Система должна предоставлять возможность выбрать блюда из категорий (салаты, основные блюда, десерты), с возможностью добавления ингредиентов к ним (соусы, специи), выбора количества порций и последующего добавления в корзину.
Уже лучше? 🤔
Да, но оно всё ещё не соответствует критерию атомарности.
Давайте разобьём требование на несколько и добавим каждому уникальный идентификатор, чтобы требование стало отслеживаемым:
* FR1 Система должна предоставлять возможность выбрать блюда из категорий (салаты, основные блюда, десерты) и автоматически добавлять их в корзину
* FR2 Система должна предоставлять возможность добавить ингредиенты (соусы, специи) к выбранным блюдам при их добавлении в корзину
* FR3 Система должна предоставлять возможность выбрать количество порций для каждого блюда как на этапе выбора в каталоге, так и при редактировании в корзине — это требование тоже можно разбить на два: 1) изменение количества порций в каталоге и 2) изменение количества порций уже в корзине.
👍14🔥6❤🔥3💯2
Вебинару быть! Системный аналитик — кто это и как им стать?
Не пропустите наш открытый вебинар, который состоится 12 сентября! Это отличный шанс узнать больше о профессии системного аналитика и сделать первые шаги в IT!
12 сентября в 19:00 МСК
❌ Записи не будет
Что вас ждёт:
🔍 Кто такой системный аналитик и чем он занимается?
🚀 Как начать карьеру с нуля или развиваться дальше, если вы уже с небольшим опытом?
🛠️ Какие навыки нужны для работы? В том числе мы расскажем, как эти навыки можно развить с помощью нашего курса AnalystCore.
И ещё много интересного!
🎁 И самое главное — на вебинаре будет уникальное предложение только для участников!
Регистрация бесплатна. Переходите по ссылке прямо сейчас и занимайте место на вебинаре. Ждём вас! Будет интересно!
Зарегистрироваться
https://forms.gle/BoRk81vPWHJUjn4U9
Не пропустите наш открытый вебинар, который состоится 12 сентября! Это отличный шанс узнать больше о профессии системного аналитика и сделать первые шаги в IT!
12 сентября в 19:00 МСК
❌ Записи не будет
Что вас ждёт:
🔍 Кто такой системный аналитик и чем он занимается?
🚀 Как начать карьеру с нуля или развиваться дальше, если вы уже с небольшим опытом?
🛠️ Какие навыки нужны для работы? В том числе мы расскажем, как эти навыки можно развить с помощью нашего курса AnalystCore.
И ещё много интересного!
🎁 И самое главное — на вебинаре будет уникальное предложение только для участников!
Регистрация бесплатна. Переходите по ссылке прямо сейчас и занимайте место на вебинаре. Ждём вас! Будет интересно!
Зарегистрироваться
https://forms.gle/BoRk81vPWHJUjn4U9
🔥10👍6🎉3👏1
Документация в IT
Системный аналитик ведёт документацию по продукту, и это занимает значительную часть работы. Мы вносим изменения, обновляем информацию и следим за тем, чтобы описание системы было актуальным. В разных компаниях документацию ведут по-разному. Где-то это обычный вордовский файл 📄, где-то гугл-документ, но чаще всего используют специальные системы, такие как Confluence.
В Confluence у каждой команды есть своё пространство, где описаны все детали работы продукта. Каждая страница — это отдельная часть: на одной странице описан юз кейс, на другой — структура базы данных, в отдельном разделе — экраны приложения. И что удобно, все страницы связаны между собой ссылками 🔗, как в Википедии. Например, из описания экрана приложения можно сразу перейти к соответствующему юз кейсу.
Документация помогает команде понять, как система работает сейчас. А если вы описываете в Confluence и технические задания, то тогда документация показывает и что нужно сделать.
Системный аналитик ведёт документацию по продукту, и это занимает значительную часть работы. Мы вносим изменения, обновляем информацию и следим за тем, чтобы описание системы было актуальным. В разных компаниях документацию ведут по-разному. Где-то это обычный вордовский файл 📄, где-то гугл-документ, но чаще всего используют специальные системы, такие как Confluence.
В Confluence у каждой команды есть своё пространство, где описаны все детали работы продукта. Каждая страница — это отдельная часть: на одной странице описан юз кейс, на другой — структура базы данных, в отдельном разделе — экраны приложения. И что удобно, все страницы связаны между собой ссылками 🔗, как в Википедии. Например, из описания экрана приложения можно сразу перейти к соответствующему юз кейсу.
Документация помогает команде понять, как система работает сейчас. А если вы описываете в Confluence и технические задания, то тогда документация показывает и что нужно сделать.
👍10🔥3👏3
Вебинар уже сегодня! 🕖
Уже сегодня в 19:00 МСК пройдёт наш открытый вебинар «Системный аналитик: кто это и как им стать?» 🚀
12 сентября в 19:00 МСК
❌ Записи не будет
Это ваш шанс узнать больше о профессии системного аналитика, получить полезные советы и увидеть, как можно начать карьеру в IT.
Что вас ждёт:
* Кто такой системный аналитик и чем он занимается?
* Как начать карьеру с нуля или развиваться дальше?
* Какие навыки нужны для работы, и как их развить?
🎁 Специальное предложение, доступное только для участников вебинара!
Переходите по ссылке прямо сейчас и занимайте место на вебинаре!
https://forms.gle/BoRk81vPWHJUjn4U9
Уже сегодня в 19:00 МСК пройдёт наш открытый вебинар «Системный аналитик: кто это и как им стать?» 🚀
12 сентября в 19:00 МСК
❌ Записи не будет
Это ваш шанс узнать больше о профессии системного аналитика, получить полезные советы и увидеть, как можно начать карьеру в IT.
Что вас ждёт:
* Кто такой системный аналитик и чем он занимается?
* Как начать карьеру с нуля или развиваться дальше?
* Какие навыки нужны для работы, и как их развить?
🎁 Специальное предложение, доступное только для участников вебинара!
Переходите по ссылке прямо сейчас и занимайте место на вебинаре!
https://forms.gle/BoRk81vPWHJUjn4U9
🔥4❤3👏3
Мы начинаем! 🕖
Системный аналитик: кто это и как им стать? 🚀
❌ Записи не будет
Ссылка на вебинар: https://pruffme.com/landing/u4395866/12092024
Системный аналитик: кто это и как им стать? 🚀
❌ Записи не будет
Ссылка на вебинар: https://pruffme.com/landing/u4395866/12092024
👍7
Как СА применяет скилы по БД? Зачем знать SQL?
Это вопросы от нашего подписчика. Думаю, тема для многих актуальна, поэтому давайте разбираться.
* Первое, мы проектируем модель данных. Это требуется на новых проектах или изменении функциональности, которая затрагивает структуру БД. Нужно понимать, как выделять сущности, атрибуты, связи, а также нормализовать данные. Знание SQL также помогает нам лучше понять, как данные хранить, чтобы их проще было извлекать, обновлять, удалять. Пример влияния SQL на модель данных см. в картинках👆.
* Второе — разбор инцидентов. Допустим, клиент жалуется, что не видит раздел «Премиум-контент». Пишем SQL-запрос и узнаем, что у клиента тариф Base, а доступ к разделу есть только на Premium. Вот и ответ.
* Ещё нас могут попросить выгрузить данные из БД для отчётов. Важно понимать, как работают SELECT, JOIN, агрегатные функции и другие базовые операторы.
* И ещё один кейс: иногда нужно тестировать. С помощью SQL можно создавать записи напрямую в БД.
#questions
Это вопросы от нашего подписчика. Думаю, тема для многих актуальна, поэтому давайте разбираться.
* Первое, мы проектируем модель данных. Это требуется на новых проектах или изменении функциональности, которая затрагивает структуру БД. Нужно понимать, как выделять сущности, атрибуты, связи, а также нормализовать данные. Знание SQL также помогает нам лучше понять, как данные хранить, чтобы их проще было извлекать, обновлять, удалять. Пример влияния SQL на модель данных см. в картинках👆.
* Второе — разбор инцидентов. Допустим, клиент жалуется, что не видит раздел «Премиум-контент». Пишем SQL-запрос и узнаем, что у клиента тариф Base, а доступ к разделу есть только на Premium. Вот и ответ.
* Ещё нас могут попросить выгрузить данные из БД для отчётов. Важно понимать, как работают SELECT, JOIN, агрегатные функции и другие базовые операторы.
* И ещё один кейс: иногда нужно тестировать. С помощью SQL можно создавать записи напрямую в БД.
#questions
👍10🔥3💯2
Подборка книг 📘
Книги, которые помогут собирать и документировать требования, общаться с заказчиком и рисовать диаграммы.
1. Разработка требований к программному обеспечению — Карл Вигерс, Джой Битти
Это — библия. Чтиво не из лёгких, но прочитать нужно. Пособие, проверенное временем!
2. Не заставляйте меня думать — Стив Круг
Книга хорошо подходит для отдыха от Вигерса 😂 О юзабилити простым языком. Примеры в книге устарели, но основные принципы хороши.
3. Современные методы описания функциональных требований к системам — Алистер Коберн
Книга о Use Cases, хорошая теория. За актуальными и понятными примерами приглашаем на наш курс, составляли их на основе своего опыта — analystcore.com🚀
4. UML. Основы — Мартин Фаулер
Научит вас визуализировать системы и процессы на UML.
5. Спроси маму — Роб Фитцпатрик
Научит задавать правильные вопросы.
6. Пиши, сокращай — Максим Ильяхов, Людмила Сарычева
Как писать понятно и чётко. Пригодится при документировании.
Книги, которые помогут собирать и документировать требования, общаться с заказчиком и рисовать диаграммы.
1. Разработка требований к программному обеспечению — Карл Вигерс, Джой Битти
Это — библия. Чтиво не из лёгких, но прочитать нужно. Пособие, проверенное временем!
2. Не заставляйте меня думать — Стив Круг
Книга хорошо подходит для отдыха от Вигерса 😂 О юзабилити простым языком. Примеры в книге устарели, но основные принципы хороши.
3. Современные методы описания функциональных требований к системам — Алистер Коберн
Книга о Use Cases, хорошая теория. За актуальными и понятными примерами приглашаем на наш курс, составляли их на основе своего опыта — analystcore.com🚀
4. UML. Основы — Мартин Фаулер
Научит вас визуализировать системы и процессы на UML.
5. Спроси маму — Роб Фитцпатрик
Научит задавать правильные вопросы.
6. Пиши, сокращай — Максим Ильяхов, Людмила Сарычева
Как писать понятно и чётко. Пригодится при документировании.
👍10🔥7❤2💯1