Сквозная задача по разработке ТЗ

спасибо

http://forum.tehdoc.ru/
Пытался как-то наладить контакты с главкомом этого форума, но что-то дружба не получилась - неконструктивную и необъяснимую позицию товарищ занял, в отличие от Миши Острогорского.

наверно я что-то пропустил или не обратил внимания. где такой форум?
(раздел безопасности в ПМИ требуется оформить)

Формулируйте.

Есть еще пара форумов по схожей тематике - форум компании Философт и форум специалистов по безопасности труда (там можно многое почерпнуть для разделов безопасности ТЗ). Но этот форум, как показали почти два года с момента основания, пока уникален.

Спасибо большое за предложение.
Они (вопросы=проблемы) есть, но пока никак не сформулирую.
Ну, хоть радость: нашла, где их можно задать.

А дальше Рикки справилась с поставленной задачей и тема увяла сама собой. Задавайте вопросы - развивайте тему.

Читала
Мне помогло
Спасибо

Всё равно мне интересно, что было дальше (развитие этой темы)

А почитайте пока то, что уже есть
http://authorit.ru/?c=8&b=3

А дальше ?

Ну уж нет!
Давайте не будем говорить о том, кто и что пытается! Я НИКОГДА не пытаюсь искать черную кошку в темной комнате, отвечайте за свои, а не мои, попытки, плииииз! Тараканы у меня есть и много, но несколько другие...

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

Я, в общем-то, и сквозную задачу для того придумала, чтобы напихать разнокалиберной довольно информации в кучу. Я даже, кажется, начала понимать, ЧТО меня не устраивает... Surgeon классно все разложил по полочкам, но на маленьком примере все просматриваемо, как только начинаю описывать довольно-таки разные задачи в одном ТЗ, все, что делилось до этого на вроде уже понятные пункты, начинает, наоборот, ссыпаться в одно место...

потому что все очень просто написано, а просто у нас не бывает. Вы пытаетесь читать между строк, а там ничего нет, вот и обманом кажется

Еще как! Я ж Вам высылала то, что пишу слету, даже не просматривая сама, что пишу.
ОК!

Посмотрел. Формально попридираться можно, но пишите пока дальше. Как только задачи и функции определятся окончательно, высылайте, правку свою внесу, чтобы сейчас не делать двойную работу.

Спасибо, учту пожелания.

Наверное... просто я хотела сначала разбить по задачам и каждую конкретизировать, а потом описать и все общее для них

Ага, только пару слов о том, что это все зачем-то разбито надо было сказать

неа, не СОСТАВ - я тут только перечисляю, а не говорю, из чего они состоят, но и НЕ комплекс, согласна. Наверное, тоже перечень.

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

ГОСТ надо без №

общие требования д.б. выше всех остальных

не, перечисление д.б. просто перечнем, списком и т.д. И кроме списка ничего содержать не должен. Другое дело, что задачи должны быть взаимно-ортогональны, взаимонезависимы.
Вместо "название" лучше "наименование". Так звучит формальнее, ведь это же ТЗ

Комплекс выполняемых функций - состав выполняемых функций. Комплекс - это штука тонкая, ну её.
В целом мне понравилось. Когда будет итоговый релиз - высылайте, минимально подкорректирую в плане унификации и формализации.

Ага, получил, щас изучу.

Лучше получите то, что я вот сейчас вышлю - это то, что в настоящее время в работе, но там накидано, что и как будет в нескольких задачах описано. И первая задача почти формализована. (выделение желтым - это мои вопросы к Заказчику, не обр. внимания )

Ага, получил, щас изучу.

А на самом деле молчу, потому что сама обещала сделать ТЗ на основе задания в этом топике, а пока руки не дошли ))

Все же - что больше всего смущало в ГОСТовском виде, так это перечисление всех функций для всех задач в одном подразделе.
Когда Вы это делали как пример, все отлично, как только начинаю сама, фигня - и не потому, что тупая или недостаточно вникаю в задачу или стандарты, а потому что задач много, и они очень разные... И, хоть Вы стремитесь все разложить по пунктам, получается наоборот - в одном пункте свалены в кучу и таблицы из одной задачи, и формы из другой, и временнЫе функции из третьей.

В общем-то не отклоняясь от ГОСТов (хотя мне-то как раз и можно) - там сказано, что разделы при необходимости можно объединять или добавлять, я сделала некое подобие ТЗ. которое (пока) меня устраивает больше ГОСТовского, т.к. в нем есть (как я думаю) самый главный пункт, которого не было в ГОСТе - ПОСТАНОВКА ЗАДАЧИ.

Могу прислать начало (чтобы было что покритиковать )

Типа того... Как раз пишу ТЗ в том виде, как я думаю - по задачам... Пишу и смотрю, что же получится?

А я вроде Вам что-то посылала?

Что-то Вы, дорогой корнет, пропали совсем... Тайные подлости ищете?

А тут есть фишка такая. Заказчик-то чего-то хочет, а сформулировать не может (как правило). Исполнитель и обязан перевести хотелки на нормальный технический язык и убедить Заказчика, что текст Тз - то, что на самом деле хочет Заказчик. Так было, есть и будет всегда.

А теперь, когда в голове прояснилось, смотрим, что я наваял пальцами.

Во-первых, очертил круг задач.

Во-вторых, просто перечислил функции, которые должны выполняться для решения поставленной задачи.

Далее расписал, что должна делать каждая функция.

Затем расписал общие требования к выходным данным, после чего - требования к входным данным по каждой функции отдельно. То же самое проделал со входными данными.

И, наконец, расписал веременнЫе характеристики по каждой функции - что и когда каждая функция выполняет, какова последовательность выполнения функций - фактически алгоритм работы программы.

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

И никаких тайных подлостей. Заказчик, если он не совсем идиот, должен все понять.

причем, слепить НЕЧТО, это не значит, слепить АБЫ ЧТО!!! Я хочу, чтобы это было НЕ ХУЖЕ!!!!

Блин! Я АБСОЛЮТНО СОГЛАСНА, что все прозрачно, может, это что-то не так со мной :? Может, я хочу того, не знаю чего... я написала всего три штуки ТЗ, примерно в таком же виде (по Вашему первому шаблончику) все их подписали, начальник доволен, а я нет. все переговоры занимали СЛИШКОМ много времени, каждый участник что-то понимал для себя, и тогда можно было понять и ТЗ. Я хочу не так, а чтобы задачу можно было восстановить по ТЗ, читая "назад". То есть, разработчик, не принимая участия в переговорах, должен понимать, что хочет заказчик, а не какие функции будет выполнять программа, чтобы заказчик все же видел текст в близких к его заданию терминах.
Может, потому нам трудно понять друг друга, что мне позволяется думать, не как в ГОСТе, вот я и хочу и нашим и вашим... слепить нечто...

Может, пройдемся по пунктам и посмотрим, где это я кого кидаю Все честно, предельно детализировано и формализовано. На любую предъяву готов держать ответ.

Просто взял и растащил задачу по разделам, отдельно перечень функций, отдельно требования к каждой из функций и т.д. - все по отдельности. Все прозрачно, все читабельно. Да и с ПМ в дальнейшем проблем не возникнет, поскольку каждая мелочь сидит отдельно и отдельно ее можно будет испытать.

ммммда... Туго. Вроде все по правилам, а впечатление какого-то обмана, что ли... Сейчас, допишу сама и вышлю почтой с разъяснениями, чего я пытаюсь добиться... Только есть подозрения, что мы не понимаем друг друга...

Здесь страниц на несколько. Заодно мозги разомну, чтобы не ржавели

1.1. Требования к функциям (задачам), решаемым программой

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

В рамках указанной задачи программа должна обеспечивать выполнение перечисленных ниже функций:

а) функции отображения сообщений;
б) функции программирования времени отображения;
в) функции фиксации реакции пользователя;
г) функции отключения компьютера;
д) и т.д.

1.1.1. Требования к функции отображения сообщений

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

1.1.2. Требования к функции программирования времени отображения сообщений

Указанная функция должна обеспечивать возможность (администратору) программирования времени отображения сообщений.

1.1.3. Требования к функции фиксации реакции пользователя

Указанная функция должна обеспечивать возможность ввода пользователем ответа на сообщение программы взаимодействием с графическим пользовательским интерфейсом (в диалоговом окне).

1.2. Требования к выходным данным

Выходными данными программы должны быть текстовые сообщения пользователю.

1.2.1. Требования к выходным данным функции отображения сообщений пользователю

Выходными данными указанной функции должны быть перечисленные ниже текстовые сообщения:

а) сообщение «Вы уже на работе?»;
б) сообщение «Кушать подано!»;
в) сообщение «Пользователь такой-то отсутствует»;
г) сообщение «Пользователь такой-то на месте»;
д) сообщение «Пользователь такой-то опоздал»;

1.3. Требования к входным данным

Входными данными программы должны быть:

а) реакция пользователя на полученные им сообщения;
б) данные, вводимые администратором.

1.3.1. Требования к входным данным функции программирования времени отображения

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

1.3.2. Требования к входным данным функции фиксации реакции пользователя

Входными данными указанной функции должны быть события взаимодействия пользователя с графическим интерфейсом (реакция пользователя на сообщения программы).

1.4. Требования к временным характеристикам работы программы

1.4.1. Требования к временным характеристикам функции отображения сообщений

Указанная функция должна обеспечивать:

а) вывод сообщения 1.2.1 (а) ежедневно в 09.30;
б) при отсутствии после 10.00 реакции пользователя – вывод администратору сообщения 1.2.1 (в);
в) в случае реакции пользователя на сообщение с 09.30 до 10.00 – вывод администратору сообщения 1.2.1 (г);
г) в случае реакции пользователя на сообщение после 10.00 – вывод администратору сообщения 1.2.1 (г);
д) вывод сообщения 1.2.1 (б) и инициализацию выполнения функции отключения пользовательского компьютера в течение 1 мин;
е)

Как-то так написал бы.

Сквозная задача.
1. У моих сотрудников на экране в 9.30 утра должно открываться окно с вопросом «вы уже на работе?». При ответе «Да», программа должна посмотреть время ответа. Если оно больше 10.00, информация об этом должна прийти ко мне, а я к концу дня укажу, давать ли предупреждение сотруднику (это зависит от того, отпрашивался ли сотрудник). После трех предупреждений в бухгалтерию посылается письмо с требованием снять 25% премию данному сотруднику. После 2-х снятий премии информация об этом приходит ко мне, а сотруднику высылается предупреждение о возможном увольнении.
2. В два часа дня появляется предупреждение, что у меня обед, когда я жму «знаю», компьютер отключается на 0,5 часа
3. В 15.00 предупреждение о том, что пора проверять расчеты. если я жму «нет», предупреждение уходит и появляется в 16 и 17 часов. Если и в 17 часов – нет, то только завтра в 15.00
4. Если я жму «да», то мне открывается список договоров, я выбираю нужный, мне открывается список статей расходов и условий по этому договору, я рассчитываю сумму. Далее я вызываю список договоров из таблицы Excel, выбираю нужный и сравниваю расчеты. Если расчет мне не нравится, отправляю письмо менеджеру по расчетам.
5. В 19.00 у меня появляется зелененькое предупреждение о том, что пора домой.