Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: anastazya от 28 Июля 2008, 08:06:54
-
Привет,
хотелось бы узнать кто из присутствующих занимался разработкой документов, в которые бы входили помимо требований, основаные на них интерфейсы. Если не жалко выложите плиз.
-
Если Вы имеете в виду GUI, то я всегда делаю ссылки из ВИ на GUI. Что конкретно интересует?
-
Точно. Именно его. Интереснует как все это дело должно офомляться.
-
Например, в SRS (http://en.wikipedia.org/wiki/Software_Requirements_Specification) есть такой раздел User Interfaces, там и надо описывать интерфейсы и делать ссылки из ФТ.
В ГОСТе (http://www.nist.ru/hr/doc/gost/34-602-89.htm) тоже есть раздел "требования к информационному обеспечению", там можно описать требования к GUI, сделав ссылка на них из соответствующих ФТ.
-
2 anastazya: Вопрос в том, что именно поинимается под требованиями к GUI в конкретном случае. Я встречал 2 разных случая описания такого рода требований:
1) требования к интерфейсу описываются в общем виде -- т.е. в лучшем случае говорится какие элементы GUI должны использоваться (или из какой библиотеки GUI), могут приводиться ссылки на конкретное ПО ("чтобы был GUI как в нем", например sсheduller как в Outlook и т.п.)
2) в ТЗ приводится собственно дизайн GUI -- это бывает когда задача разработчика суть чисто кодирование (т.е. вот тебе дизайн, включая дизайн GUI -- напиши реализацию на таком-то ЯП) или когда по требованиям (например по тем же юзкейсам) в качестве сторибоардинга был спроектирован МАКЕТ GUI (для иллюстрации) и который имеет рекомендательный характер.
Очевидно, в зависимости от ситуации описание требований к GUI будет различно ... Каков случай ваш?
-
Юрий, я имею ввиду интерфейс, который содержит элементы, которые ссылаются на требования.
-
Видимо Анастасия имеет в виду Прототип\Макет GUI.
Тогда Вам должно подойти решение, кот. я Вам написал. Ссылки могут быть перекрестные, как из GUI на ФТ, так и наоборот.
-
Юрий, я имею ввиду интерфейс, который содержит элементы, которые ссылаются на требования.
Не вполне понял что имеется ввиду (сложно как-то предложение выстроено :-)) ... вы не могли бы пояснить?
-
:) Юрий, поясняю: есть форма, которая содержит некий набор элементов (поля, радибаттоны и т.д.). Есть требования, на основе которых эти элементы были помещены на эту форму. Где и в каком виде это должно быть описано. Я имею ввиду, что интерфейс берется не с потолка, а основывается на определенных требованиях. Вот я о чем.
-
bas, а можно узнать куда вы написали мне?
-
Т.е. вы хотите трассировать требования на GUI, вплоть до конкретных контролов? ...
На самом деле будет довольно напряжно поддерживать такую трассировку в состоянии целостности, особенно на первых итерациях проекта. Более практично утверждать GUI у заказчика через прототипы. Я бы вообще в таком тяжелом случае, когда заказчик ТАК ТРЕБОВАТЕЛЕН к GUI рекомендовал бы использовать сторибоардинг
-
bas, а можно узнать куда вы написали мне?
Вот (http://www.uml2.ru/forum/index.php?topic=859.msg9223#msg9223), если Вы это (http://www.uml2.ru/forum/index.php?topic=859.msg9236#msg9236) имели в виду.
-
Привет,
хотелось бы узнать кто из присутствующих занимался разработкой документов, в которые бы входили помимо требований, основаные на них интерфейсы. Если не жалко выложите плиз.
Привет. Мы в проекте формы пользовательского интерфейса трассируем на ВИ, т.е UC-->GUI, если в дальнейшем будем создавать для каждого варианта использования реализацию в виде взаимодействия классов анализа, то будем трассировать через граничные классы, т.е UC-->Boundary --> GUI. Но почти всегда, имхо последняя связь будет один к одному. Если проект не большой то, думаю, первого случая достаточно, т.к. из анализа сценария ВИ можно свободно накидать прототип (макет) пользовательского интерфейса. Если же форм много и они могут использоваться в разных ВИ, удобней делать через классы анализа, но это требует дополнительных временных затрат.
Т.е. вы хотите трассировать требования на GUI, вплоть до конкретных контролов? ...
На самом деле будет довольно напряжно поддерживать такую трассировку в состоянии целостности, особенно на первых итерациях проекта. Более практично утверждать GUI у заказчика через прототипы. Я бы вообще в таком тяжелом случае, когда заказчик ТАК ТРЕБОВАТЕЛЕН к GUI рекомендовал бы использовать сторибоардинг
Юрий, я думаю в случае Анастасии, заказчик не требователен к GUI и не выдвигает жестких требований. Наверное аналитики, хотят сами убедится в том, что вся функциональность в требованиях учтена в формах GUI и ничего не забыто. Анастасия, я прав?
Если так. То может описать варианты использования, а далее в документе привести графическое представление формы и сослаться на ВИ.
-
Виталий, о чем я и говорил в своих постах.
-
Виталий, о чем я и говорил в своих постах.
Ага :-) . Я только немного добавил про классы анализа.
-
Юрий, я думаю в случае Анастасии, заказчик не требователен к GUI и не выдвигает жестких требований. Наверное аналитики, хотят сами убедится в том, что вся функциональность в требованиях учтена в формах GUI и ничего не забыто. Анастасия, я прав?
Если так. То может описать варианты использования, а далее в документе привести графическое представление формы и сослаться на ВИ.
Именно так, Виталий. Правда мы сначала описываем требования в виде иерархии, основанные на ВИ, а потом создаем интерфейсы в соответствии с пунктами требований. Мне хотелось бы знать как правильно все это дело оформлять.
-
Именно так, Виталий. Правда мы сначала описываем требования в виде иерархии, основанные на ВИ, а потом создаем интерфейсы в соответствии с пунктами требований. Мне хотелось бы знать как правильно все это дело оформлять.
Анастасия, если я правильно понял, схема у Вас следующая:
1. Создается набор вариантов использования и описываются их сценарии
2. Из сценариев получается набор функциональных требований
3. Создаются GUI на основе функциональных требований.
Трассировка у вас в таком случае UC-->RQ-->GUI ?
1. В документе, как уже говорил Выше Александр и немного я :), создаете раздел в котором описываете набор вариантов использования и их сценарии. Лучше каждому ВИ присвоить уникальный номер, например UC1, UC2...
2. В следующем разделе приводите список функциональных требований, которые вы получили из сценариев ВИ. Каждому требованию тоже лучше присовить идентификатор, например REQ1, REQ2...
Далее делаете матрице трассировки требований на ВИ, или если описываете требования в таблице, то прямо в таблице для каждого требования пишете ВИ к которому оно относится
3. В следующем разделе рисуете GUI и точно также трассирует на требования.
Анастасия, а какого уровня абстракции у вас варианты использования: Business, Summary или System?
Если системные ВИ то может не стоит тогда функциональные требования писать, а достаточно лишь сценариев?