1
Обучение / Re: Онлайн-курсы на английском языке
« : 22 Апреля 2016, 07:49:11 »
Спасибо!
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Так вы сначала определите ЧТО заказчик хочет увидеть в вашей "спецификации технических требований"? IMHO всего лишь все зависит от степени детальности описания. Или вам важнее соблюсти некую формальную букву хоть какого-нибудь официального стандарта, чем создать документ для работы?Да получается замкнутый круг, вот и пытаемся изобрести велосипед . Спасибо за рекомендацию, попробуем и так сделать и показать заказчику.
То что вы написали выше: "входные и выходные данные, прототипы интерфейса" делают документ "техническим", а его заказчику трудно читать. Замкнутый круг получается.
Вы в России? Почему не подходит ГОСТ 34.602-89? Там вполне четкая структура требований. Ну выкиньте "слишком технические" разделы и обзовите это ТТ.
Почему спецификация требований IEEE не принимается? Кем не принимается? Вами, заказчиком, программистом?Спасибо за примеры.
Пример от Джоэла Сполски:
http://www.joelonsoftware.com/articles/WhatTimeIsIt.html
Пример от Карла Вигерса:
http://www.tol.oulu.fi/kurssit/otekniikka/papers/COS_use_cases.pdf
Наверное Вам подойдут сценарии использования. Результат -- описание алгоритма, понятное и заказчику, и разработчику. Шаблоны есть и на uml2, и в интернете.Сценарии использования будут в СТ. Еще в эту спецификацию. надо поместить входные и выходные данные, прототипы интерфейса. Вот и стоит проблема чтобы это было наглядно и понятно заказчику. А заказчику трудно читать такой технический докмент, вот и думаем как облегчить для него восприятие.
Что Вы понимаете под "техническими требованиями"?Опечатка, извиняюсь. "Спецификация требований"
Я знаю классификацию требований Вигерса и там нет никаких "технических требований".