Системный Аналитик – Telegram
Системный Аналитик
18.6K subscribers
91 photos
4 videos
49 files
254 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
Бесплатный курс на Stepik Постановка задачи на разработку ПО при поддержке ВК

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

#курсы
🔥4👍3🤔1
Для высоконагруженных систем со множеством клиентов и высокими требованиями к производительности сервера, но неустойчивой сети лучше всего подойдет следующий API межсистемной интеграции
Anonymous Quiz
41%
REST
30%
gRPC
17%
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🔥31👎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
👍91🤔1