# does anyone love requirements validation?



## spacefem (Apr 7, 2011)

Picture this. You're a manager in an industry with lots of regulation where everything must be tested and very very carefully documented at lots of levels. There's this sacred process - when a customer comes in you write down his high-level requirements (I want this button to light up a blue light) and someone takes those and decides there will be a button, converter box, light, and then they write another component-based requirement that THIS resistor inside the box will do something. Then we build the system. Then we write tests and test everything, first all the components, then each unit (box level), then the whole system to confirm that the blue light works. Tons of paper describing what everything should do, lots of testing, databases to track it all, you see?

The issue is that your company hires all these engineers who are excited about making stuff. You're always coming in to work the next morning and some lady comes up to you saying, "I was here until 2AM last night, I was inspired, I made this beautiful THING! Look what it does, everyone will want one of these!"

and you're like oh hell, we have to go backwards now because this thing wasn't made PER ANY DOCUMENTED REQUIREMENTS. So you tell the engineer she has to start writing down her system, unit, and component-level details otherwise it'll never get the government/quality/professional org people to sign off on it and besides this is the best way we've found to test every detailed corner case of operation to make sure your beautiful thing won't blow up. and she glazes over and says "I have to STOP working on my project, to do paperwork? You're mean!"

Time to get to my question. Maybe it's not fair to shoehorn engineers into writing, writing, writing. Maybe there's another personality type who would LOVE to just dive into these details, organize levels of testing, make databases. There's a person for every job right? Instead of engineering majors should we hire people who majored in english, law, history, accounting? Is there a personality type for this? I have no idea. Or do we tell the engineers to suck it up, your second grade teacher said you had to show your work so no more inspired late nights without writing down requirements first... that's just cruel.


----------



## Caveman Dreams (Nov 3, 2015)

Try AGILE, its easier.


----------



## AriesLilith (Jan 6, 2013)

Having worked with very complex systems including some projects for the government, I can tell you that I came to appreciate documentation (and a team of dedicated functional analysts) and be horrified of any complex project without it (yes, I've experienced, and am experiencing the horrors of this).

The lack of requirements specification and documentation means abstract details that will have to be up to people's subjective ideals and tastes, not to mention endless meetings chasing people who are supposed to know about some details but actually have no idea.
Normalization and coherence in information and design can be lost too. Too few people understand the importance of well architectured and structured information.

Although of course, functional and business documentation should be writen by functional/business analysts. They should be the ones analysing and structuring them full-time, as developers has the whole technical side and implementation challenges to focus on. Developers can write technical documentation, but not functional documentation.

With this said, there are different types of projects and some are more "formal" than others. Certainly tere are places where creativity and fast paced development might be more common. Government projects tend to be quite strict and formal.


----------



## ShinyHappyPeople (Jul 30, 2016)

spacefem said:


> and you're like oh hell, we have to go backwards now because this thing wasn't made PER ANY DOCUMENTED REQUIREMENTS. So you tell the engineer she has to start writing down her system, unit, and component-level details otherwise it'll never get the government/quality/professional org people to sign off on it and besides this is the best way we've found to test every detailed corner case of operation to make sure your beautiful thing won't blow up. and she glazes over and says "I have to STOP working on my project, to do paperwork? You're mean!


And this is why technological advancement has slowed so much in recent decades. Bureaucrats more concerned with paperwork than they are innovation.


----------



## jbking (Jun 4, 2010)

There can be business analysts that take the requirements and validate them as one thought while solution architects would be the other job title that comes to mind in planning out everything and seeing what has to be done here.


----------



## g_w (Apr 16, 2013)

spacefem said:


> Picture this. You're a manager in an industry with lots of regulation where everything must be tested and very very carefully documented at lots of levels. There's this sacred process - when a customer comes in you write down his high-level requirements (I want this button to light up a blue light) and someone takes those and decides there will be a button, converter box, light, and then they write another component-based requirement that THIS resistor inside the box will do something. Then we build the system. Then we write tests and test everything, first all the components, then each unit (box level), then the whole system to confirm that the blue light works. Tons of paper describing what everything should do, lots of testing, databases to track it all, you see?
> 
> The issue is that your company hires all these engineers who are excited about making stuff. You're always coming in to work the next morning and some lady comes up to you saying, "I was here until 2AM last night, I was inspired, I made this beautiful THING! Look what it does, everyone will want one of these!"
> 
> ...





Reality Check said:


> Try AGILE, its easier.





AriesLilith said:


> Having worked with very complex systems including some projects for the government, I can tell you that I came to appreciate documentation (and a team of dedicated functional analysts) and be horrified of any complex project without it (yes, I've experienced, and am experiencing the horrors of this).
> 
> The lack of requirements specification and documentation means abstract details that will have to be up to people's subjective ideals and tastes, not to mention endless meetings chasing people who are supposed to know about some details but actually have no idea.
> Normalization and coherence in information and design can be lost too. Too few people understand the importance of well architectured and structured information.
> ...





ShinyHappyPeople said:


> And this is why technological advancement has slowed so much in recent decades. Bureaucrats more concerned with paperwork than they are innovation.





jbking said:


> There can be business analysts that take the requirements and validate them as one thought while solution architects would be the other job title that comes to mind in planning out everything and seeing what has to be done here.


The trade off is

79549df0a03f012f2fe600163e41dd5b

vs

large_020517_treeswing.jpg


...or why the Pentagon chose the F-35 over the F-22 raptor...


----------



## angelfish (Feb 17, 2011)

I believe there are almost certainly people out there who enjoy the subject information but would prefer to work with written data than hands-on parts and the creative process. Having a data-entry position for that sort of work might be good. It makes me think of medical coding - you need someone who enjoys being familiar with the technical specifications and language, and who gets intrinsic pleasure out of making sure the paperwork is in order. I think there are probably some IxxJs out there who would fit the bill.


----------



## Arzazar Szubrasznikarazar (Apr 9, 2015)

spacefem said:


> Time to get to my question. Maybe it's not fair to shoehorn engineers into writing, writing, writing. Maybe there's another personality type who would LOVE to just dive into these details, organize levels of testing, make databases. There's a person for every job right? Instead of engineering majors should we hire people who majored in english, law, history, accounting? Is there a personality type for this? I have no idea. Or do we tell the engineers to suck it up, your second grade teacher said you had to show your work so no more inspired late nights without writing down requirements first... that's just cruel.


Isn't there some kind of a specialisation in engineering that specialises in the all that stuff?


----------

