Уважавам много интереса ти към темата. Ако имаше повече хора, които се интересуват как трябва да се правят нещата нямаше да има толкова бъгове в софтуера.

За съжаление мога да ти помогна повече, ако знаех за какво конкретно се интересуваш: искаш да работиш във фирма за софтуер или имаш за задача да съдействаш при внедряването на система в предприятие?

Като цяло има два генерални подхода:

Фирмите, които внедряват системата са изправени пред следната дилема:
1/ Да купим или
2/ да си програмираме сами.


1/ Проектирането при тази възможност е много по-лесна и съответно по-скъпичка:
Сравняват се какво могат готовите продукти и фирмата си реорганизира работата спрямо тях.
Не трябва да се забравя, че това също не става от днес до утре:
при една сравнително голяма фирма /която може и да си позволи софтуер за няколко милиона евро/ процесът на внедряване трае около две години.

Това съответно не се прави от двама души, обикновено се ползват услугите на консултантски фирми. Ако почнеш в такава фирма е по-добре отколкото шестица от тотото. Научават се невероятни неща.


2/ При този вариант става интересно:
Проектирането е най-важната част от проекта. Тогава се събира екип от програмисти, софтуерни инженери, хора, които ще ползват системата или ще я администират, мениджъри и прочие.
Важно: иска се опит:
- при анализ на бизнес операцииите.
- при избиране на съответната технология.
- при определяне на екипа от програмисти и т.н.
- при определяне на бюджета.

Случвало се е проекти да се превръщат в тотални катастрофи, често заради :
- недостатъчна спецификация на софтуера
- надостатъчна документация /повечето забравят, че после системата трябва да се поддържа по време на ползването и увисват съc support-a/
- подценяване на сроковете /Цитат: А,бе, до утре съм го програмирал! След две седмици: Готов съм до 99%/
- вземане на решения от некомпететни лица /шефът определя какво да прави системата, без да е наясно КАК работят подчинените му/
- много, много други.

Какво сме ползвали като подходи /software process models/:
- Rational Unified Process (RUP)
- Catalysis
- KobrA
- Extreme Programming

На кой от тях ще се спре човек зависи от вида на системата.
Ако сериозно ще се занимаваш с проектиране не може да се размине без UML особено при обектно-ориентираното програмиране.

Затова:
Една книга, която всеки информатик трябва да е чел:
Ian Sommerville, Software Engineering

За RUP и UML:
Craig Larman, Applying UML and patterns

За UML като цяло - онлайн информация колкото искаш.

За съжаление на тези методи не се обръща подобаващо внимание в университетите /доколкото си спомням, поправете ме ако греша/.
Моят съвет към теб: най-добре се учат чрез работа във фирма, която прилага тези техники.

Ако пък си от другата страна - във фирмата, на която и трябва софтуера, можеш да се конкретизираш за каква система става въпрос. Така ще мога да ти дам съвети как да си направите спецификацията.