Подскажите пожалуйста, какие есть в сети хорошие материалы по вопросу разработки требований к ПО? Желательно в электрическом виде
Интересуют все возможные аспекты этого вопроса.
Если кто-то имел практический опыт разработки требований, буду БЕЗМЕРНО благодарен за информацию, как вы это делали.
12.11.07 19:44: Перенесено модератором из 'Философия программирования' — IT
Здравствуйте, StevenIvanov, Вы писали:
SI>Подскажите пожалуйста, какие есть в сети хорошие материалы по вопросу разработки требований к ПО? Желательно в электрическом виде
Здравствуйте, StevenIvanov, Вы писали:
SI>Всем доброго времени суток!
SI>Подскажите пожалуйста, какие есть в сети хорошие материалы по вопросу разработки требований к ПО? Желательно в электрическом виде SI>Интересуют все возможные аспекты этого вопроса.
SI>Если кто-то имел практический опыт разработки требований, буду БЕЗМЕРНО благодарен за информацию, как вы это делали.
SI>Подскажите пожалуйста, какие есть в сети хорошие материалы по вопросу разработки требований к ПО? Желательно в электрическом виде SI>Интересуют все возможные аспекты этого вопроса.
Ещё там есть ссылка на куцую русскую статью, но оттуда идёт довольно толковая ветка по технологии разработки ПО.
А в ссылках есть, к примеру, вот этот форум: http://www.uml2.ru/forum/index.php?board=18.0
Верхние ветки оттуда:
-Лучшие веб ресурсы по требованиям
-FAQ — Требования
-Как Вы описываете требования к ПО?
и т.д.
Вообще работу с требованиями надо начинать примерно так:
— со стороны заказчика должен быть выделен "хозяин требований" — в его служебные обязанности менеджмент заказчика должен включить ответы на вопросы разработчиков, бегания по разным отделам заказчика
— с вашей стороны надо определиться в каком процессе вы разрабатываете
— если это agile — почитайте как пишутся требования для agile, это подход к написанию требований ОЧЕНЬ серьезно отличающийся, если любой "тяжелый процесс" — берите шаблоны RUP и вперед.
Далее, устаканив все эти орг вопросы выясняем business vision и начинается самое интересное — выясняем два главных вопроса:
— кто пользуется приложением (actors)
— что он там делает (не забываем ориентироваться на конечную цель его действий)
Иногда эти выяснения могут занимать месяцы, это нормально.
Все это пишем по возможности человеческим языком и рисуем эскизы GUI, если требования не понятны "хозяину требований" — значит вы лезете в дизайн и архитектуру, это плохо по двум причинам:
1) заказчик не может понять требований и в связи с этим их может просто не читать вообще
2) вы навязываете архитектурные решения разработчикам, возможно не имея на это полномочий или не имея должного опыта проектирования или не поинтересовавшись их мнением
Здравствуйте, D_, Вы писали:
D_>Вообще работу с требованиями надо начинать примерно так: D_>- со стороны заказчика должен быть выделен "хозяин требований" — в его служебные обязанности менеджмент заказчика должен включить ответы на вопросы разработчиков, бегания по разным отделам заказчика D_>- с вашей стороны надо определиться в каком процессе вы разрабатываете D_>- если это agile — почитайте как пишутся требования для agile, это подход к написанию требований ОЧЕНЬ серьезно отличающийся, если любой "тяжелый процесс" — берите шаблоны RUP и вперед.
D_>Далее, устаканив все эти орг вопросы выясняем business vision и начинается самое интересное — выясняем два главных вопроса: D_>- кто пользуется приложением (actors) D_>- что он там делает (не забываем ориентироваться на конечную цель его действий)
При работе с требованиями нужно ответить на три вопроса.
1. ПОЧЕМУ нужно делать этот софт и какие проблемы он решает, каке потребности заказчика покрывает
2. ЧТО есть цели пользователей по отношению к системе, ЧТО делают пользователи ПО в системе для достижения своих целей и ЧТО связывает эти цели с потребностями.
3. ЧТО (а не КАК) делает система и насколько хорошо чтобы помочь пользователям достичь своих целей.
Далее, не процесс определяет то каким образом будет производиться работа с требованиями, а контракт с заказчиком. Если в контракте будет написано, что нужно выкатить ТЗ по ГОСТ 34.602, то работать можно хоть по ХР хоть по AIM хоть по RUP ... но написать ТЗ по ГОСТ придется .
Здравствуйте, byur, Вы писали:
B>При работе с требованиями нужно ответить на три вопроса. B>1. ПОЧЕМУ нужно делать этот софт и какие проблемы он решает, каке потребности заказчика покрывает B>2. ЧТО есть цели пользователей по отношению к системе, ЧТО делают пользователи ПО в системе для достижения своих целей и ЧТО связывает эти цели с потребностями. B>3. ЧТО (а не КАК) делает система и насколько хорошо чтобы помочь пользователям достичь своих целей.
B>Далее, не процесс определяет то каким образом будет производиться работа с требованиями, а контракт с заказчиком. Если в контракте будет написано, что нужно выкатить ТЗ по ГОСТ 34.602, то работать можно хоть по ХР хоть по AIM хоть по RUP ... но написать ТЗ по ГОСТ придется .
1 — это и есть business vision.
Ну а вопросы контракта с заказчиком — могу только сказать из опыта что бывает всякое разное. Сама суть проекта (в идеале) должна бы определять тип процесса, не все проекты вообще могут быть сделаны в agile, а многие просто не имеет смысла делать в heavyweight.
Здравствуйте, D_, Вы писали:
D_>1 — это и есть business vision.
Если оперировать терминологией, принятой в программной инженерии, то это просто Vision. Т.к. Business Vision -- термин уже определенный в том же RUP имеет отношение именно к бизнес-домену, а не столько к ассоциации с решением проблем бизнеса при помощи создаваемого ПО.
Здравствуйте, byur, Вы писали:
B>Здравствуйте, D_, Вы писали:
D_>>1 — это и есть business vision.
B>Если оперировать терминологией, принятой в программной инженерии, то это просто Vision. Т.к. Business Vision -- термин уже определенный в том же RUP имеет отношение именно к бизнес-домену, а не столько к ассоциации с решением проблем бизнеса при помощи создаваемого ПО.
Извините за столь поздний ответ. Замечание справедливое по формальным признакам, но не по смыслу Ибо сколько ни работаю в отрасли — единая терминология — это из области "сферических коней в вакууме". Например, текущий заказчик просит называть Vision в документах Business Case, потому что уверен что в индустрии разработки ПО именно это является общепринятым термином.
