Огромное всем спасибо за советы. Сделала для себя определенные выводы.
В проекте используются шаблоны некой методологии microscope. модели рисуем в RRose. больше по сути не пользуемся ни чем.
Сейчас столкнулись с проблемой, что в use case не прописано ни одного поля, которые нужно заполнить. Например:
Пользователь добавляет новый элемент - Система открывает фору добавления нового элемента.
Пользователь заполнил атрибуты и нажал сохранить - Система проверила все ли обязательные атрибуты заполнены, сохраняет новый элемент. Если одно из обязательных полей не заполнено, система выдает ошибку.
Кстати, еще вопрос: Правильно ли прописывать текст сообщения об ошибке в use case? Мне пришлось это сделать, т.к. наши тестеровщики не могли тестировать - не знали, что должно всплывать и что должно писаться. В результате сначала прописали одни сообщения, потом поняли, что среда, в которой разрабатывают систему не может поддерживать такое поведение, переписали заново (у меня сейчас вся работа состоит в том, что я то что-то добавлю, то убиру, потом опять добавлю, то что недавно было убрано).
Если следовать совету Александра Котельникова, то у нас на проекте кроме меня никого не останется, т.к. изменения требуют вносить и тестеровщики и разработчкики (причем разработчки не сообщают об этом аналитику!!! был скандал! При этом всегда крайний аналитик, т.к. клиенты увидели эту экстрафичу и сказали - мы этого не просили, зачем это? а ну уберите! вы не придерживаетесь наших требований! (это в случае, если эта экстрафича им непонравилась), или - а почему этого нет в требованиях, раз это уже есть в релизе, значит мы это ообсуждали этого хотели, ах как так аналитик это не прописал!)
Еще вопрос: К примеру, в use case описываю сценарий поиска "Элемента" в справочнике. Т.е. пользователь задает параметры, инициирует поиск - Система ищет "элемент" согласно заданным параметрам. На форме задается куча параметров - причем нужно проверять, чтобы дата была в формате DD/MM/YYYY, номер версии элемента не содержал букв, что в номер версии может быть введено только 12 символов с разделетелем ".", по умолчаню стоит "Искать последнюю утвержденную версию" но можно поменять на просто "последнюю", на "все", можно использовать ключевое слово (при этом система ищет соответствующее значение в поле1, поле2, коментариях и кратком описании)причем вводиться туда может до 8000 символов.
Подобной детализации в описании ограничений на вводимые данные от меня требуют тестеровщики, чтобы им можно было проверить влезает туда 8000 символов или 8001 (есть возможность завести дефект лишний раз) - что выводит из себя разработчков. Вобщем стоит ли все это прописывать в use case или для этого есть отдельный документ?
Еще на прошлой работе у меня был опыт следующего оформления спецификаций требований: в каждую спецификацию вставлялась модель сущность-связь из Erwin, где можно было четко увидеть все атрибуты сущности, участвующей в данном сценарии, просделить связь между всеми сущностями, участвующмими в процессе. На этой работе мы так не делаем и менять методику написания use case уже невозможно (тем более шаблоны и методику диктует нам заказчик). В вашей практике занимаетесь ли вы построением модели базы данных, диаграмм классов - и где это прописываться у вас в use case или в каком-либо отдельном документе?
В одном из постов старожилы этого форму сетовали на то, что мол новички молчат, студенты только читают, а сказать ничего не могут. И вот меня понесло
Но мне, действительно, нужны и важны ваши советы! Еще раз спасибо огромное!
Потерянные требования