Требования могут выдвигаться различными сторонами. Из Википедии источники требований:
Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)
Нормативное обеспечение организации (регламенты, положения, уставы, приказы)
Текущая организация деятельности объекта автоматизации
Модели деятельности (диаграммы бизнес-процессов)
Представления и ожидания потребителей и пользователей системы
Журналы использования существующих программно-аппаратных систем
Конкурирующие программные продукты
При разработке требований к системе следует принимать во внимание мнение ВСЕХ возможных пользователей. Сложные системы получают требования из многих источников (рис.4.1). Даже ОДНО неучтенное требование может привести к большим проблемам или печальному результату.
Рис. 4.1. Источники требований
sales manager - 1) коммерческий директор 2) заведующий отделом сбыта.
Help desk в дословном переводе означает стол помощи. В английском языке help desk – это устоявшееся сочетание, обозначающее техническую поддержку компьютерного парка. Таким образом служба технической поддержки – это help desk.
Технические требования разрабатываются в целях:
· Конкретизации и дифференциации требований к составу, структуре и функциям оборудования на объектах, в зависимости от их статуса и назначения;
· Установления требований к методам и техническим средствам, применяемых на объектах, и их техническому и метрологическому обеспечению;
· Конкретизации требований к программно-техническому комплексу автоматизированных систем управления;
· Определения порядка, организации и проведения метрологического контроля и надзора за состоянием и применением средств измерений и методик выполнения измерений.
· Результатами анализа и разработки требований могут быть:
· Техническое задание;
· Технические требования;
· Общие технические решения;
· Задание на проектирование;
· Подготовка конкурсной документации.
Совет: как создавать требования
· Принимайте во внимание различные источники (внутренние, внешние, Web).
· Идентифицируйте типы и группы пользователей. Общайтесь с каждым.
· Попытайтесь заставить пользователя выражать свои мысли в терминах процессов и данных, используемых ими на каждом шаге разработки
· Записывайте каждое требование как полное предложение, сформулированное в утвердительное форме
· Не забывайте о прошлых ошибках и старайтесь обойти их хорошими и простыми альтернативными вариантами требований
· Постарайтесь выяснить природу возникновения требования.
· Не стесняйтесь на некоторые требования заказчика спросить - ПОЧЕМУ?
· Никогда не оставляйте попыток улучшить формулировку требования.
· Остановитесь только когда каждый скажет, что понял, что имеется в виду
· Не жалейте времени сформулировать требование как можно более однозначно и недвусмысленно. Скорость работы многих специалистов - одна страница в час.
· Потратьте и вы хотя бы столько же времени, чтобы создать хороший документ с требованиями – это окупится сторицей.
Такой подход начинается с понимания потребностей заказчика, определения функциональности изделия и обязательных запланированных проверок (аттестаций, приемочных испытаний, контроля) на самых ранних стадиях жизненного цикла создания изделия
Преимущества, которые дает управление требованиями
· Информированность – ясное понимание целей и задач разработки
· Прозрачность – руководство может видеть общую картину и статус проекта
· Тестируемость – известно что тестировать, чтобы сдать продукт заказчику
· Интеграция – все отдельные блоки и модули наконец-то работают вместе
· Трассируемость – прозрачность отношений между требованиями
· Управление изменениями – оценка последствий вносимого изменения
· Оптимизация – разрабатываем и поставляем только то, что заказывалось
· Качество – мы хорошо понимаем, как много это значит для бизнеса
· Удовлетворение - заказчик и бизнес получают то, что хотели
