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

Ранее используемый формат не устраивает. Решили работать по науке.

Аналитик пишет документ требований и передает его в отдел проектирования. Там требования изучаются и предлагаются проектные решения.

Сразу возникла проблема:
а/ формы представления требований
б/ способы добавления решений
с/ разделение труда

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

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

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

Хотя может так можно? Ведь требование пишется в конечном счете для программистов?

Поскольку пока форма не принята, задался вопросом, а как корректно писать требования.

Предложил такой подход.

Анализируя задачу смотрим на что в конечном итоге это должно влиять:
1. на форму счетов и расходных документов
2. на порядок и сроки их создания

Потому я предложил двигаться от конечного результата, типа.
1. Скидка по предоплате
  система должна обеспечивать возможность указания режима использования скидки по предоплате
  1.1. Величина скидки по предоплате - целое не отрицательное число
  1.2  Скидка действует до даты Х
        1.2.1 Дата Х - целое не отрицательное число в диапазоне от 1 до 30
  1.3 Скидка является внесубъектным свойством, т.е. задается один раз и распростарняется на все субъекты учета
  1.4 При формировании счетов указывается цена со скидкой для всех клиентов
2. Формирование счет-фактур и актов
   2.1 Есть фиксированная цена
         Для клиента с фиксированной ценой скидка по предоплате не применяется
   2.2 Есть задолженность
         Для клиента с задолженность скидка не применяется
   2.3 Оплата в срок
        При оплате до указанного срока (1.2.1) документы формируются со скидкой
        2.3.1 Оплата не полная
                Если опалте сделано в срок но не полностью, скидка не применяется и указывается долг клиента
        2.3.2 Оплата не в срок
                Если оплате не выполнена или выполнена после срока, скидка не применяется и указывается долг клиента

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

При этом данная структура загоняется в RaQuest или EA и формируется диаграмма для более наглядного представления и анализа согласованности...

Итак вопросы
1. Форма описания требований?
2. Следует ли разделять требования?
3. Что должен содержать документ, т.е. что понимать под спецификацией требований? (для заказчика документ не пишется и у заказчика соответственно не подписывается)
4.Не следует ли иметь то что есть и показать во что нужно изменить?
5. Как лучше группировать требования и выстраивать зависимости?
6. Следует ли предлагать ГУИ прототипы в качестве требований или их оставить для проектировщиков?
7. Что следует вносить в документ аналитику, а что проектировщику?

Может еще, что добавится после....

 

Эд, и я бы ничего не понял из такого описания требований ....
1. Вовсе не обязательно писать именно юзкейсы -- пиши просто сценарий или уж если юзкейсы, то в casual формате по Коберну.
2. Разделять на типы на типы можно только в том случае, если у тебя есть согласованный со всеми для данного проекта Requirements Management Plan, в котором будет расписано все про типы требований. Если в культуре компании нет такого -- лучше не делать, особенно если до этого не было евангелизма на эту тему.
3. Нафиг писать в виде отдельных требований типы данных (целое число, дата от 1 до 30 ... кстати а 31 числа не бывает?)? Это можно спокойно отдельно написать в словаре данных.
4 По-сути, того что ты написал: "Суть задачи такова:
Пожелания заказчика - для увеличения собираемости платежей по выставленным счетам ... предложена так называемая скидка по предоплате. Механизмом реализации такой скидки должен стать двуэтапный биллинг. Т.е. сначала печатаются и отправляются ..." практически все что нужно иметь на входе "проектировщику в контексте" ...

Эд, и я бы ничего не понял из такого описания требований ....
1. Вовсе не обязательно писать именно юзкейсы -- пиши просто сценарий или уж если юзкейсы, то в casual формате по Коберну.

можно

2. Разделять на типы на типы можно только в том случае, если у тебя есть согласованный со всеми для данного проекта Requirements Management Plan, в котором будет расписано все про типы требований. Если в культуре компании нет такого -- лучше не делать, особенно если до этого не было евангелизма на эту тему.

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

3. Нафиг писать в виде отдельных требований типы данных (целое число, дата от 1 до 30 ... кстати а 31 числа не бывает?)? Это можно спокойно отдельно написать в словаре данных.

В реальности этого и не было, это я включил просто для связки. Дата 31 бывает, но как конечная дата не используется, и вообще может быть требование что может быть число не более 20, не суть важно

4 По-сути, того что ты написал: "Суть задачи такова:
Пожелания заказчика - для увеличения собираемости платежей по выставленным счетам ... предложена так называемая скидка по предоплате. Механизмом реализации такой скидки должен стать двуэтапный биллинг. Т.е. сначала печатаются и отправляются ..." практически все что нужно иметь на входе "проектировщику в контексте" ...

Он это и имеет на входе в качестве контекста. Далее аналитик прикладывает правила, по которым формируется тот или иной документ при наличии тех или иных исключений.


Резюме.
Типы не важны сначала нужно покреститься. Окей.

Все велью в ответе нет. Вернее сказано не понятно. Окей как будет понятно?

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

Happy birth day, Yury

Юра Булуй, я тебя специально привлекаю к этой тебе, напоминаю. А так же и других интересно спросить.

Что хотелось бы в конечном виде получить - отзыв того кто по спекам прямо работает и что он думает о тех спеках, которые использует и почему они ему нравятся-не нравятся.

Далее - как лучше НАЧИНАТЬ писать требования, не то что какова формула хорошего требования, а именно как все требования вместе лучше структурировать и понятно доносить - помним что свойство целого <> сумме свойств его частей. Как раз в моем примере сумма требований оказалась не понимаема - за деревьями леса не увидали, хотя контекст определен - его точно подметил Юрий.

Эд,

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

Писать в любом случае в виде сценария более понятно.

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

Как это нет! Или что ты понимаешь под первоначальными требованиями?

Писать в любом случае в виде сценария более понятно.

Может я поверхностно объяснил, но как пишет Юра:

4 По-сути, того что ты написал: "Суть задачи такова:
Пожелания заказчика - для увеличения собираемости платежей по выставленным счетам ... предложена так называемая скидка по предоплате. Механизмом реализации такой скидки должен стать двуэтапный биллинг. Т.е. сначала печатаются и отправляются ..." практически все что нужно иметь на входе "проектировщику в контексте" ...

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