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

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - jura

Страницы: 1
1
jura,

Вы почитали, что должно содержать ТЗ и ТП?
bas, да почитал, и вот что выяснил:
Техническое задание – это документ, в основе которого лежат требования, сформулированные на понятном (обычном, привычном) для Заказчика языке.
Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании.

Вот из этой темы: http://www.uml2.ru/forum/index.php?topic=5238.0
есть комментарий Дениса Бескова:
Цитировать
Давайте возьмём 2 верхних уровня функциональных требований (без технических):

1. Бизнес-требования: «Система должна позволять отправлять почтовые сообщения» — этот уровень лучше описывается атомарными и группированными требованиями такого рода. Эти требования можно хранить в концепции и ТЗ.

2. Требования/решения пользовательского уровня: «Система должна позволять выбирать адресатов письма из адресной книги», «Система должна сообщать о факте успешной отправки письма» можно хранить атомарно, а лучше в способах применения. Эти требования можно документально хранить в приложении к ТЗ или уже в ТП.

Отсюда и вопрос, ВИ является технической реализацией или нет?

2
В вашем варианте ТП содержит менее детализированные требования, чем ТЗ. Это будет сбивать с толку людей, привыкших к устоявшейся терминологии. Я бы всё перечисленное для ТП включил в Концепцию, а если в вашем случае концепция не нужна, то в ТЗ.

А что тогда в ТП писать? :)
Как я понимаю, ВИ это не только способ выявления требований, но и способ реализации.

Или например так: выделить основные бизнес-задачи сервиса и их описать в ТЗ, а уже детали и проектные решения в виде ВИ писать в ТП?

3
Добрый день, задание разработать "техническое задание" и "технический проект".

Само задание:
Есть интернет магазин (продажа косметики) необходимо разработать сервис "обратной связи", чтобы покупатели могли связываться с администрацией магазина по разным вопросам. Необходимо разработать ТЗ и ТП.

Представим что сам ИМ это система, сервис "обратной связи" это подсистема. ТЗ и ТП не обязательно должны быть по госту.

Что писать в ТЗ?
1. Назначение и цели подсистемы
2. Перечень функций реализуемых подсистемой
3. Требования к подсистеме
(тут описываем, функциональные и не функциональные требования)


Что писать в ТП?
1. Постановка задачи
2. Определение ЗЛ
4. Цели ЗЛ
5. ДВИ
6. Описание каждого ВИ



4
А как правильно описывать циклы и ветвления, не используя "ЕСЛИ"


Пример, ВИ "Проверить заказ"
Цитировать
1. ВИ начинается, когда Менеджер нажимает кнопку ``Проверить заказ''.
2. Система формирует экран на котором выводит заполненную анкету клиентом.
3. Менеджер проверяет анкету
4. Если анкета заполнена правильно:
    4.1 Менеджер изменяет статус заказа на статус "Без ошибок" и нажимает кнопку "Сохранить и продолжить".
    4.2 Система сохраняет изменения.
5. Если анкета заполнена неправильно:
    5.1 Менеджер нажимает кнопку "Указать ошибки"
    5.2 Система переходит к сценарию "Указать ошибки".
 

Как правильно было бы написать такой сценарий без слова "Если"?

5
Я запомнил различие include и extend на основе примера.

1. Пользователь заходит в систему с какой-то целью, например, просмотр заказов. Перед этим он обязательно авторизуется в системе. В этом случае связь будет такая:

ВИ "Просмотреть заказы" ---include---> ВИ "Авторизоваться в системе"

2. Допустим, вы работаете над документом Word. И тут вы захотели включить функционал "Проверка орфографии и пунктуации". В этом случае связь будет такая:

ВИ "Формировать документ Word" <---extend--- ВИ "Проверить орфографию и пунктуацию".

Спасибо, действительно так намного стало понятнее :)

6
таблицу с ролями включить перед ВИ и все сделать отдельным документом, у нас так делают, например

7
Спасибо за ответ, Про понятие CRUD я знаю:)

По моему условию, просмотреть заказ можно только просмотрев список заказов, поэтому не нужна ли линия "include" между ними?

8
Нарисовал новую диаграмму по FAQ, для начала из 4х действий:

ВИ: просмотреть список заказов,
ВИ: просмотреть заказ,
ВИ: проверить заказ,
ВИ: указать ошибки в оформлении заказа


правильно?

9
Если кратко, то неправильно, см. примеры в этом разделе, все объяснения давали...
Смотрел, у всех к сожалению все по-разному,
а если не совсем кратко? пару наводящих замечаний :)
Все дело в include?

10
Всем привет.

Подскажите правильность диаграммы

Актор: Менеджер

менеджер может:
просматривать список заказов,
просматривать заказ,
проверить заказ,
указать ошибки в оформлении заказа,
изменить статус заказа,
загрузить готовые документы заказу,
принять заказ на себя.


Прикрепил файл. Правильно я нарисовал UseCase диаграмму?

Спасибо

11
http://softprofi.org/
bas, зарегистрировался, жду активации аккаунта.

12
Ищу работу системного аналитика, 24 года, высшее образование, более 2х лет работаю разработчиком в софтверной компании, резюме вышлю по запросу (Москва)

Опыта работы Системным аналитиком не имею. На данный момент читаю книги, форум. Хочу получить опыт на реальных проектах, готов работать удаленно 3-4 часа в день(преимущественно вечером) без оплаты.
Так же рассматриваю вариант стажера\младшего Системного Аналитика на полный рабочий день, но с з\п более 30 000 net

13
квест в чем
вообщем я составил список ВИ, нарисовал ДВИ, написал основные сценарии к ВИ

Дальше в ТЗ в соответствии с ГОСТ 34 идет: 
4.1 Требования к информационной системе в целом
указываю подсистемы, их назначение и т.д

4.2 Требования к функциям (задачам), выполняемым системой
Тут описываю функции каждой подсистемы

А где в ТЗ добавлять основные сценарии к ВИ? Или нужно в пункте 4.2 писать как раз эти сценарии к функциям?

14
Бизнес требования мы должны описывать в пункте 4.1, а функциональные/нефункциональные требования и требования пользователей мы описываем в пункте 4.2 Требования к функциям (задачам), выполняемым системой?






Страницы: 1