196

Sparx / Re: Генерация отчета для оценки трудоемкости

« : 12 Января 2016, 00:11:37 »

А при чём тут ТЭО?

197

Варианты Использования (Use Case) / Re: Как отобразить на ВИ требования к вариантам развертывания?

« : 12 Января 2016, 00:10:21 »

Какая сеть? При чём здесь сеть?

Контекстную диаграмму нарисовать можете?

Обычно при развёртывании происходит взаимодействие дистрибутива с ОС.

Т.е. в качества агентов могут выступать Администратор и ОС. А в качестве проектируемой системы — дистрибутив.

198

Системный Анализ и Требования / Re: управление требованиями

« : 07 Января 2016, 13:09:16 »

2. Создается требование к внешнему интерфейсу (интегарция со сканером)
Идентификатор: ИНТ1.
Заголовок: - Интеграция со сканером.
Описание:
система должна обеспечивать возможность получить копию документа клиента со сканера. Для этих целей необходимо обеспечить
взаимодействие системы со сканером <Модель>.
Схема взаимодействия
<тут размещаем схему>

Диаграмма вызовов
<тут некоторый материал поясняющий кто кого вызывает и т.д.>

Описание протокола взаимодействия
<длинное описание протокола взаимодействия со сканером>

3. Теперь формируем функциональное требование на выполнение пользовательского требования регистрации клиента
Идентификатор: ФТ1.
Заголовок: - Регистрация клиента.
Для выполнения сценария регистраии клиента неоходимо реализовать соледующие функциональные возможности
<Компонента CRM>
необходимо разработать форму с составом полей ..., на форме расположить кнопку сканирования документа...
обеспечить взаимодействие со сканером... описание схемы взаимодействия отсыл к требованию ИНТ1.

Обратите внимание, что когда вы начали говорить, что необходимо разработать (а не какими внешними свойствами должно обладать разработанное), вы вывалились из роли аналитика-проектировщика в роль тимлида-менеджера проекта, который ставит задачи разработчикам. Зачем?

<Компонента ЛК (Личный кабинет Web интерфейс)>
В ЛК создать учетную запись клиента с логином соответствующим номеру ЛС, пароль сгенерировать...

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

Вопрос 3.
-в SRS должны попасть ФТ1 и ИНТ1, но например ИНТ1, может быть очень большим, нужно ли в SRS тащить  подраздел "Описание протокола взаимодействия", или достаточно описания? Аналогочно для схемы которая может быть достаточно большой.

Вы можете описать сценарии взаимодействия со сканером в приложении к SRS, а можете сделать отдельный документ по описанию интеграций.

199

Системный Анализ и Требования / Re: управление требованиями

« : 07 Января 2016, 13:02:45 »

Обратите внимание, что все ваши вопросы не про управление требованиями, а про разработку требований.

Добрый день!
Денис, благодарю за ответ!
Попробую переложить вопросы на пример. Общее описание - создается некоторая система. В этой системе оператор должен выполнять множество действий, возьмем пока
одну из задач - регистрация клиента.
В процессе регистрации оператор
- печатает форму договора которая передается клиенту для заполнения,
- вносит в систему данные о клиенте - ФИО, адрес, семейное положение и тд.д.
- а так же выполняет сканирование документа клиента и данный скан прикрепляется к карточке клиента.
Теперь это попробую разложить в виде требований и документов как я это вижу. Вопросы по тексту.
Цели проекта пока опущу. Начинаем с пользовательского требования.

1. Пользовательское требование -
Идентификатор: ПТ1.
Заголовок: - Регистрация клиента.
Описание:
система должна обеспечивать возможность зарегистрировать нового клиента.
Вопрос1. Нужно ли тут расписывать полностью все действия описанные в шапке
-1.1.печать договора,
-1.2. сканирование документа клиента...?
- 1.3.нужно ли описывать тут состав данных которые оператор вносит в систему?
Т.е. например так "в процессе регистрации оператор должен распечатать форму договора и переадть её для подписи клиенту.
Оператор должен отсканировать паспорт клиента и данный скан сохранить как приложение к карточке клиента, внести в систему данные - ФИО.."?

Диаграмма процесса:
Например есть диаграмма процесса она прикрепляется к данному требованию.

"Нужно ли описывать… " — ответ зависит от того, чем вы занимаетесь.

А. Вы пытаетесь сформировать набор требований для выбора готовой системы?
Б. Вы пытаетесь создать набор требований для предварительной оценки подрядчиком / командой?
В. Вы пытаетесь поставить задачу на проектирование системы?
Г. Вы пытаетесь поставить задачу на разработку системы?

В случае А вам возможно не нужна такая детализация.
В случае Б она полезна.
В случаях В-Г она необходима.

Вопрос 2. Требование к форме отчета "Договор клиента" это отдельное требование?

"Печать договора", "сканирование документа клиента" — это не части одного пользовательского требования, а отдельные требования, подчинённые ему.

Вигерс различает такие требования как пользовательские и функциональные. Я считаю такую классификацию неудачной и называю их:
- Пользовательское функциональное требование (описание результата, нужного пользователю)
- Техническое функциональное требование (обеспечивают реализацию пользовательского ФТ)

Форма отчёта — это тоже отдельное, но подчинённоё НФТ.

200

Системный Анализ и Требования / Re: управление требованиями

« : 05 Января 2016, 02:22:54 »

Уважаемые форумчане, 
по работе появилась необходимость разобраться с управлением требованиями, но тема для меня новая, помогите пожалуйста разобраться.
Читаю Вигерса "управление требования к ПО" и не все понятно. В указанной книге есть следующая схема http://iiba.ru/wp-content/uploads/2013/04/requirement_types.jpg. Собственно вопросы по ней
1. В книге сказано "Спецификация требований к ПО может представлять собой отчет, сгенерированный на основе информации, хранимой в средстве управления требованиями." т.е. это сводный документ который содержит множество требований. Пример и структура этой спеки в книге есть. А что из себя тогда представляют сами отдельные требования (например функциональные, требования к интерфейсам...). Какая структура у них?

Типовая структура требований выглядит как "Система должна … <утверждение о необходимом функциональном поведении системы>" или "система должна позволять … <утверждение о возможности, предоставляемой пользователю или внешней системе>. Например:

"Система должна вести журнал всех действий пользователя" или
"Система должна позволять создавать новые Проекты".

Из каких частей отдельных требований формируется "Спецификация требований к ПО"?

Не очень понял вопрос. Вы же сказали, что ознакомились со структурой документа у Вигерса?

Спецификация требований содержит требования в формате, указанном выше, а также в табличных и графических форматах согласно структуре спецификации.

Как это выглядит в промышленных RMS?

Зайдите на сайт любой промышленной RMS и ознакомьтесь с демо-материалами. Если не найдёте — спросите у них. Там есть специально обученные люди, которые получают за это зарплату, чтобы вам было всё понятно.

2. Что из себя представляет документ "Документ о вариантах использования" (в моем бумажном экземпляре книги этот документ называется "Документ пользовательских требований"). Для кого он предназначен? Можете ткнуть в пример такого документа?.

И снова я не понимаю. У Вигерса же есть пример такого документа в книге? Вы его видели?

3. Правильно понимаю, что в общем случае документы "Документ об образе и гарницах", "Документ о вариантах использования", "Спецификация требований к ПО" заменяют ТЗ (если например заказчик не настаивает именно на ТЗ)?

Для ПО — да, заменяет. Только "Образ и границы проекта" ближе к документам "устав проекта" и "концепция ПО", чем к ТЗ.

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

201

Идеи и мозговой штурм / Re: Какого софта не хватает аналитику сегодня

« : 01 Января 2016, 13:53:53 »

Под профилем качества я имею в виду профиль качества: http://www.slideshare.net/maieutic/ss-35127562

202

Идеи и мозговой штурм / Re: Какого софта не хватает аналитику сегодня

« : 31 Декабря 2015, 13:32:53 »

существует много компьютерных программ для аналитике

да, для аналитики много, для анализа мало

Чего не хватает:
Чтобы редактор требований мог полуавтоматически выделять функциональные требования из сценариев и связывать их друг с другом.
Чтобы редактор требований мог полуавтоматически выделять объекты из текста требований и проставлять ссылки на словарь данных.
Чтобы редактор требований создавал матрицу покрытия объектов функциональными требованиями и подсказывал, какие требования пропущены.
Не хватает программы, которая позволяла бы быстро создавать комплект типовых требований к качеству, опираясь на выбранные класс системы и  профиль качества.
Это может быть, например, плагин для Google Docs.

Много всего интересного есть в докладе Гриши Печёнкина про СУТ: http://habrahabr.ru/company/sqalab/blog/217737/

203

Конференции Семинары и Тренинги / Re: Онлайн-курс «Практический анализ и моделирование на UML»

« : 26 Декабря 2015, 11:19:06 »

Следующий курс пройдёт с 23 января до 14 февраля

204

Конференции Семинары и Тренинги / Re: Онлайн-школа разработки ТЗ

« : 18 Декабря 2015, 23:50:13 »

Ближайшая школа пройдёт в зимние праздники с 4 по 9 января 2016 года.

205

Для всех / Re: Выбор UML диаграммы

« : 02 Ноября 2015, 17:01:51 »

https://www.google.ru/search?q=uml+swimlane&newwindow=1&espv=2&biw=1466&bih=932&source=lnms&tbm=isch&sa=X&ved=0CAYQ_AUoAWoVChMIyNK4sPPxyAIVReFyCh3taAVS#

206

Для всех / Re: Выбор UML диаграммы

« : 02 Ноября 2015, 16:08:16 »

Примеров множество в гугле по запросу workflow diagram: https://www.google.ru/search?q=workflow+diagram&newwindow=1&espv=2&biw=1466&bih=932&source=lnms&tbm=isch&sa=X&ved=0CAYQ_AUoAWoVChMI2Lq9sefxyAIV6epyCh3RowRW

207

Для всех / Re: Выбор UML диаграммы

« : 02 Ноября 2015, 16:06:47 »

А почему обязательно UML, а не ARIS, BPMN, IDEF?

208

Конференции Семинары и Тренинги / Re: Онлайн-курс «Практический анализ и моделирование на UML»

« : 01 Ноября 2015, 23:23:26 »

На ноябрьский курс есть ещё 2 места

209

Конференции Семинары и Тренинги / Re: Курсы Системного анализа для практикующих аналитиков

« : 30 Октября 2015, 20:06:31 »

хотелось бы получить теорию, систематизировать знания

для этого не надо тратить столько денег, есть литература, которую можно приобрести дешевле

идея того, чтобы 10 человек из Москвы, например, собирались в одном месте и слушали, как одиннадцатый человек стоит и пересказывает им книжки, в 21-м веке выглядит очень странной. и растратой денег компании.

но если цель именно растратить, то тут конечно все средства хороши.

210

Конференции Семинары и Тренинги / Re: Курсы Системного анализа для практикующих аналитиков

« : 30 Октября 2015, 20:03:32 »

Также есть несколько курсов на тему у Интерфейса: http://www.interface.ru/iservices/training.asp?kId=*&cId=31