Взаимосвязь иерархии требований и ролей
Перевод статьи из блога tynerblain.com.
Ссылка на статью:
http://tynerblain.com/blog/2006/05/11/requirements-documents-one-mans-trash/
——перевод——↓
Существует несколько способов документирования требований при разработке программного обеспечения: MRD, PRD, SRS, FRS и документы проектирования системы. Каждый из участников имеет представление о том, что описывается в каждом из документов, но каждый из участников имеет свое собственное представление о том, на какие вопросы отвечает каждый из этих документов.
Процесс разработки программного обеспечения
Разработка программного обеспечения состоит из трех фаз:
- Определить, что делать;
- Определить, как делать;
- Сделать.
Мы можем представить это в виде трех вопросов:
- Зачем мы делаем это?
- Что мы хотим сделать?
- Как мы это сделаем?
В зависимости от роли в команде, мы получаем различные ответы на эти вопросы. Следующая диаграмма демонстрирует весь процесс разработки:
Процесс разработки программного обеспечения в данном представлении разбивается на пять категорий:
- Рынок. Определение проблем и возможностей, которые должны быть решены. Рассматривайте их как требования рынка;
- Требования. MRD и PRD. Описание того, что должно быть сделано для удовлетворения потребностей рынка безотносительно к способу реализации;
- Спецификация. SRS или FRS. Структурированное описание технологических решений, которые позволят реализовать требования;
- Проект системы. Стратегия реализации спецификации;
- Продукт. Код и тесты. Реализация.
Представления команды
Существует четыре различных представления процесса для ответа на три указанных выше процесса («Зачем», «Что» и «Как»). Мы можем определить роли, которые несут знамя каждого из взглядов.
- Менеджер продукта. Мыслитель, который находится в поисках перспектив создания хорошего программного обеспечения;
- Ведущий разработчик. Изобретатель, который находится в поиске лучших технических решений поставленных задач;
- Разработчик. Исполнитель, который старается сделать наиболее эффективное решение проекта системы;
- Тестировщик. Контролер, задачей которого является обеспечение того, что мы делаем правильную вещь и делаем это правильно.
У каждой из этих ролей есть свой взгляд на процесс разработки, и они по-разному отвечают на три вопроса «Зачем», «Что» и «Как». И каждая из ролей выбирает различные этапы процесса разработки для ответа на эти вопросы. Следующая диаграмма показывает связь пяти категорий из предыдущей диаграммы с четырьмя ролями.
Менеджер продукта
- Зачем? Рынок говорит нам, зачем мы должны делать что-либо. Мы ищем возможности и оцениваем их;
- Что? Наши требования четко отражают проблемы, которые мы хотим решить и что необходимо для их решения;
- Как? Спецификация – практическое описание того, что должно быть сделано.
Ведущий разработчик
- Зачем? У нас есть требования, которые определяют рамки мероприятия;
- Что? Спецификация говорит нам, что должно быть сделано;
- Как? Проект системы показывает нам подход к решению задачи.
Разработчик
- Зачем? Спецификация четко описывает наши обязанности;
- Что? Проект системы говорит нам, как решить поставленные задачи лучшим образом;
- Как? Мы ответственны за продукт, который мы создаем.
Тестировщик
- Зачем? Требования должны быть реализованы;
- Что? Проект системы должен быть надежным. Доверяй, но проверяй;
- Как? С помощью тестов мы гарантируем качество того, что мы делаем.
Заключение
У людей в команде различные обязанности. И эти люди рассматривают разные этапы процесса разработки как «источник вдохновения». Также они ответственны за различный результат.
