"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
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).
-
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 have a problem allright.. in scenario 1 the requirements-engineer is designing the product and using the "requirements" to enforce their design. That's the problem. Its not their fault, but they do need to learn a new way of thinking about problem solutions -- one that doesn't involve trying to figure out what the solution is but merely setting the outline of it. I know from experience how hard that is. Try having the requirements engineer prioritize the requirements into the set of must-haves and nice-to-haves. If they still have trouble, have them think about must-haves as requirements that the product will not ship without meeting, even if it delays the product, even if people have to get laid off because shipment was delayed, or even if everybody has to take a pay cut because the shipment was delayed. Having such dire consequences in mind when making the evaluation might help them make the separation.
patbob
-
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 :-))
Frygreen wrote:
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?
There is no real difference with that an what you said before. A typical cycle is requirements -> design -> implementation -> test (validate requirements) Any or all of those can be explicit or implicit. Whether a project succeeds or not can depend on many things but certainly having someone doing any of the above steps in at least an adequate way is going to make that more likely. So someone that creates an explicit design without explicit requirments must still understand what the requirements are (implicit) and must be able to translate that into a usable design which others can use effectively.
-
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 describe "what" the system must do. Design address "how" the system will meet the requirements. It is not uncommon for the people writing the requirements to want to also do the design, but that impulse must be resisted. If you can't write a requirement in the form of "The system shall ...", then it ain't a requirement.
-
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
[500] ----(what is the gap?)---- [5] If both work well, there must be something behind the cases. If I can't reveal it, I would select the easier and take the harder as a reference. But, somehow it dependents on who am I. If I were an ordinary manager, 500 clearly defined requirements would be easer. If I were an artist, 5 sparkles would be better. From normal distribution, I am most likely an ordinary manager, so I would select the 500 requirements.
-
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 the requirements are written perfectly clear, then they should each be a testable line item. SyRD, SARAD, SAD, SRD, SDD. (IEEE 12207) Yes? If the items are not clearly testable then they haven't been broken down far enough. From a test perspective, the more granular the requirement, the more testable it is and so can actually make the product more stable. Not necessarily useful, but stable. Useful comes from the design. Actually going through a requirements rewrite where I now work because the last attempt at writing them was a massive exercise in futility. Go with Scenario 1 and ask yourself these questions: 1. How much can be done at the API level? 2. How many can be combined to create a scenario (end2end) style test? 3. How many of them are such edge case scenarios that the likelyhood of hitting that are practically nil? All of these questions can provide you with an avenue to a successful solution if you just don't overthink it. :) Oh, and good luck with this.
Mike Poz
-
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
IMO your balance does not lie in one or the other nor between them, its both. I have seen teams of analysts get lost in reams of requirements, which doesn't get you to the final product, I have also seen scope creep that was bigger than the original project. You need to document the requirements in a hierarchical fashion so you can keep an eye on the requirements and their progress at various levels, keeping an eye on the high level stuff is vital to ensure good direction, but the detail must be available. I don't think going beyond 100 or 200 requirements is practical (as you are then at risk of analysis paralysis) but I suppose massive projects could justify that. (People tend to think more is better and they add more of the same) Try to get a concise list of requirements, at the highest level probably 5 items or so, and make sure you have enough requirements for clarity of each item (in as many levels as needed) but not too many items that will cause people to get lost in the labyrinth... I have seen countless customers who have 600 page process flow documents and no one (I'm not exaggerating, NO ONE) ever reads it again. Also separate functional requirements from technical requirements. Technical requirements can be many, but a product with more than 100 functional requirements is brave. I recon most ERP systems on earth today can be described in about 100 functional requirements or less. I can go on, but its too early in the morning for that... :) --EDIT-- I haven't mentioned testing, but it should be do-able at every level
____________________________________________________________ Be brave little warrior, be VERY brave