196
Sparx / Re: Генерация отчета для оценки трудоемкости
« : 12 Января 2016, 00:11:37 »
А при чём тут ТЭО?
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
2. Создается требование к внешнему интерфейсу (интегарция со сканером)Обратите внимание, что когда вы начали говорить, что необходимо разработать (а не какими внешними свойствами должно обладать разработанное), вы вывалились из роли аналитика-проектировщика в роль тимлида-менеджера проекта, который ставит задачи разработчикам. Зачем?
Идентификатор: ИНТ1.
Заголовок: - Интеграция со сканером.
Описание:
система должна обеспечивать возможность получить копию документа клиента со сканера. Для этих целей необходимо обеспечить
взаимодействие системы со сканером <Модель>.
Схема взаимодействия
<тут размещаем схему>
Диаграмма вызовов
<тут некоторый материал поясняющий кто кого вызывает и т.д.>
Описание протокола взаимодействия
<длинное описание протокола взаимодействия со сканером>
3. Теперь формируем функциональное требование на выполнение пользовательского требования регистрации клиента
Идентификатор: ФТ1.
Заголовок: - Регистрация клиента.
Для выполнения сценария регистраии клиента неоходимо реализовать соледующие функциональные возможности
<Компонента CRM>
необходимо разработать форму с составом полей ..., на форме расположить кнопку сканирования документа...
обеспечить взаимодействие со сканером... описание схемы взаимодействия отсыл к требованию ИНТ1.
<Компонента ЛК (Личный кабинет Web интерфейс)>Вы можете описать сценарии взаимодействия со сканером в приложении к SRS, а можете сделать отдельный документ по описанию интеграций.
В ЛК создать учетную запись клиента с логином соответствующим номеру ЛС, пароль сгенерировать...
4. Теперь нужно создать SRS. как писал в первом посте
В книге сказано "Спецификация требований к ПО может представлять собой отчет, сгенерированный на основе информации, хранимой в средстве управления требованиями." т.е. это сводный документ который содержит множество требований.
Вопрос 3.
-в SRS должны попасть ФТ1 и ИНТ1, но например ИНТ1, может быть очень большим, нужно ли в SRS тащить подраздел "Описание протокола взаимодействия", или достаточно описания? Аналогочно для схемы которая может быть достаточно большой.
Добрый день!"Нужно ли описывать… " — ответ зависит от того, чем вы занимаетесь.
Денис, благодарю за ответ!
Попробую переложить вопросы на пример. Общее описание - создается некоторая система. В этой системе оператор должен выполнять множество действий, возьмем пока
одну из задач - регистрация клиента.
В процессе регистрации оператор
- печатает форму договора которая передается клиенту для заполнения,
- вносит в систему данные о клиенте - ФИО, адрес, семейное положение и тд.д.
- а так же выполняет сканирование документа клиента и данный скан прикрепляется к карточке клиента.
Теперь это попробую разложить в виде требований и документов как я это вижу. Вопросы по тексту.
Цели проекта пока опущу. Начинаем с пользовательского требования.
1. Пользовательское требование -
Идентификатор: ПТ1.
Заголовок: - Регистрация клиента.
Описание:
система должна обеспечивать возможность зарегистрировать нового клиента.
Вопрос1. Нужно ли тут расписывать полностью все действия описанные в шапке
-1.1.печать договора,
-1.2. сканирование документа клиента...?
- 1.3.нужно ли описывать тут состав данных которые оператор вносит в систему?
Т.е. например так "в процессе регистрации оператор должен распечатать форму договора и переадть её для подписи клиенту.
Оператор должен отсканировать паспорт клиента и данный скан сохранить как приложение к карточке клиента, внести в систему данные - ФИО.."?
Диаграмма процесса:
Например есть диаграмма процесса она прикрепляется к данному требованию.
Вопрос 2. Требование к форме отчета "Договор клиента" это отдельное требование?
Уважаемые форумчане,Типовая структура требований выглядит как "Система должна … <утверждение о необходимом функциональном поведении системы>" или "система должна позволять … <утверждение о возможности, предоставляемой пользователю или внешней системе>. Например:
по работе появилась необходимость разобраться с управлением требованиями, но тема для меня новая, помогите пожалуйста разобраться.
Читаю Вигерса "управление требования к ПО" и не все понятно. В указанной книге есть следующая схема http://iiba.ru/wp-content/uploads/2013/04/requirement_types.jpg. Собственно вопросы по ней
1. В книге сказано "Спецификация требований к ПО может представлять собой отчет, сгенерированный на основе информации, хранимой в средстве управления требованиями." т.е. это сводный документ который содержит множество требований. Пример и структура этой спеки в книге есть. А что из себя тогда представляют сами отдельные требования (например функциональные, требования к интерфейсам...). Какая структура у них?
Из каких частей отдельных требований формируется "Спецификация требований к ПО"?Не очень понял вопрос. Вы же сказали, что ознакомились со структурой документа у Вигерса?
Как это выглядит в промышленных RMS?Зайдите на сайт любой промышленной RMS и ознакомьтесь с демо-материалами. Если не найдёте — спросите у них. Там есть специально обученные люди, которые получают за это зарплату, чтобы вам было всё понятно.
2. Что из себя представляет документ "Документ о вариантах использования" (в моем бумажном экземпляре книги этот документ называется "Документ пользовательских требований"). Для кого он предназначен? Можете ткнуть в пример такого документа?.И снова я не понимаю. У Вигерса же есть пример такого документа в книге? Вы его видели?
3. Правильно понимаю, что в общем случае документы "Документ об образе и гарницах", "Документ о вариантах использования", "Спецификация требований к ПО" заменяют ТЗ (если например заказчик не настаивает именно на ТЗ)?Для ПО — да, заменяет. Только "Образ и границы проекта" ближе к документам "устав проекта" и "концепция ПО", чем к ТЗ.
существует много компьютерных программ для аналитикеда, для аналитики много, для анализа мало
хотелось бы получить теорию, систематизировать знаниядля этого не надо тратить столько денег, есть литература, которую можно приобрести дешевле