Здравствуйте, GapertonСтат, Вы писали:
G>В нашей практике техническим заданием мы называли документ, который подписывается заказчиком и определяет что, собственно, будет разработано и за что
G>будут уплачены деньги (и какие). Задача и цель ТЗ состоит в том, что как только он подписан заказчиком, мы гарантируем (1) сроки выполнения заказа и
G>бюджет по данному ТЗ, (2) что мы сделаем тот продукт, который соответствует ТЗ, (3) что мы не сделаем ничего кроме указанного в ТЗ (т.е. все
G>изменения к ТЗ оплачиваются отдельно). Факт подписи ТЗ с нашей стороны означает, что нам понятна задача (по крайней мере процентов на 90) и мы знаем
G>как ее решать настолько, что можем гарантировать сроки и бюджет. При этом мы хотим защититься от изменений требований, желаний, и бизнес-процессов
G>"на халяву" со стороны заказчика.
G>Требование гарантии по срокам и бюджету и делает наш документ иногда отличным от SRS.
Я вот тоже только в сроках, бюджете и в защите от изменений требований со стороны заказчика нашла различие.
Но хотелось бы посмотреть пример такого документа, есть у кого-нибудь пример SRS? И на сколько сильно в спецификации требований детализируются функции системы? Буду рада, за помощь.
Здравствуйте, vhomka, Вы писали:
V>Я вот тоже только в сроках, бюджете и в защите от изменений требований со стороны заказчика нашла различие.
V>Но хотелось бы посмотреть пример такого документа, есть у кого-нибудь пример SRS? И на сколько сильно в спецификации требований детализируются функции системы? Буду рада, за помощь.
У меня есть шаблоны Microsoft Solutions Framework:
Business Requirements.doc
Operations Requirements.doc
System Requirements.doc
User Requirements.doc
Если интересно могу выложить.
Это не примеры, это именно шаблоны, но по ним видно что должно в них содержаться
