[15:08] RAGDOLL [15:08] HALP [15:09] have you done dfds before [15:11] I made a couple after [15:11] finishing the project [15:11] to pretend I made documentation once [15:11] wai? [15:13] >after finishing the project [15:14] that's fucking awesome [15:14] I don't see why you'd make it beforehand unless you actually had preliminary checks by management required... [15:14] if the system is simple enough that it can be perfectly represented on the diagram before testing and implementation [15:14] it doesn't need the diagram [15:14] well yes, there are preliminary checks [15:14] and if it isn't and you're still good enough to make it [15:15] then /you/ don't need the diagram [15:15] rofl [15:15] oh then you're fucked [15:15] just make it really vague [15:15] and then ammend it afterwards and write about required changes [15:15] bitches love required changes [15:15] really? good thing my supervisor's female [15:15] ahue [15:16] =content storage= - commands > (program) - output > [output device] [15:16] there you captured all possibilities [15:17] as long as your program does something, that diagram defines it :3c [15:17] hmm, how would you approach the data flow of an rss? I don't know if I'm doing it right [15:18] the backend holds the data, the program generates the RSS feed from the data (possibly influenced by the user's input to the RSS generator script) the output is the RSS feed [15:18] ez right? [15:19] that's how I did it, yeah, do you think that's vague enough? [15:19] it can't really get more vague [15:19] it has approached the event horizon of vagueness [15:19] hmm, I see [15:20] if you need to put more detail in afterwards you just split the possible user commands into their own paths and add subroutines of the program as more (bubbles)