Системный Аналитик
19.1K subscribers
95 photos
4 videos
50 files
276 links
Канал для системных аналитиков и не только: подборки полезных материалов на все случаи жизни.

Реклама и сотрудничество @radale

https://gosuslugi.ru/snet/67b0613c6411ff785396754a
Download Telegram
Статьи про User Stories

1. Как формировать User Stories
2. Подробный гайд по User Stories: критерии INVEST, AC, Job Stories, метод персон, типичные ошибки
3. Декомпозиция User Stories — паттерны, метод гамбургера, SPIDR

#требования
🔥8🤔1
Карл_Вигерс_и_Джой_Битти_Karl_Wiegers_and_Joy_Beatty_Разработка.pdf
3.1 MB
Библия для Системного аналитика, если у кого её ещё нет. Кому нужно на английском, дайте знать в комментах — найдём

#требования
🔥11🤔1
👍3🤔1
Бесплатный курс на Stepik Постановка задачи на разработку ПО при поддержке ВК

Курс формирует базовые навыки подготовки и документирования требований к программному обеспечению. По итогам курса вы научитесь: работать с требованиями и заинтересованными сторонами, анализировать проблему и формулировать требования, проектировать взаимодействие пользователей с системой, обеспечивать необходимые качества системы на этапе постановки задачи.

#курсы
🔥4👍3🤔1
Для высоконагруженных систем со множеством клиентов и высокими требованиями к производительности сервера, но неустойчивой сети лучше всего подойдет следующий API межсистемной интеграции
Anonymous Quiz
41%
REST
30%
gRPC
16%
GraphQL
13%
SOAP
👎1
Какие HTTP-методы всегда являются идемпотентными?
Anonymous Quiz
68%
GET, PUT и DELETE (с оговорками)
3%
PATCH
2%
DELETE
12%
только GET
3%
POST
12%
все (GET, POST, PUT, PATCH, DELETE)
👎1
SOAP использует только формат XML
Anonymous Quiz
84%
Верно
16%
Неверно
👎1
SOAP имеет встроенную обработку ошибок
Anonymous Quiz
62%
Верно
38%
Неверно
👎1
4 шага как «раскопать» систему

1️⃣ Собери всё, что есть
В идеале документация может должна содержать:
1. описание потребности в этой функциональности (просто текстом, таблички, какие-то схемы в любой нотации);
2. описание фронта: поведение элементов, workflow пользователя;
3. описание бэка: внутренние сервисы, описание бд и компонентов;
4. описание интеграционных сервисов, включая примеры запросов и ответов, статусы ответов.
5. Требования к функциональности
6. Запротоколированные договоренности, в которых можно проследить какие-то несделанные пожелания
7. Требования регулирующих органов (если влияют напрямую)
8. Руководство пользователя/инструкции


2️⃣ Протыкать ручками (если есть возможность). Просто садишься и начинаешь тыкать везде и смотреть как реагирует система. При этом фиксируешь поведение, а сомнительные моменты отмечаешь для уточнения у носителей неявных знаний

3️⃣ Задай вопросы
Выясняешь у начальника (линейного, руководителя проекта, лида и прочее — нужное подчеркнуть), кто может проконсультировать по вопросам. Готовишь список вопросов. Задаёшь, конспектируешь ответ. Идёшь пропускать все это через себя.

4️⃣ Оформи то, что получил
Оформляешь полученную информацию в установленном порядке в своей фирме. Это может быть актуализация документов, или формирование базы знаний в конфлюенсе, может быть даже обновление родительских тикетов в таск-трекере — в общем удобное для вас место.

Задача аналитика — оставить после себя структурированную информацию. Оставить — это значит оформить и выложить в общедоступное место. А не разобраться, как школьник с новыми знаниями, и оставить их при себе. Структурированная информация — это значит разложить по полочкам все то, что до тебя плохо лежало.

Оригинал

#требования
👍7🔥3❤1👎1🤔1
Чек-лист хороших требований

✅ Полнота. Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода? Чтобы проверить этот пункт, просто напишите чек-лист проверок функционала. Вот как начали читать ТЗ, сразу записывайте тесты. Важно именно писать, а не просто прикидывать в уме. Иначе что-то обязательно забудете.

✅ Однозначность. Требования должны трактоваться всеми одинаково.
Отчет должен загружаться быстро. Отчет за год должен загружаться не более секунды.

✅ Непротиворечивость. Требования не должны противоречить сами себе
Необходимость. Помните главный принцип: «Кратко, но емко». Пишите только то, что необходимо: функционал, основной сценарий и альтернативы, типы ошибок.

✅ Осуществимость. А можно ли реализовать то, что тут написано? Насколько это будет сложно и дорого?

✅ Тестируемость. Можно ли протестировать этот функционал? Подумайте об этом заранее. А то бывает так, что разработчик уже всё сделал, и тут только тестировщик понимает, что задачу никак нельзя проверить

✅ Атомарность. Не может быть разбито на ряд более детальных требований

Подробнее – см. свойства качественных требований

#требования
🔥8
Пиши_Сокращай_Как_составлять_сильный_текст.pdf
12.9 MB
Чётко и ясно излагать мысли — один из главных навыков системного аналитика. И этот навык можно прокачать. А помочь в этом может книга от создателей сервиса glvrd.ru «Пиши, сокращай» М. Ильяхова и Л. Сарычевой
👍7🤔1
Открытый курс по документированию API

Позволяет узнать:

1. стандарты, инструменты и спецификации REST API
2. необходимые разделы в документации API
3. как присоединиться к опен-сорс проекту для получения опыта
4. Как использовать Postman и составлять запросы curl
5. как составлять спецификацию OpenAPI и Swagger

#интеграции #api
👍9❤1🤔1
Как выбрать технологию для интеграции, реализовать и не сойти с ума — доклад с Analyst Days 15
Анастасии Воробьевой, интеграционного аналитика из Райфа

#интеграции #api #архитектура
🔥6