"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
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.
-
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
This may or may not help you, but I like to think of requirements as "what the customer needs", even when the customer is some other guy/department in the company. If it's "implementation", it's design. If they really do care about some aspect of the implementation, then that part could be a requirement as well. Think of requirements as describing the black box. For example, here might be some requirements: The software shall store the settings of the last 100 users. This should NOT be a requirement, but your implementation: The software shall use a MySQL database to store settings. Some other requirements: The system shall be able to operate for 24 hours continuously without needing the recharge the battery. The system shall be powered by a 9V battery. [<-- This could be a requirement because it fits into some other department's, the mechanical design, needs.] But these would be implementation: The software shall throttle the processor when possible to conserve power consumption. Making something a spec does not get you off the hook from testing, but it may affect the nature of the test. BTW, it IS worth spending time on figuring out how you want to handle this!
-
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
Requirements should be "reasonable" and implementation independent. Before you go to design create a specifications document: specifications should be "feasible", a selection of the requirements taking into account the feasibility, costs, time to implement etc. Create functional specifications and constructional specifications. Design is a process of alternate analysis and synthesis steps. During an analysis step the concerns are the correct understanding of the semantics, the completeness, and the consistency of the function of the Object System. In a synthesis step, the concerns are the correct replacement of functional semantics by formal semantics and the efficiency of the construction of the Object System. Good book: Building Strategy into design (Jan L.G. Dietz)
-
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
Coming from a safety critical system design background, requirements need to be detailed, unambiguous and unique. Having more requirements doesn't help the design/implementation process if they are of poor quality. I'd much rather develop a system based on 100 good, verifiable requirements than 1000 poor, conflicting, duplicating requirements. In the old days writing requirements was seen as a skill in its own right. Modern practises see it as a hoop to jump through to keep the process assurance team happy. Good requirements doesn't always mean you'll end up with a successful project, but bad requirements almost always lead to a poor result (both in meeting the customer's technical expectations and schedule).