"What is requirement" vs. "What is design"
-
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