Добрый день, уважаемые коллеги!
Подскажите пожалуйста. с помощью какого стандарта или примера можно составить спецификацию технических требований к автоматизации БП.
На входе есть БП, для него нужно составить СТТ, так чтобы было понятно и удобно читать заказчику (заказчик не технический специалист) и разработчику. Причем упор здесь на заказчика. Варианты: ТЗ, спецификация требований IEEE не принимаются . Заранее спасибо за информацию.

Что Вы понимаете под "техническими требованиями"?
Я знаю классификацию требований Вигерса и там нет никаких "технических требований".

Добрый день, уважаемые коллеги!
Подскажите пожалуйста. с помощью какого стандарта или примера можно составить спецификацию технических требований к автоматизации БП.
На входе есть БП, для него нужно составить СТТ, так чтобы было понятно и удобно читать заказчику (заказчик не технический специалист) и разработчику. Причем упор здесь на заказчика. Варианты: ТЗ, спецификация требований IEEE не принимаются . Заранее спасибо за информацию.

Наверное Вам подойдут сценарии использования. Результат -- описание алгоритма, понятное и заказчику, и разработчику. Шаблоны есть и на uml2, и в интернете.

Добрый день, уважаемые коллеги!
Подскажите пожалуйста. с помощью какого стандарта или примера можно составить спецификацию технических требований к автоматизации БП.
На входе есть БП, для него нужно составить СТТ, так чтобы было понятно и удобно читать заказчику (заказчик не технический специалист) и разработчику. Причем упор здесь на заказчика. Варианты: ТЗ, спецификация требований IEEE не принимаются . Заранее спасибо за информацию.

Почему спецификация требований IEEE не принимается? Кем не принимается? Вами, заказчиком, программистом?

Пример от Джоэла Сполски:
http://www.joelonsoftware.com/articles/WhatTimeIsIt.html

Пример от Карла Вигерса:
http://www.tol.oulu.fi/kurssit/otekniikka/papers/COS_use_cases.pdf

Что Вы понимаете под "техническими требованиями"?
Я знаю классификацию требований Вигерса и там нет никаких "технических требований".

Опечатка, извиняюсь. "Спецификация требований"

Наверное Вам подойдут сценарии использования. Результат -- описание алгоритма, понятное и заказчику, и разработчику. Шаблоны есть и на uml2, и в интернете.

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

Почему спецификация требований IEEE не принимается? Кем не принимается? Вами, заказчиком, программистом?

Пример от Джоэла Сполски:
http://www.joelonsoftware.com/articles/WhatTimeIsIt.html

Пример от Карла Вигерса:
http://www.tol.oulu.fi/kurssit/otekniikka/papers/COS_use_cases.pdf

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

Так вы сначала определите ЧТО заказчик хочет увидеть в вашей "спецификации технических требований"? IMHO всего лишь все зависит от степени детальности описания. Или вам важнее соблюсти некую формальную букву хоть какого-нибудь официального стандарта, чем создать документ для работы?
То что вы написали выше: "входные и выходные данные, прототипы интерфейса" делают документ "техническим", а его заказчику трудно читать. Замкнутый круг получается.

Вы в России? Почему не подходит ГОСТ 34.602-89? Там вполне четкая структура требований. Ну выкиньте "слишком технические" разделы и обзовите это ТТ.

Так вы сначала определите ЧТО заказчик хочет увидеть в вашей "спецификации технических требований"? IMHO всего лишь все зависит от степени детальности описания. Или вам важнее соблюсти некую формальную букву хоть какого-нибудь официального стандарта, чем создать документ для работы?
То что вы написали выше: "входные и выходные данные, прототипы интерфейса" делают документ "техническим", а его заказчику трудно читать. Замкнутый круг получается.

Вы в России? Почему не подходит ГОСТ 34.602-89? Там вполне четкая структура требований. Ну выкиньте "слишком технические" разделы и обзовите это ТТ.

Да получается замкнутый круг, вот и пытаемся изобрести велосипед . Спасибо за рекомендацию, попробуем и так сделать и показать заказчику.