Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: ES2011 от 15 Мая 2011, 20:02:57
-
Вопрос следующего характера:
В ТЗ иногда пишут use case.
Насколько уместно в ТЗ помимо вариантов использования включать конкретные сценарии (вплоть до указания вводимых пользователем данных).
Или для ТЗ это не преемлемо?
-
Для ТЗ бессмысленно.
Для тестирования - возможно.
-
пример приведите того и того варианта
-
Противоречивые советы)
Но все равно спасибо
-
Почему так сразу и противоречивы?
Вы должны убедиться что use case понимают все участники проекта(вы , разработчики ,ген директор и заказчики).
Это условие очень трудно будет обеспечить.
Иначе это как писала IDA - не имеет смысла.Одни трудозатраты
-
IDA пишет, что приводить примеры в ТЗ бессмысленно.
Я-то как раз боюсь, что если не писать конкретные примеры, то могут возникнуть недопонимания.
Вопрос именно в том, насколько корректно писать ПРИМЕР (с детализацией вводимых данных):
Вот так писать можно (вымышленный сценарий):
Вариант использования "Сохранение документа"
Сценарий
1. Пользователь пытается сохранить документ
2. Система отображает окно сохранения документа
3. Пользователь вводит наименование документа и подтверждает операцию сохранения
4 Система сохраняет документ
Альтернативный сценарий 1
2. Если документ сохранен ранее, то он сохраняется без вопросов под тем же именем.
Альтернативный сценарий 2
На шаге 3 пользователь ввел некорректное наименование документа
Система сообщает о невозможности сохранения документа
А можно ли привести потом пример:
Пример "Сохранение документа. Ошибка ввода"
1. Пользователь пытается сохранить документ
2. Система отображает окно сохранения документа
3. Пользователь вводит наименование "// ..@@"
4. Система сообщает о невозможности сохранения документа: "Имя документа некорректно. Сохранение невозможно".
Пример выдуман, но суть в том, а корректно ли вообще писать примеры в ТЗ.
Что можно писать варианты использования ясно.
-
Техническое задания первую очередь является документом соглашения между заказчиком и разработчиком. Коли оно пишется. Весьма странно будет выглядеть контракт, в котором будут приведены примеры. Примеры они и есть примеры, они не могут охватить всех ситуаций.
Другое дело описание технических заданий, или лучше извлечений из технических заданий . В них некоторые примеру могут помочь понять какие-то детали. Или использование примеров помогает в ходе извлечения и уточнения требований при работе с заказчиком.
-
Примеры помогают use case. Более того, если use case запутан и до конца не проработан (а такое бывает), то несколько конкретных примеров, которые фиксируют точно известные сценарии - гораздо лучше, чем попытка обобщения и домысливания, в которой область неизвестности будет размыта. В этом случае примеры вместо обобщенного описания помогают избежать достаточно распространенной ситуации, когда аналитик придумывает общее решение, программисты трудятся и его делают, а потом оно оказывается ненужным или бесполезным, поскольку не соответствует реальности.
Да, говорить что в описанной ситуации надо просто лучше изучить область - не надо, по опыту, если основной сценарий понятен, то его стоит реализовать и показать, а потом уточнять остальное. Но известные примеры альтернатив - помогут, и полезны сразу.
Но все это - про реальные и сложные use case. Пример с сохранением документа - это use case, которого вообще не должно быть в описании, такие вещи сильно увеличивая объем документа мешают его пониманию. Пишу потому, где видел ТЗ в которых авторы каждый документ сопровождали подобными тривиальными сценариями - наверное, им платили по-странично.
-
Спасибо за ответы! Use case с сохранением был приведен для демонстации сути моего вопроса.
Он тривиален. Просто не хотелось приводить пример длинного кейса, дабы не путать читающих пост.
Техническое задания первую очередь является документом соглашения между заказчиком и разработчиком. Коли оно пишется. Весьма странно будет выглядеть контракт, в котором будут приведены примеры. Примеры они и есть примеры, они не могут охватить всех ситуаций.
Это понятно. А так ли плохо, что в ТЗ - вариант использования, а в приложениях - примеры отдельных сценариев.
Ведь и эскизы экранных форм не принято писать в ТЗ (не тех.проект).
Но насколько я знаю не возбраняется привести их в приложениях с оговоркой, что в процессе проектирования возможны изменения в дизайне.
Ну не просто бывает заказчику без экранных форм и примеров.
-
Вот тут большой набор ТЗ http://aisup.economy.gov.ru/pubportal/
-
Соглашусь с Эд, что ТЗ должно описывать ВСЕ требования к Системе, но пример можно привести, если формулировка требований сложная/неочевидна.
А пример требования был приведен плохой:
На шаге 3 пользователь ввел некорректное наименование документа
Требования должны быть однозначными и корректными. Из этой формулировки вообще непонятно - что такое "некорректное наименование документа". Тут нужно перечислить не примеры символов, а все символы, которые считаются неконкретными в имени документа.
-
А как вам такая мысль:
в техническом задании должны быть отражены не все требования, а только архитектурнозначимые?
-
Спасибо за ответы!
-
А как вам такая мысль:
в техническом задании должны быть отражены не все требования, а только архитектурнозначимые?
После такой фразы обычно народ пишет четкое определение - что же такое "архитектурнозначимые" требования )
-
После такой фразы обычно народ пишет четкое определение - что же такое "архитектурнозначимые" требования )
Ты это написал так, что можно прочесть, а после этого настоящие офицеры стреляются, или после этого вообще-то следует подать в отставку.
Архитектурнозначимые - те, которые оказывают значительно влияние на архитектуру. Это как раз, те требования, которые следует выявить как можно раньше. А вот как они на самом деле выглядят и чем отличаются от неАЗ, не вем :(
Думаю тут следует разделить тему иначе флуд.
-
Архитектурнозначимые - те, которые оказывают значительно влияние на архитектуру. Это как раз, те требования, которые следует выявить как можно раньше. А вот как они на самом деле выглядят и чем отличаются от неАЗ, не вем :(
Мне кажется это очень сложно. Подобные вещи можно выявить на этапе ТП. А ведь заказчик все время хочет подписать все поскорее и начать работу. Кроме того, эта бумажка - гарант его правильного вложения денег, потому, мне кажется, ему гораздо понятнее будут именно функциональные требования, требования назначения.
А вообще все зависит от заказчика и от исполнителя. Я сотрудничала с людьми, которые согласовывали только 2 документа с заказчиком: описание бизнес-требований (буквально 1-2 листа кратко) и требования формата use case + мокапы. Процесс согласования был длительный и болезненный, но позволял на выходе получить готовое ТЗ на разработку, заказчик же получал представление о том, как будет выглядеть его система, а все возможные "А давайте сюда добавим кнопочку" ликвидировались на этом этапе.