Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
23 марта 2016 Из жизни РМа Переводы, рецензии, отзывы
100 0

Как писать хорошие спецификации на ПО

Юлия Бажанова
Редактор проекта, РМР, РМЕ, PRIME

Наткнулась тут на хабре на прекрасную статью о написании спецификаций в проектах разработки ПО.

Написано отлично, даже добавить нечего.

Отдельно стоит упомянуть комментарии в статье, там тоже много интересного.

Особенно понравился этот коммент:

Отличная статья. У меня в свое время хорошо прижился такой формат спеков:

1. Рассказ о том, что за проблема. Текст на абзац в свободном стиле.

2. Как сделать. Прояснение тех. деталей для разработчиков, желательно пошагово.

3. Как проверить. Прояснение тех моментов, которые будут тестироваться. Краткий сценарий тестирования.

Итоговая история смотрится примерно так (условно набросал сейчас):

Нашим пользователям очень неудобно создавать новые задачи. Создать задачу им может прийти в голову в любой момент, а сейчас это можно сделать только из определенного меню. Нужно сделать так, чтобы это было возможно из любого экрана программы.

Для этого необходимо:

— Создать на экране кнопку [рисунок], которая будет вести на карточку создания задачи.
— Некоторые поля там будут предзаполнены, например пользователь создал карточку из экрана клиента или сделки. [список экранов и типов предзаполнения]
— В некоторых ситуациях создать задачу нельзя. Например, нет прав. В этом случае показывать кнопку в неактивном состоянии.

Как проверить:

— На всех страницах есть кнопка создания задачи.

— По клике на кнопке на новом экране открывается карточка задачи, некоторые поля предзаполняются. Карточка задачи работает в полном объеме, предзаполненые поля можно отредактировать.

— Если у пользователя такие-то права, то задачу создать нельзя, кнопка неактивна.

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

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

Отлично, как считаете?

комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: