В теме 4 ответа, и 2 участника, последнее обновление сделано пользователем 
Михаил Сорокин 12 г, 11 мес. назад.
-
Сообщения
-
Привет.
Около полугода назад я наткнулся на такую книжку как «Software Requirement Patterns», внимательно прочел (не всю, интересующие меня главы). С тех пор я а. стараюсь идентифицировать шаблоны б. документирую их для себя.Книжку можно скачать тут.
Хотелось бы услышать как вы накпливаете свой опыт, и ре-используете опыт других.
Спасибо за книжку.
От себя могу сказать, что рассматриваю паттерн только как стартовую точку для формата описания требований на конкретном проекте.
С паттернами разработки, к примеру, все немного проще, проектные документы же создаются разными людьми для разных целей и для потенциально разной аудитории (если совсем утрировать, то требования могут быть как для разработчиков для предмета разработки, так и для несведующего в тех. деталях заказчика для их утверждения).
Лично у меня за 5 лет работы аналитиком ни разу не было, чтобы определенный формат описания полностью перенесся на др. проект без существенных изменений. И мне кажется это хорошо, т.к. документы создаются, чтобы их читали. Поэтому, если надо внести в формат документа изменения для удобства тех, кто его будет читать на данном проекте, без потери полезности документа — значит их надо внести.По поводу накопления опыта — лично я репозиторий шаблонов (личную базу знаний шаблонов) не веду (пока не было необходимости).
Т.к. если я описываю требований в каком-то формате несколько месяцев, то эти знания уже никуда от меня не денутся. А если я наткнулась на полезный шаблон описания в статье/книге, но в данный момент применить его не могу — то я поверхностно изучаю теоретическую часть шаблона. В тот момент, когда я смогу применить его — я всегда смогу найти достаточно документов по этому шаблону (как в сети, так и в моих локально сохраненных документах). Да и прогресс по определению не стоит на месте (к моменту необходимости применения шаблона умные люди в книгах/блогах могут написать уже много всего полезного о нем — надо только найти ) )Melissa, я говорю не про шаблоны документов, а про шаблоны самих требований. Требования описывают зачастую типичные ситуации. Таким же образом как ГОФ паттерны советуют как решать типичные ситуации.
Приведу пример. Зачастую, сущность может сохраняться в драфтовом виде. Таким образом паттерт "Драфт", будет рекомендовать или наводить на мысль:
1. В каком виде сохранять драфтовую сущность.
2. Какие данные нужно обязательно сохранить чтобы потом "поднять" ее. и т.д.Да, теперь ваш вопрос понятнее.Думаю любой аналитик так или иначе использует паттерны требований — это свойство человеческого мозга, минимизировать раcход энергии и выудить из памяти решение схожей задачи вместо решения "с нуля".
Другое дело, что, возможно, систематизация и документирование их оправданно, если аналитик "прокачивает" свою экспертизу год от года в схожих проектах из одной доменной области (в условиях нашей реальности это часто не получается — белорусский аутсорс, а следовательно и аналитик, берется за все подряд).PS: кстати паттерны используются также и при проектировании UI и взаимодействия с пользователем (например, часто использую http://designingwebinterfaces.com/).
PS: кстати паттерны используются также и при проектировании UI и взаимодействия с пользователем (например, часто использую http://designingwebinterfaces.com/).
С UI паттернами все более-менее понятно. Про них много написано и инфа на поверхности. А вот с паттернами требований (не привязанных к UI) все сложнее.
Вы должны авторизироваться для ответа в этой теме.
