Рубрика «сбор требований»

Создаем свой проектный фреймворк автотестирования API [Часть 1-3] - 1

Артем

Head of QA

Читать полностью »

«Хорошо определённая проблема - это проблема наполовину решённая». Джон Дьюи.

Спойлер

Если в вашей практике на начальном этапе анализа проекта обозначаются все контексты и границы взаимодействия систем, то скорее всего у вас хорошо развита культура системного дизайна и данная статья для вас не имеет практического значения. В противном случае предлагаю уделить 5 минут вашего времени для ознакомления с материалом.

Общий сценарий

Читать полностью »

image

Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование.
https://ru.wikipedia.org/wiki/анализ_требований

Большинству уже интуитивно понятно, о чем идет речь, однако я еще не встречал людей, которые бы руководствовались интуицией в вопросах анализа требований и получили что-то годное к использованию.

Зачастую все заканчивается недописанной таблицей, составленной для галочки, живущей в отрыве от реального функционала системы.

На мой взгляд, для того чтобы избежать этой ситуации, надо всего-лишь посмотреть на процесс под другим углом… Читать полностью »

В статье ответим только на один вопрос – как мы решаем, что и когда реализовывать в платформе «1С:Предприятие».

Именно в такой формулировке нам его задают редко, но часто и даже очень часто появляются конкретные вопросы – «почему вы сделали это?», «почему вы НЕ сделали это?», «почему бы вам не сделать это?», «когда вы сделаете это?», «когда же вы, наконец, сделаете это?!!!», …

Попробуем описать то, как мы решаем, что когда делать.

Как мы решаем «что делать?» - 1
Читать полностью »

«Но я же хотела зеленое большое кислое яблоко» — стенала я, держа в руках маленькое яблочко с красным боком. «Ты сказала, чтобы я купил яблоко, я купил яблоко» — сурово отрезал муж.

image

В начале разработки клиенты всегда довольны, недовольными они становятся в конце, когда их ожидания не совпадают с тем, что разработано. Вроде бы говорили заказчик и менеджер разработки об одном, вроде употребляли умные слова вроде «план» и «риски», а не в восторге клиент от готового продукта. Как так?

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js