Рецепт работы с требованиями

Николай Войнов в своем отзыве о ReqLabs 2011еще 26 марта 2011 г. написал:

"Собственно все прошло довольно хорошо - активно, весело, иногда задиристо. Но ощущение осталось немного странное. От конференции обычно ожидаешь чего-то нового, неожиданного; структурируешь и по новому осознаешь некоторые известные темы; уходишь с новыми идеями. Но ничего из этого не случилось...

Вроде как и темы интересные, докладчики грамотные, и диалог состоялся. Но системности не было, выводы недостаточно четкие".

И привел для примера Рецепт работы с требованиями - завершающие главы из книги Принципы работы с требованиями к программному обеспечению. Унифицированный подход.(это Дин Леффингуэлл, Дон Уидриг).

Введение

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

Набор приемов Анализ проблемы

Необходимо понять решаемую проблему до начала разработки приложения. Предлагается использовать метод состоящий из пяти этапов. 1. Достигнуть соглашение по определению проблемы. 2. Выделить основные причины - проблемы, стоящие за проблемой. 3. Выявить заинтересованных лиц и пользователей, чье коллективное мнение в конечном итоге определяет успех или неудачу системы. 4. Определить, где приблизительно находятся границы решения. 5. Понять ограничения, которые будут наложены на команду и решение. Моделирование бизнес-процессов. Выявленные бизнес-прецеденты будут позднее применяться для определения требований к системе.

Понимание потребностей пользователя

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

• Интервьюирование и анкетирование

• Совещание, посвященное требованиям

• Мозговой штурм и отбор идей

• Создание раскадровок

• Прецеденты

• Обыгрывание ролей

• Создание прототипов

Определение системы

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

Управление масштабом

Проблема масштаба проекта является весьма типичной. Проекта инициируются с объемом функциональных возможностей, вдвое превышающим тот, который команда может реализовать, обеспечив приемлемое качество. Заказчики хотят большего, маркетинг хочет большего и также желаем большего. Тем не менее нужно ограничить объем, чтобы иметь возможность предоставить в срок хоть что-нибудь. Философия привлечения заказчика к процессу принятия трудных решений. Заказчик принимает решения, т.к. это его проект. Что обязательно должно быть сделано в следующей версии при имеющихся ресурсах проекта

Уточнение определения системы

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

Построение правильной системы

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

• все элементы проекта учтены;

• все элементы служат некой цели.

Проверка правильности (валидация) является второй составной частью приемо-сдаточных испытаний, призванных подтвердить корректность построенной системы. Основное внимание уделяется тестированию и использованию методов трассировки для отбора компонентов системы, нуждающихся в тестировании. Методы проверки правильности призваны гарантировать, что:

• все элементы надлежащим образом тестируются;

• все тесты служат некой полезной цели.

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