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