Why aren't you studying?

[Lager]

 

[Zim Hosein]

Because I'm not in school at the moment

 

[Kalvin00]

Because i'm replying to all these nm,delete, or mn threads.

 

[BigKev]

I'm too busy reading neffism.

 

[enjoi]

Cuz I'm fscking lazy and not motivated.

I suck at life.

 

[screw3d]

STFU.

 

[eLiu]

b/c i don't need to

 

[DXM]

I'll do it tomorrow.

 

[eakers]

im procrastinating

 

[johnjbruin]

Originally posted by: ISO
I'm too busy reading neffism.

 

[iamme]

Originally posted by: eakers
im procrastinating

i'm gonna procrastinate later.

 

[minendo]

Because I'm still in class for another 2 hours.

 

[huesmann]

Cause I'm not in school anymore?

 

[Fausto]

I am studying, thank you very much. I'm actually doing my dissertation on the interaction of virginal nerds in their native habitat.


/continues browsing ATOT

 

[Feldenak]

Because I'm at work.

 

[Kadarin]

Not in school...

 

[yellowperil]

I'm taking a break from cramming

I'm going cross-eyed

 

[Konigin]

Already studied for 2.5 hours.

 

Because I'm already a full member of the real world.

 

[Ameesh]

cause i already graduateded

 

[wyvrn]

I am, have a final tomorrow and just finished writing my last program for my CS class. After tomorrow, I get six weeks off. Woot !

 

[Tetsuo]

Originally posted by: Zim Hosein
Because I'm not in school at the moment

 

[yllus]

I am! Look, I'll post the useless crap I have to memorize for tomorrow's final:


Requirements Validation:
1) Validity (does the system support functions best suited for the user?s needs)
2) Consistency (any requirement conflicts?)
3) Completeness (all required functions represented?)
4) Realism (can the requirements be completed with today?s technology and available budget?)
5) Verifiability (can the requirements be checked?)

Requirements Validation Techniques:
1) Requirements reviews (systematic manual analysis of requirements)
2) Prototyping (using an executable model to check requirements)
3) Test-case generation (developing tests to check requirements)
4) Automated consistency analysis (checking consistency of a structured requirements description)

Requirements Change (Classification of Requirements)
1) Mutable requirements (that change due to system?s environment)
2) Emergent requirements (that appear as understanding of the system develops)
3) Consequential requirements (resulting from the introduction of the system)
4) Compatibility requirements (depend on other systems or organizational processes)


Finals for courses in which you really just have one big project are the worst. It's always filler crap that only serves to enlarge the professor's ego by letting him string a bunch of big words together.

 

[amdskip]

I'm multitasking kind sorta

 

Requirements Validation:
1) Validity (does the system support functions best suited for the user?s needs)
2) Consistency (any requirement conflicts?)
3) Completeness (all required functions represented?)
4) Realism (can the requirements be completed with today?s technology and available budget?)
5) Verifiability (can the requirements be checked?)

Requirements Validation Techniques:
1) Requirements reviews (systematic manual analysis of requirements)
2) Prototyping (using an executable model to check requirements)
3) Test-case generation (developing tests to check requirements)
4) Automated consistency analysis (checking consistency of a structured requirements description)

Requirements Change (Classification of Requirements)
1) Mutable requirements (that change due to system?s environment)
2) Emergent requirements (that appear as understanding of the system develops)
3) Consequential requirements (resulting from the introduction of the system)
4) Compatibility requirements (depend on other systems or organizational processes)

ahhahah what a load of crap.
I'll sum it up, "does it do what the user need it to do, all the time, without crashing, and is flexable"