А когда начинающие системные аналитики начинают работать с постановкой задач на разработчиков, то у них как раз таки возникает ошибка с недостаточной степенью детализации требований.
Что стоит проверять?
✔️ Описали ли вы ограничения по доступности функциональности? Какие роли имеют к ней доступ?
✔️ Вы описали сущность в системе. Например "Заказ". Что с ней можно сделать? Прогнали CRUD-модель (create, read, update, delete), чтобы описать все бизнес- и функциональные требования?
✔️ Вы описываете Use Case (пользовательский сценарий).
- Вы проверили возможные альтернативные сценарии, которые могут быть на каждом из шагов?
- Для клиента - вы указали методы API, которые должны вызываться?
- Для сервера - вы указали откуда брать данные из БД?
✔️ При постановке задачи на дизайнера вы сообщили ему о том, что необходимо отрисовать состояния, когда на экране возникли ошибки или нужно поменять статус (состояние)?
✔️ При проектировании интеграций вы открыли Postman, чтобы убедиться в том, что внешняя система работает корректно в тесте и на продакшн, как вы ожидаете по документации?
✔️ Форма ввода данных. Где делать проверки введенных данных? На сервере перед сохранением в БД точно. А нужно ли дублировать какие-то проверки на клиенте? Как обрабатывать ошибки валидации? Подсвечивать поля красным?
✔️ Вы проектируете БД. В одном заказе может быть много товаров. Один товар может быть во многих заказах. Связь сущностей товар-заказ "многие-ко-многим". Вы поняли почему так? А знаете как избавиться от этой связи? 😉
Это, и даже больше, возможно разобрать и запомнить только на практике! Делайте скриншот, чтобы не потерять этот мини-чеклист 📷
Что стоит проверять?
✔️ Описали ли вы ограничения по доступности функциональности? Какие роли имеют к ней доступ?
✔️ Вы описали сущность в системе. Например "Заказ". Что с ней можно сделать? Прогнали CRUD-модель (create, read, update, delete), чтобы описать все бизнес- и функциональные требования?
✔️ Вы описываете Use Case (пользовательский сценарий).
- Вы проверили возможные альтернативные сценарии, которые могут быть на каждом из шагов?
- Для клиента - вы указали методы API, которые должны вызываться?
- Для сервера - вы указали откуда брать данные из БД?
✔️ При постановке задачи на дизайнера вы сообщили ему о том, что необходимо отрисовать состояния, когда на экране возникли ошибки или нужно поменять статус (состояние)?
✔️ При проектировании интеграций вы открыли Postman, чтобы убедиться в том, что внешняя система работает корректно в тесте и на продакшн, как вы ожидаете по документации?
✔️ Форма ввода данных. Где делать проверки введенных данных? На сервере перед сохранением в БД точно. А нужно ли дублировать какие-то проверки на клиенте? Как обрабатывать ошибки валидации? Подсвечивать поля красным?
✔️ Вы проектируете БД. В одном заказе может быть много товаров. Один товар может быть во многих заказах. Связь сущностей товар-заказ "многие-ко-многим". Вы поняли почему так? А знаете как избавиться от этой связи? 😉
Это, и даже больше, возможно разобрать и запомнить только на практике! Делайте скриншот, чтобы не потерять этот мини-чеклист 📷