Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
Graic Gabtar
Dec 19, 2014

squat my posts

Lord Of Texas posted:

Functional specs can be a humongous trap. Don't prescribe solutions, describe the user's need, and develop the criteria must be met for the users to accept a particular solution.

If you find yourself writing "the application will have a table/button/drop-down" stop yourself. Users don't need buttons and tables, they need the ability to enter and view comments (for example). Then for acceptance criteria, you might have "users should not be able to enter comments anonymously".
Never were truer words spoken.

I'm currently "working" on a project as a domain architect where to "save time" the steering committee endorsed a view to write a requirements/functional spec frankenstein that completely missed the mark (set field 'A" to this, use technology "B" that we only know about to do that).

My practice formally withdrew me from the project telling them we would just do an "as built" design - if they ever went live.

About two years down the track nothing has been delivered, downstream teams are screaming about the crappy requirements and complete lack of architecture.

Long story short. Functional specs might have a place on your project - once the requirements are done correctly and there is a solid design signed off.

Adbot
ADBOT LOVES YOU

  • Locked thread