Журнал о системах электронного документооборота (СЭД)
Основы электронного документооборота

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

  7 комментариев Добавить в закладки

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

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

 

  • Цель.

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

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

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

  • Стандарты.

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

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

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

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

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

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

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

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