Форум Сообщества Аналитиков

×


Потерянные требования(Прочитано 13257 раз)
Потерянные требования : 17 Апреля 2007, 17:42:15
Создано по мотивам сообщения в топике http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=68.msg2120#msg2120

Цитировать
Всем привет.
Хотела поделиться проблемами и задачами. Вобщем, недавно я пришла работать в компанию, автоматизирующую бизнес-процессы. Я работаю системным аналитиком. Попала на проект в стадии, когда требования фактически уже собраны, мне их "пересказал" и дал почитать спецификации требований бывший аналитик. Сейчас уже идет стадия разработки - столкнулись с кучей неопределенностей, спотыкаемся на каждой мелочи. Я теперь единственный аналитик на проекте, все проблемы падают на меня и я совершенно не справляюсь! Хочу пересмотреть полностью концепцию написания спецификаций требований, но опыта не хватает грамотно к этому подойти и довести до конца. С принципами написания use case model у меня есть, но сейчас я столкнулась с тем, что не знаю, где мне прописать такие требования к системе, как ограничение полей, обязательность заполнения, взаимосвязи сущностей. Так, чтобы один раз написал спецификацию, где пользователь\заказчик сразу увидел четко обозначенные поля, что вводим, где выбираем, затем подписал это и все! А сейчас у нас постоянно добавляются новые поля, не можем разобраться с форматом вводимых данных. Вобщем ситуация бедственная!



Re: Потерянные требования Ответ #1 : 17 Апреля 2007, 17:44:45
Тогда повторюсь

Во-первых, давайте успокоимся :-)
Во-вторых, вероятно в вашей организации нет четкого процесса разработки и налаженной системы отслеживания и управления требованиями. Но все-таки какие-то стандарты приняты. Хотелось бы узнать, какие стандарты приняты, какие шаблоны и технологи используете или предпочитаете, какими интсрументами пользуетесь.

Читая вашу беду, сразу подумал о Вигерсе и о его примерах в книге, тут вот сделал перевод его примеров, ну а саму книгу найдете думаю.

В частности в них есть такое понятие как словарь данных. Весьма полезная вещь, но возможно не всегда строго необходимая. Ведь модель классов явно и неявно будет уже содержать всю эту информацию.
Согласитесь, что не поле формы определяет тип данных, а данные тип поля формы. Однако о словаре - в нем достаточно точно и формализовано описано, что есть каждое данное - его тип если требуется, ограничения и т.п. Посмотрите сами.

Модель данных и словарь очень полезны - они взаимодополняют друг друга, просто одно лучше представить как модель визуальную, другое как модель текстуальную.

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

Кроме того используя Visio, или Enterprise Architect, или Visual Paradigm CE, Access наконец можно разработать сразу концепции форм и трассировать их к тем элементам данных в словаре, модели данных, правилам и ограничениям.
« Последнее редактирование: 17 Апреля 2007, 19:30:21 от Galogen »



Re: Потерянные требования Ответ #2 : 18 Апреля 2007, 00:30:41
Да, эту проблему помогает решать трассировка. Не поленитесь, поставьте себе CaliberRM, внесите в проект все ваши требования. Постарайтесь хотя бы примерно сгруппировать требоавния на бизнес-требования, требования пользователей, функциональные и нефункциональные. Зафиксируйте их в программе и заполните матрицу трассировки - она в Caliber удобная достаточно. правила заполнения матрицы смотрите у Лиффингуэлла - там это доступно.

Этот набор требований закрепите как базовый.
Теперь остановитесь - решите проблему "кто вправе вносить изиенеия в проект". Жестко запретите вносить измения программистам, тестерам, маркетологам.
Только уполномоченное лицо или лица.

И только после этого - анализируйте - какие требования упущены, какие противоречат друг другу, какие выходят за рамки проекта. Жестко, до истерики, придерживайтесь процедуры внесения изменений. Тот же Лиффингуэлл предлагает увольнять программеров, вносящих несанкционированные изменения. Не идите на поводу у босса - даже его требования должны быть приняты уполномоченным лицом - отвечать будете вы.



Re: Потерянные требования Ответ #3 : 18 Апреля 2007, 10:19:59
Огромное всем спасибо за советы. Сделала для себя определенные выводы.  ;)

В проекте используются шаблоны некой методологии microscope. модели рисуем в RRose. больше по сути не пользуемся ни чем.

Сейчас столкнулись с проблемой, что в use case не прописано ни одного поля, которые нужно заполнить. Например:
Пользователь добавляет новый элемент - Система открывает фору добавления нового элемента.
Пользователь заполнил атрибуты и нажал сохранить - Система проверила все ли обязательные атрибуты заполнены, сохраняет новый элемент. Если одно из обязательных полей не заполнено, система выдает ошибку.
Кстати, еще вопрос: Правильно ли прописывать текст сообщения об ошибке в use case? Мне пришлось это сделать, т.к. наши тестеровщики не могли тестировать - не знали, что должно всплывать и что должно писаться. В результате сначала прописали одни сообщения, потом поняли, что среда, в которой разрабатывают систему не может поддерживать такое поведение, переписали заново (у меня сейчас вся работа состоит в том, что я то что-то добавлю, то убиру, потом опять добавлю, то что недавно было убрано).

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

Еще на прошлой работе у меня был опыт следующего оформления спецификаций требований: в каждую спецификацию вставлялась модель сущность-связь из Erwin, где можно было четко увидеть все атрибуты сущности, участвующей в данном сценарии, просделить связь между всеми сущностями, участвующмими в процессе. На этой работе мы так не делаем и менять методику написания use case уже невозможно (тем более шаблоны и методику диктует нам заказчик). В вашей практике занимаетесь ли вы построением модели базы данных, диаграмм классов - и где это прописываться у вас в use case или в каком-либо отдельном документе?

В одном из постов старожилы этого форму сетовали на то, что мол новички молчат, студенты только читают, а сказать ничего не могут. И вот меня понесло :-[ Но мне, действительно, нужны и важны ваши советы! Еще раз спасибо огромное!



Re: Потерянные требования Ответ #4 : 18 Апреля 2007, 12:01:57
Если рисуете в Rose - тогда скачивайте и ставьте RequisitePro. Она интегрируется с Rose и сможете делать трассировки UC к требованиям.
Где скачать - смотрите на сайте, который в моем профиле.



Re: Потерянные требования Ответ #5 : 18 Апреля 2007, 16:36:38
(тем более шаблоны и методику диктует нам заказчик)
А Вы можете предоставить нашему сообществу эти документы для изучения? Или это секрет фирмы?



Re: Потерянные требования Ответ #6 : 18 Апреля 2007, 21:59:57
Огромное всем спасибо за советы. Сделала для себя определенные выводы.  ;)

В проекте используются шаблоны некой методологии microscope. модели рисуем в RRose. больше по сути не пользуемся ни чем.

У меня есть ощущение, что вы работаете на одну _очень_ известную на отечественном оффшорном рынке компанию, в проекте на иминитого западного заказчика в сфере авиции, так?

Сейчас столкнулись с проблемой, что в use case не прописано ни одного поля, которые нужно заполнить. Например:
Пользователь добавляет новый элемент - Система открывает фору добавления нового элемента.
Пользователь заполнил атрибуты и нажал сохранить - Система проверила все ли обязательные атрибуты заполнены, сохраняет новый элемент. Если одно из обязательных полей не заполнено, система выдает ошибку.

А может так оно будет понятнее ...:
...
Главный успешный сценарий
1. Пользователь инициирует добваление нового элемента.
2. Система отобаражет форму добавления нового элемента и предлагает заполнить Атрибуты_элемента.
3. Пользователь заполнет Атрибуты_элемента и подтверждает ввод.
4. Система поддтверждает заполнение всех обязательных атрибутов и сохраняет элемент (или можно более детально -- Система в соответствии с бизнес-правилом BR33 подтверждает корректность заполнения Атрибутов_элемента и сохраняет элемент)

Альтернативные сценарии (или Расширения)
3а. Пользователь оказался от ввода
  3а1. <что происходит при этом>
4а. Не все обязательные атрибуты заполнены.
   4а1. Система предупреждает пользователя о проблеме и отображает (или выделяет         визуально) незаполненные атрибуты. (ИЛИ Система выдает Сообшение_об_ошбке_23 и ...)
   4а2. <что происходит далее ...>

Дополнительная информация
Атрибуты_элемента = Название чегото-то {max. 250 символов}
+ дата чего-то {в формате dd/mm/yyyy}
+ еще что-то ....
+ еще нечто
+ ...

Сообшение_об_ошбке_23 = "Hitler kaput!"

Еще на прошлой работе у меня был опыт следующего оформления спецификаций требований: в каждую спецификацию вставлялась модель сущность-связь из Erwin, где можно было четко увидеть все атрибуты сущности, участвующей в данном сценарии, просделить связь между всеми сущностями, участвующмими в процессе. На этой работе мы так не делаем и менять методику написания use case уже невозможно (тем более шаблоны и методику диктует нам заказчик). В вашей практике занимаетесь ли вы построением модели базы данных, диаграмм классов - и где это прописываться у вас в use case или в каком-либо отдельном документе?

См. как это можно сделать выше .. без всяких диаграмм ...

В одном из постов старожилы этого форму сетовали на то, что мол новички молчат, студенты только читают, а сказать ничего не могут. И вот меня понесло :-[ Но мне, действительно, нужны и важны ваши советы! Еще раз спасибо огромное!

Your welcome ...
P.S. Если то что я посоветовал поможет вам в работе, то скажите вашему директору центра качества, что я вышлю ему счет по почте, за консалтинг :-) ...

Disclaimer: То что в P.S. написано а) публикуется на правах шутки б) валидно, если я правильно угадал ваше место работы.
« Последнее редактирование: 19 Апреля 2007, 12:33:29 от Юрий Булуй »
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Потерянные требования Ответ #7 : 18 Апреля 2007, 23:24:22
Disclaimer: То что в P.S. написано а) публикуется на правах шутки б) валидно, если я правильно угадал ваше место работы.
Вот ведь, ххитрец аналитический:). Вроде сказал нет, но в то же время да. вроде как бы да нет да :)



Re: Потерянные требования Ответ #8 : 19 Апреля 2007, 12:34:20
Эд, не хитрец ... это нормальный рефлекс консалтера.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Потерянные требования Ответ #9 : 06 Июня 2007, 09:30:32
Эд, не хитрец ... это нормальный рефлекс консалтера.
Советую оставлять рефлексы консалтера на работе. А то новичков всех распугаете. Они вам вопрос, а вы им в ответ называете где он работеает и сообщаете, что счет уже выслан.
Вот и общайся так в форуме.  ;D



Re: Потерянные требования Ответ #10 : 06 Июня 2007, 12:00:36
Советую оставлять рефлексы консалтера на работе.

Советовать -- это одна из составляющих МОЕЙ работы :-).

А то новичков всех распугаете. Они вам вопрос, а вы им в ответ называете где он работеает и сообщаете, что счет уже выслан.
Вот и общайся так в форуме.  ;D

У новичков должно же быть чуство юмора и доля самоиронии :-) ... Мир не всегда жестОк :-).
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19