Если у вас хорошие отношения с заказчиком, а система сдается его руководителю… А ещё на написание ТЗ есть 30-60 минут, то пулочившееся ТЗ будет выглядеть так: ТЗ ЕСУЗ.
Методика проста – беру просто шаблон RUP (которому потом не шибко следую), делаю скрины всех страниц (с кратким описанием того, что там можно делать и зачем это). Далее делаю скрины базы – все поля, добавляю схему данных и дописываю ограничения (это делал мой партнер по проекту).
Всё 🙂
P.S. Так работать не надо.. Это ТЗ по сути вообще не нужно было главному заказчику (его требования уместились бы на листе А4), но вот доделывать и дорабатыывать систему гораздо проще, когда есть хотя бы такой документ.
Advertisements
Лёш, больше похоже на описание системы с учётом нефункциональных требований. Я тоже подобное как-то писал только потому, что заказчику было оно необходимо. Зачем? Наверное, для того, чтобы показать, что что-то сделано.
Да, и для этого тоже. Но ещё чтобы потом вспомнить – что это такое мы наразрабатывали 🙂
Это такой фичер лист скорее получится )
Да, вроде того, но не очень удачный. С другой стороны – ещё есть описание базы + приложены скрины всех фейсов, за счет чего систему легко представить следующему потенциальному заказчику..
Pingback: Я и стартап, которому не суждено было выжить | Блог Алексея Киселева