2. Истории пользователя

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

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

При написании историй рекомендуется придерживаться следующей структуры:

как <пользователь>, я могу <действие>, для того, чтобы <цель>, где

• пользователь ‑ одна из обобщенный пользовательских ролей;

• действие ‑ действие, выполняемое пользователем посредством взаимодействия с системой;

• цель ‑ конечная цель текущей задачи, выполняемой пользователем посредством взаимодействия с системой.

Примеры

1. Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям.

2. Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей.

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

4. Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.

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

2. Разработка интерфейса пользователя

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

3. Реализация базовой функциональности

Функциональность программного продукта должна быть реализована на одном из выбранных языков программирования и выбранной технологии. Для реализации рекомендуются следующие языки: С/С++, Java, C#.

4. Тестирование программного продукта

В ходе выполнения курсовой работы, студент должен разработать и согласовать с заказчиком набор приемочных тестов. Результаты приемочного тестирования должны быть отражены в пояснительной записке.

1. Тестирование в классической модели разработки

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

Пример

Название: Тест отправки комментария

Функция: Контакт-Вопросы

Предусловие

(a) Действия:

i. Открыть сайт.

ii. Перейти по ссылке.

(b) Ожидаемый результат:

i. Сайт открыт и доступен.

ii. Страница открыта и доступна.

Шаги теста

(a) Действия:

i. Заполните форму отправки комментария.

(b) Ожидаемый результат:

i. Данные успешно введены.

Постусловие

(a) Действия:

i. Перейти по ссылке “назад”

(b) Ожидаемый результат:

i. Страница открыта.

В приложении 2 приведен шаблон оформления сценария тестирования.