Спецификация технических требований к автоматизации бизнес-процесса(Прочитано 7978 раз)
Добрый день, уважаемые коллеги!
Подскажите пожалуйста. с помощью какого стандарта или примера можно составить спецификацию технических требований к автоматизации БП.
На входе есть БП, для него нужно составить СТТ, так чтобы было понятно и удобно читать заказчику (заказчик не технический специалист) и разработчику. Причем упор здесь на заказчика. Варианты: ТЗ, спецификация требований 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? Там вполне четкая структура требований. Ну выкиньте "слишком технические" разделы и обзовите это ТТ.
Да получается замкнутый круг, вот и пытаемся изобрести велосипед :). Спасибо за рекомендацию, попробуем и так сделать и показать заказчику.




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19