Наверх

Как составить техническое задание на систему электронного документооборота?

Архив
Время чтения: 3 минуты
5
Как составить техническое задание на систему электронного документооборота?

Как составить техническое задание на систему электронного документооборота?

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

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

  • Цель.

Необходимо явно выделить цель и проблематику,ответить на вопрос: «Для решения, каких задач Вам необходима СЭД»? На этом этапе цель может быть достаточно размыта,не нужно вдаваться в процесс желаемого решения конкретных «узких» мест и специфических задач.

  • Функциональные требования.

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

  • Стандарты.

Указать стандарты, которым должна удовлетворять система документооборота.

  • Системные требования.

Поддерживаемые операционные системы, требования по памяти.

  • Желаемая стоимость.

Здесь необходимо указать как диапазон цен, такжелаемое количество лицензий.

Это очень краткий список. Техническое задание должно быть достаточно детализированным! На мой взгляд, возможно, необходимо детально описать один из бизнеспроцессов компании более подробно в виде схем (например, с помощью CASE-систем).

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 5

Дамир Галимов 3 августа 2009
При определении функциональных требований обязательно захочется больше чем надо сейчас. Поэтому есть смысл все требования проранжировать (хотя бы для себя) по приоритетам (надо обязательно/желательно/очень хочется, но если нет, то не надо) и срокам (надо сразу/потребуется позже). В дальнейшем это позволит сэкономить средства: если на систему, которая делает все денег не хватает, то можно присмотреться к той, которая делает все жизненно важное нам и готова развиться до того, что мы отложили "на потом".
Михаил Романов 3 августа 2009
Поэтому есть смысл все требования проранжировать (хотя бы для себя) по приоритетам (надо обязательно/желательно/очень хочется, но если нет, то не надо)

И назвать эту технологию Scrum :)
Алена Вернова 3 августа 2009
Большое спасибо за комментарии . Постараюсь в ближайшее время раскрыть тему более подробно.
Максим Галимов 3 августа 2009
по приоритетам (надо обязательно/желательно/очень хочется, но если нет, то не надо)
MoSCow - M – Must have, S – Should have, Co – Could have, and W - Would have, if we had time. 

Предлгаю продолжить дискуссию на "круглом столе".

Чтобы прокомментировать, или зарегистрируйтесь