16

Системный Анализ и Требования / Re: Временные затраты. У кого какие?

« : 27 Февраля 2013, 13:23:35 »

На концепцию обычно стоит тратить от недели до месяца.

Собственно из-за этого и возник сам вопрос. Сказали сделать концепцию для оценки трудозатрат на разработку. На все отвелось 10 - 12 часов. Конечно в самой идеологии возникли неточности, т.к. за это время не успел ни пообщаться с заказчиком, ни хотя бы "переспать" с тем что сделанно и т.д. Поэтому и решил поинтересоваться хотя бы примерные цифры.

17

Системный Анализ и Требования / Временные затраты. У кого какие?

« : 27 Февраля 2013, 11:49:25 »

Всем - здравствуйте. Понимаю, что многие сейчас начнут закидывать меня фразами "все задачи разные" и будут, собственно, правы, но вопрос следующий:
сколько времени минимально необходимо для разработки требований скажем на портал типа "Хабрахабр" и вообще какой минимальный срок вы закладываете даже на самые небольшие системы?

18

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

« : 27 Февраля 2013, 11:44:57 »

Уже коплю деньги и жду следующий курс 

19

Задачи студентов / Re: Разработка системы "Фоторобот"

« : 21 Января 2013, 12:25:45 »

Так же хотел выразить благодарность ув. Galogen. Очень подробно все расписываете и, как по мне - правильно. Так что ваши ответы полезны не только автору темы - еще раз спасибо.

20

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

« : 14 Января 2013, 17:35:29 »

Планируется ли повторение данного курса в дальнейшем, так как сейчас нет финансовой возможности на него попасть ?

21

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

« : 26 Декабря 2012, 15:33:02 »

Интересно, что нибудь надумали?

Я разделил всё ТЗ на 2 основных части: "Добавляемые компоненты" и "Модифицируемые компоненты".
Справочники, сделал попытку описать, в формате:
1. Структура справочника. Описываю ее в виде таблицы: (Имя поля   | Тип | Отображается на странице списка | Отображается на странице редактирования   | Заполнение обязательно);
2. Функциональные требования
Вот здесь у меня куча сомнений.. Например, можно ли отнести к функциональным требованиям требование вида: "Для пользователя роли "такой-то" на странице справочника должен отображаться фильтр по "такому-то" полю.
3. Макеты страниц. Для справочников я решил что необходимо приводить макеты "страницы списка" и "страница редактирования элемента".

Был бы очень признателен, тому кто приведет конкретный пример требований на справочник. Например каталог книг, в системе учета книжного магазина, в котором есть поиск по наименованию, автору. Структура "Название, Автор, год". Соответственно обладать должен стандартными Add/Edit/Delete. Но каждой книге должен соответствовать список книг похожих на нее(для упрощения - эти книги забивает администратор).

22

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

« : 20 Декабря 2012, 15:36:12 »

Следующие вопросы
1. ТЗ на существующую систему есть? Согласовано?
2. Данный вопрос  больше на стороне технических писателей и вашей договоренностей с Заказчиком

ТЗ есть, но оно, как бы лучше выразится, на первый этап. По нему все сделанно, сейчас начинается 2-й этап работы, в котором есть как доработка/изменение существующего функционала, так и добавление абсолютно новых компонентов. Например, нужно добавить справочник "SomethingRef". Вообщем нужно думать.

23

Системный Анализ и Требования / ТЗ на доработку

« : 19 Декабря 2012, 17:13:36 »

Вообщем, по роду своей деятельности столкнулся с разработкой ТЗ на доработку системы "ХYZ". И опять возникли вопросы как оформить сам документ. Стандартное ТЗ предполагает что мы описываем функциональные требования и дополнительную мишуру. Но вот как оформить банальный запрос заказчика: "Удалить реквизит "Х" с формы документа "Y", а поведение реквизита "Z" нужно модифицировать так-то и так-то". Это ведь не функциональное требование, а придумывать из головы разделы не хочется, например, "Модификации форм документов" -> Документ "Y" -> описание то, что необходимо выполнить. Может есть какие-ниюудь "ГОСТированные" разделы?

24

Системный Анализ и Требования / Re: Использование ВИ и функциональных требований вместе/раздельно или как?

« : 06 Декабря 2012, 11:35:07 »

Спасибо, что откликнулись. Под "способами применения" вы понимаете варианты использования?
Да
Цитировать
и по пункту № 2, то есть в ТЗ должено существовать функциональное требование «Система должна позволять выбирать адресатов письма из адресной книги» и параллельно с ним, в отдельном файле может быть ВИ «Выбор адресатов».
Да, в ТЗ можно указать ФТ «Выбор адресатов из адресной книги», вот только выявлять его, как вы правильно писали раньше, удобнее через разработку набора способов применения, относящихся к фиче «Отправка писем». Например, через разработку способа применения «Отправить письмо».

«Выбор адресатов» — это вообще не ВИ, это его шаг. Способ применения — это, ради чего происходит сеанс работы в системе.

Цитировать
ВИ обязательно нужно согласовывать с заказчиком ?
В общем случае да, но обычно он делегирует эту функцию своим экспертам.

Спасибо за исчерпывающие ответы! Теперь все устаканилось.

25

Системный Анализ и Требования / Re: Использование ВИ и функциональных требований вместе/раздельно или как?

« : 04 Декабря 2012, 12:20:31 »

В книге "Путь аналитика", насколько я помню, предлагается способ:

1. Высокоуровневые требования.
2. Варианты использования, поясняющие эти требования.

Именно по такому принципу я в последнее время и формирую спецификации.

Да, тоже это читал, но не представляю как это уложить в ТЗ.

26

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

« : 04 Декабря 2012, 11:48:21 »

Спасибо всем за ответы. Пока еще не сделал вывод для себя как все же это реализовать правильно, но пока и проекта рабочего нет.

27

Системный Анализ и Требования / Re: Использование ВИ и функциональных требований вместе/раздельно или как?

« : 04 Декабря 2012, 11:44:54 »

IMHO Вы неверно понимаете суть ВИ. ВИ - это способ реализации требования, т.е. своего рода проектное решение верхнего уровня (с точки зрения использования программы). Для реализации одного и того же требования разные проектные группы могли бы придумать и реализовать разные ВИ, решающие одну и ту же задачу.

Таким образом, в ходе разработки ВИ не выкидываются, а "прорабатываются вглубь". На основе некоторых (или даже многих) ВИ действительно можно разрабатывать тест кейсы, но это не означает, что все тест кейсы должны разрабатываться только на основе ВИ. И вообще-то тесты лучше разрабатывать не программистам-разработчикам системы, а специализирующимся на тестировании тестировщикам (в старых книжках, типа PeopleWare, упоминается т.н. "Черная команда").

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

28

Системный Анализ и Требования / Re: Использование ВИ и функциональных требований вместе/раздельно или как?

« : 04 Декабря 2012, 11:42:18 »

Давайте возьмём 2 верхних уровня функциональных требований (без технических):

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

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

Спасибо, что откликнулись. Под "способами применения" вы понимаете варианты использования?  и по пункту № 2, то есть в ТЗ должено существовать функциональное требование «Система должна позволять выбирать адресатов письма из адресной книги» и параллельно с ним, в отдельном файле может быть ВИ «Выбор адресатов». ВИ обязательно нужно согласовывать с заказчиком ?

29

Системный Анализ и Требования / Re: Использование ВИ и функциональных требований вместе/раздельно или как?

« : 03 Декабря 2012, 18:04:54 »

включать в ТЗ ВИ не имеет смысла. ВИ - это способ реализации, а ТЗ - набор требований. Требовать надо не столько КАК должно быть сделано, а ЧТО должно быть сделано. По большому счету система для заказчика представляет собой "черный ящик", ему не очень важно, что внутри...
К тому же в случае изменения требований будете и ВИ переписывать?
Плюс к этому, не забывайте о необходимости проверять соответствие требованиям (ПМИ и т.п.).

Благодарю за ваше мнение. Но тогда у меня возникает вопрос: получается, что ВИ я создаю для выявления и конкретизации функциональных требований, так? И дальше (если требования составлены без ошибок), созданные ВИ остаются не нужными, за исключением использования их для тест кейсов или просмотра их программистами ?

30

Системный Анализ и Требования / Использование ВИ и функциональных требований вместе/раздельно или как?

« : 03 Декабря 2012, 16:27:19 »

Господа и дамы, очень интересует как вы совмещаете варианты использования и функциональные требования для проектируемой системы. Я все никак не могу определиться, стоит ли в ТЗ включать и полный набор функциональных требований и все ВИ. Или, например, проработать функциональные требования верхнего уровня, а конкретизировать все с помощью ВИ или все описать в виде ВИ. Что можете посоветовать из своего опыта? Для каких систем, какой метод лучше, как считает? Надеюсь, что корректно выразил свою мысль.