"What is requirement" vs. "What is design"
-
Dear reader, I have an issue with the right balance between "what to have as requirement" and "what to have as design/architecture". Both have consequences in my projects. Let me try to explain it with two project-szenarios ( from embedded safety-critical systems engineering ) Szenario 1: There is a subsystem to develop (e.g. handling data of a sensor). The requirements-engineer writes a lot of requirements for this subsystem (lets say 500 requirements). Developers are designing and coding the system. So far so good. Problem: there are 500 requirements to validate somehow. If the complete system is handled in this way, there are actually 15.000 requirements to validate/test: Pure nightmare Szenario 2: These guys are seeing the topic more relaxed. They are creating only 5 requirements. The developers have now much more design/architectural choices and finally (let's assume) have the same solution. Advantage here: There are only 5 requirements to test/validate and the complete development is much faster now Did I explain my problem right? If I move anything in my design-documents, I save a lot of time for testing. But something seems to be strange here and I do not know what. Where is the right balance? Is there any theory behind
-
Dear reader, I have an issue with the right balance between "what to have as requirement" and "what to have as design/architecture". Both have consequences in my projects. Let me try to explain it with two project-szenarios ( from embedded safety-critical systems engineering ) Szenario 1: There is a subsystem to develop (e.g. handling data of a sensor). The requirements-engineer writes a lot of requirements for this subsystem (lets say 500 requirements). Developers are designing and coding the system. So far so good. Problem: there are 500 requirements to validate somehow. If the complete system is handled in this way, there are actually 15.000 requirements to validate/test: Pure nightmare Szenario 2: These guys are seeing the topic more relaxed. They are creating only 5 requirements. The developers have now much more design/architectural choices and finally (let's assume) have the same solution. Advantage here: There are only 5 requirements to test/validate and the complete development is much faster now Did I explain my problem right? If I move anything in my design-documents, I save a lot of time for testing. But something seems to be strange here and I do not know what. Where is the right balance? Is there any theory behind
If you move it all into design you are assuming the developers/designers anticipate what the requester will require after release (remember there are always additional requests). In your first scenerio the
(new_requests) / (total_requests)ratio is much much smaller than scenerio 2. It is also possible that the new requests shake the fundimental design of the system and requires a re-design. If you are given 500 requirements and they are clear as day, I recomend taking those requirements. In the real world this is rarely the case. More often you get "Change process A to act 'a little' like process D with a splash of C" and eventually they come back and say "Oh you thought I said C... No I meant 'See me for additional requirements'Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
Dear reader, I have an issue with the right balance between "what to have as requirement" and "what to have as design/architecture". Both have consequences in my projects. Let me try to explain it with two project-szenarios ( from embedded safety-critical systems engineering ) Szenario 1: There is a subsystem to develop (e.g. handling data of a sensor). The requirements-engineer writes a lot of requirements for this subsystem (lets say 500 requirements). Developers are designing and coding the system. So far so good. Problem: there are 500 requirements to validate somehow. If the complete system is handled in this way, there are actually 15.000 requirements to validate/test: Pure nightmare Szenario 2: These guys are seeing the topic more relaxed. They are creating only 5 requirements. The developers have now much more design/architectural choices and finally (let's assume) have the same solution. Advantage here: There are only 5 requirements to test/validate and the complete development is much faster now Did I explain my problem right? If I move anything in my design-documents, I save a lot of time for testing. But something seems to be strange here and I do not know what. Where is the right balance? Is there any theory behind
Frygreen wrote:
there are actually 15.000 requirements to validate/test: Pure nightmare
On the contrary. This is pure joy!
Frygreen wrote:
There are only 5 requirements to test/validate and the complete development is much faster now
Now this is pure nightmare, because those 5 requirements were not thought out. Not only will they not explode to 15,000 but because those 15,000 aren't actually ever stated, your project is guaranteed to fail. I'm not sure if there is a balance. The more specs, the better the requirements, the better. The real question is, how do you test the requirements. That's the fun part! Marc
-
Dear reader, I have an issue with the right balance between "what to have as requirement" and "what to have as design/architecture". Both have consequences in my projects. Let me try to explain it with two project-szenarios ( from embedded safety-critical systems engineering ) Szenario 1: There is a subsystem to develop (e.g. handling data of a sensor). The requirements-engineer writes a lot of requirements for this subsystem (lets say 500 requirements). Developers are designing and coding the system. So far so good. Problem: there are 500 requirements to validate somehow. If the complete system is handled in this way, there are actually 15.000 requirements to validate/test: Pure nightmare Szenario 2: These guys are seeing the topic more relaxed. They are creating only 5 requirements. The developers have now much more design/architectural choices and finally (let's assume) have the same solution. Advantage here: There are only 5 requirements to test/validate and the complete development is much faster now Did I explain my problem right? If I move anything in my design-documents, I save a lot of time for testing. But something seems to be strange here and I do not know what. Where is the right balance? Is there any theory behind
You seem to be missing the point slightly. Without requirements, you cannot effectively have design. How do you prove that a system works if you don't know what it's supposed to do. I am always amazed when companies think it's OK to start developing systems before they have fully gathered the requirements. If you do this, then you are actively shooting yourself in the foot. By the way, why does nobody seem to want to produce acceptance criteria? Without knowing what the criteria by which your application will be judged successful is, how can you prove to the client that you have delivered what they want. I appreciate that scenario 2 is close to the SCRUM mentality of just enough requirement, but frankly I don't by into this viewpoint. Having tried this out with clients in the past, I can tell you that this is ripe for scope creep and never delivering your application because there's always that little bit more that comes into scope. I believe there's a new term in vogue right now called Emergent Design, where you code and hope that a design comes out of it - we used to know this as either JFDI or "Making this sh*t up as we go along".
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
Dear reader, I have an issue with the right balance between "what to have as requirement" and "what to have as design/architecture". Both have consequences in my projects. Let me try to explain it with two project-szenarios ( from embedded safety-critical systems engineering ) Szenario 1: There is a subsystem to develop (e.g. handling data of a sensor). The requirements-engineer writes a lot of requirements for this subsystem (lets say 500 requirements). Developers are designing and coding the system. So far so good. Problem: there are 500 requirements to validate somehow. If the complete system is handled in this way, there are actually 15.000 requirements to validate/test: Pure nightmare Szenario 2: These guys are seeing the topic more relaxed. They are creating only 5 requirements. The developers have now much more design/architectural choices and finally (let's assume) have the same solution. Advantage here: There are only 5 requirements to test/validate and the complete development is much faster now Did I explain my problem right? If I move anything in my design-documents, I save a lot of time for testing. But something seems to be strange here and I do not know what. Where is the right balance? Is there any theory behind
The more clearer and to the point the requirements are the design and development would be much more smoother and so the requirement change management will be much more easy. I say go with the first approach; In any case the test/validation cases would have to be more. Even if you have only 5 vague requirements, the test cases based upon them will need to consider all the 15K scenarios, otherwise users will have nightmares.
-
Dear reader, I have an issue with the right balance between "what to have as requirement" and "what to have as design/architecture". Both have consequences in my projects. Let me try to explain it with two project-szenarios ( from embedded safety-critical systems engineering ) Szenario 1: There is a subsystem to develop (e.g. handling data of a sensor). The requirements-engineer writes a lot of requirements for this subsystem (lets say 500 requirements). Developers are designing and coding the system. So far so good. Problem: there are 500 requirements to validate somehow. If the complete system is handled in this way, there are actually 15.000 requirements to validate/test: Pure nightmare Szenario 2: These guys are seeing the topic more relaxed. They are creating only 5 requirements. The developers have now much more design/architectural choices and finally (let's assume) have the same solution. Advantage here: There are only 5 requirements to test/validate and the complete development is much faster now Did I explain my problem right? If I move anything in my design-documents, I save a lot of time for testing. But something seems to be strange here and I do not know what. Where is the right balance? Is there any theory behind
Like Collin said*, more requirements can make your life easier in the long run. Every project changes during development, but the more that's set down at the beginning, the better your design can be. Otherwise, you're just guessing at what the client REALLY wants, and one wrong guess might mean having to rewrite it before you even ship. I only see one advantage to your second scenario... If you have a really good design/development team, and you make the RIGHT guesses as to what the client wants (This is a matter of how well you know your client's business), it's easy to impress them and develop a good reputation... Lets you show off a little, since you have some room to maneuver. Just remember that in your second scenario, you don't REALLY have just five requirements. You only have five requirements WRITTEN DOWN. There may still be hundreds or thousands of requirements... They're just implied instead of implicit. Even if it's not written down, it's a requirement that, say, clicking "File > Exit" will exit the application, prompt the user to save, etc... The client expects the feature to be there, and your team should know to implement it, but it was never put on paper. * Ok, others said it too, but he was the only one who had replied when I started typing :)
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
Dear reader, I have an issue with the right balance between "what to have as requirement" and "what to have as design/architecture". Both have consequences in my projects. Let me try to explain it with two project-szenarios ( from embedded safety-critical systems engineering ) Szenario 1: There is a subsystem to develop (e.g. handling data of a sensor). The requirements-engineer writes a lot of requirements for this subsystem (lets say 500 requirements). Developers are designing and coding the system. So far so good. Problem: there are 500 requirements to validate somehow. If the complete system is handled in this way, there are actually 15.000 requirements to validate/test: Pure nightmare Szenario 2: These guys are seeing the topic more relaxed. They are creating only 5 requirements. The developers have now much more design/architectural choices and finally (let's assume) have the same solution. Advantage here: There are only 5 requirements to test/validate and the complete development is much faster now Did I explain my problem right? If I move anything in my design-documents, I save a lot of time for testing. But something seems to be strange here and I do not know what. Where is the right balance? Is there any theory behind
User scenario #1. Why? Two words: Scope Creep [^]. [Modified] Also, the number of tests may sound daunting, but if those are the requirements, they must be coded and tested to ensure quality. Is the motivation of using #2 to simply speed up the dev / test / release cycle?
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" — Hunter S. Thompson
-
Dear reader, I have an issue with the right balance between "what to have as requirement" and "what to have as design/architecture". Both have consequences in my projects. Let me try to explain it with two project-szenarios ( from embedded safety-critical systems engineering ) Szenario 1: There is a subsystem to develop (e.g. handling data of a sensor). The requirements-engineer writes a lot of requirements for this subsystem (lets say 500 requirements). Developers are designing and coding the system. So far so good. Problem: there are 500 requirements to validate somehow. If the complete system is handled in this way, there are actually 15.000 requirements to validate/test: Pure nightmare Szenario 2: These guys are seeing the topic more relaxed. They are creating only 5 requirements. The developers have now much more design/architectural choices and finally (let's assume) have the same solution. Advantage here: There are only 5 requirements to test/validate and the complete development is much faster now Did I explain my problem right? If I move anything in my design-documents, I save a lot of time for testing. But something seems to be strange here and I do not know what. Where is the right balance? Is there any theory behind
Szenario 1... :drool: IS THIS REALLY POSSIBLE???? is out there somebody capable to make a good requirement list? This is the best of the cases... choose always all the requirements. More requirements means better design, better testing, programming knowing the real goal... This is a dream come true.
[www.tamelectromecanica.com] Robots, CNC and PLC machines for grinding and polishing.
-
Dear reader, I have an issue with the right balance between "what to have as requirement" and "what to have as design/architecture". Both have consequences in my projects. Let me try to explain it with two project-szenarios ( from embedded safety-critical systems engineering ) Szenario 1: There is a subsystem to develop (e.g. handling data of a sensor). The requirements-engineer writes a lot of requirements for this subsystem (lets say 500 requirements). Developers are designing and coding the system. So far so good. Problem: there are 500 requirements to validate somehow. If the complete system is handled in this way, there are actually 15.000 requirements to validate/test: Pure nightmare Szenario 2: These guys are seeing the topic more relaxed. They are creating only 5 requirements. The developers have now much more design/architectural choices and finally (let's assume) have the same solution. Advantage here: There are only 5 requirements to test/validate and the complete development is much faster now Did I explain my problem right? If I move anything in my design-documents, I save a lot of time for testing. But something seems to be strange here and I do not know what. Where is the right balance? Is there any theory behind
wow, such many, such fast answers: thank you. Ok, I understand. It is common opinion that szenario 1(based on detailed requirements-engineering)is clearly the preferred one. There are many arguments for this point of view. I will keep this in my mind tomorrow :-)
-
Dear reader, I have an issue with the right balance between "what to have as requirement" and "what to have as design/architecture". Both have consequences in my projects. Let me try to explain it with two project-szenarios ( from embedded safety-critical systems engineering ) Szenario 1: There is a subsystem to develop (e.g. handling data of a sensor). The requirements-engineer writes a lot of requirements for this subsystem (lets say 500 requirements). Developers are designing and coding the system. So far so good. Problem: there are 500 requirements to validate somehow. If the complete system is handled in this way, there are actually 15.000 requirements to validate/test: Pure nightmare Szenario 2: These guys are seeing the topic more relaxed. They are creating only 5 requirements. The developers have now much more design/architectural choices and finally (let's assume) have the same solution. Advantage here: There are only 5 requirements to test/validate and the complete development is much faster now Did I explain my problem right? If I move anything in my design-documents, I save a lot of time for testing. But something seems to be strange here and I do not know what. Where is the right balance? Is there any theory behind
In scenario 2 what you seem to be referring as requirements are what I would call use cases. The use case would define the operation of the system from a users perspective, and what and how the tests should be conducted. The architect would then create the requirements from this. In most projects I have worked on there is one requirements document with many modules. I would doubt the effectiveness of only five tests to adequately cover a complex system.
I know the language. I've read a book. - _Madmatt
-
You seem to be missing the point slightly. Without requirements, you cannot effectively have design. How do you prove that a system works if you don't know what it's supposed to do. I am always amazed when companies think it's OK to start developing systems before they have fully gathered the requirements. If you do this, then you are actively shooting yourself in the foot. By the way, why does nobody seem to want to produce acceptance criteria? Without knowing what the criteria by which your application will be judged successful is, how can you prove to the client that you have delivered what they want. I appreciate that scenario 2 is close to the SCRUM mentality of just enough requirement, but frankly I don't by into this viewpoint. Having tried this out with clients in the past, I can tell you that this is ripe for scope creep and never delivering your application because there's always that little bit more that comes into scope. I believe there's a new term in vogue right now called Emergent Design, where you code and hope that a design comes out of it - we used to know this as either JFDI or "Making this sh*t up as we go along".
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
Pete O'Hanlon wrote:
close to the SCRUM mentality of just enough requirement
I've seen this misunderstood and abused. Requirements may not be fully fleshed out at first but no project I've worked on has succeeded without adequate and complete requirements in the end.
I know the language. I've read a book. - _Madmatt
-
Dear reader, I have an issue with the right balance between "what to have as requirement" and "what to have as design/architecture". Both have consequences in my projects. Let me try to explain it with two project-szenarios ( from embedded safety-critical systems engineering ) Szenario 1: There is a subsystem to develop (e.g. handling data of a sensor). The requirements-engineer writes a lot of requirements for this subsystem (lets say 500 requirements). Developers are designing and coding the system. So far so good. Problem: there are 500 requirements to validate somehow. If the complete system is handled in this way, there are actually 15.000 requirements to validate/test: Pure nightmare Szenario 2: These guys are seeing the topic more relaxed. They are creating only 5 requirements. The developers have now much more design/architectural choices and finally (let's assume) have the same solution. Advantage here: There are only 5 requirements to test/validate and the complete development is much faster now Did I explain my problem right? If I move anything in my design-documents, I save a lot of time for testing. But something seems to be strange here and I do not know what. Where is the right balance? Is there any theory behind
It's me again: Let me take another position. In my project I am now the experience professional, I know how to perform RequirementsEngineering as well as how to apply high-valued design/architecture. Therefore: Instead of giving "my" developers many detailed requirements, I decide to have a very detailed design-documentation. In this way, I have the material not in an requirements-engineering-tool (e.g. doors) but in a word-document ( or an uml-model ). What's suspicious with this? Requirements are now somehow transformed :-))
-
You seem to be missing the point slightly. Without requirements, you cannot effectively have design. How do you prove that a system works if you don't know what it's supposed to do. I am always amazed when companies think it's OK to start developing systems before they have fully gathered the requirements. If you do this, then you are actively shooting yourself in the foot. By the way, why does nobody seem to want to produce acceptance criteria? Without knowing what the criteria by which your application will be judged successful is, how can you prove to the client that you have delivered what they want. I appreciate that scenario 2 is close to the SCRUM mentality of just enough requirement, but frankly I don't by into this viewpoint. Having tried this out with clients in the past, I can tell you that this is ripe for scope creep and never delivering your application because there's always that little bit more that comes into scope. I believe there's a new term in vogue right now called Emergent Design, where you code and hope that a design comes out of it - we used to know this as either JFDI or "Making this sh*t up as we go along".
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
Pete O'Hanlon wrote:
I am always amazed when companies think it's OK to start developing systems before they have fully gathered the requirements.
Requirement for a system we are doing (it was previously part of a much larger system, part bought, heavily modified after we bought the source code, in a different language) was "same as it currently does without all the bits we don't like". The requirements effectively come from the users each time they get shown what it currently does. It is also being developed to integrate with another system we have bought in which is being customised and configured by an external company. However they are doing their work at the same time. And the business processes keep changing as they realise what each system can, cannot, or currently does do. Surprisingly it is not going very well and the developers on the project are all extremely grumpy. I on the other hand, am finding the whole process highly amusing.
Every man can tell how many goats or sheep he possesses, but not how many friends.
-
It's me again: Let me take another position. In my project I am now the experience professional, I know how to perform RequirementsEngineering as well as how to apply high-valued design/architecture. Therefore: Instead of giving "my" developers many detailed requirements, I decide to have a very detailed design-documentation. In this way, I have the material not in an requirements-engineering-tool (e.g. doors) but in a word-document ( or an uml-model ). What's suspicious with this? Requirements are now somehow transformed :-))
Requirements are meant to be, and should be, unambiguous. There is no room for different interuptations of how a component should function. If developer A expects a method to return an int but developer B codes for a string, you have problems. Look at the Mars Lander. One team expected metric measurements they other did not.
I know the language. I've read a book. - _Madmatt
-
Frygreen wrote:
there are actually 15.000 requirements to validate/test: Pure nightmare
On the contrary. This is pure joy!
Frygreen wrote:
There are only 5 requirements to test/validate and the complete development is much faster now
Now this is pure nightmare, because those 5 requirements were not thought out. Not only will they not explode to 15,000 but because those 15,000 aren't actually ever stated, your project is guaranteed to fail. I'm not sure if there is a balance. The more specs, the better the requirements, the better. The real question is, how do you test the requirements. That's the fun part! Marc
Marc Clifton wrote:
real question is, how do you test the requirements.
Hmm, I wonder if requirements could be written in a declaritive way using a logic programming language. Then the requirements could be "run" to see if they are self-consistent.
-
Pete O'Hanlon wrote:
close to the SCRUM mentality of just enough requirement
I've seen this misunderstood and abused. Requirements may not be fully fleshed out at first but no project I've worked on has succeeded without adequate and complete requirements in the end.
I know the language. I've read a book. - _Madmatt
Mark Nischalke wrote:
no project I've worked on has succeeded without adequate and complete requirements in the end.
That's the point. Just because you haven't fully fleshed out a requirement, it's still a requirement. Is it a functional requirement? Is it none functional? Is it OK to wait until 6 months into the project before introducing performance requirements? Having just finished with a 3 year project where the requirements were written in water because the client wanted to use this, I can testify to the pain it causes - especially when you have to scrap something because they change a requirement such as "it must run in SQL Server" to "it's got to run on Oracle on a Linux box using Oracle Spatial". That hurts development times, a lot, and ends up confusing the end customer because they aren't sure what they are going to receive, or when.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
Marc Clifton wrote:
real question is, how do you test the requirements.
Hmm, I wonder if requirements could be written in a declaritive way using a logic programming language. Then the requirements could be "run" to see if they are self-consistent.
Leslie Sanford wrote:
Hmm, I wonder if requirements could be written in a declaritive way using a logic programming language. Then the requirements could be "run" to see if they are self-consistent.
Exactly! While I've tried that, I have yet to succeed with non-trivial requirements, because they often require some significantly large pieces of data. What's missing, and what I've never taken the step to do, is to add the capability to capture the data and feed it into the application in a different way. For example, one application that I've written scans a Visio drawing that was manually created. The drawing is essentially the topology of a switch network. The application tests for situations in which the network cannot handle failed outputs. Needless to say, the application is complicated because of the way I do the testing (the algorithm solves the problem from a topology perspective, which is significantly faster than taking 5 years of processor time, literally, to test every switch permutation.) Anyways, there have been times when the algorithm erroneously reports an error, or vice versa. So I have this library of Visio drawings that I use to test prior errors in the algorithm, whenever I make a change. Geez, it would be so much easier if I had a button I could press that said "take a snapshot of the internal data structures". Sort of like a VM for the application's state. Anyways, sorry for the long-winded post! Marc
-
wow, such many, such fast answers: thank you. Ok, I understand. It is common opinion that szenario 1(based on detailed requirements-engineering)is clearly the preferred one. There are many arguments for this point of view. I will keep this in my mind tomorrow :-)
Welcome. Glad that we can be helpful. One more teeny-tiny grammatical suggestion it is Scenario not Szenario.
-
Welcome. Glad that we can be helpful. One more teeny-tiny grammatical suggestion it is Scenario not Szenario.
If only my German were a fraction as good as the posters English.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
If only my German were a fraction as good as the posters English.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
Hmmm and If only my English was as good as your English, and don't even think about my German.