Difference between revisions of "Design Constraints Analysis"
(→What) |
(→How) |
||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
==What== | ==What== | ||
| − | Design constraints are boundaries within | + | Design constraints are limiting parameters or boundaries within which the system is to be designed. |
| − | + | ==How== | |
| − | + | A design constraint can be seen as a non-functional requirement which the final product should meet. | |
| − | + | Prepare the design constraints. Consider the following topics: | |
| − | + | '''The price of the product:''' | |
| − | + | Consider how much the product should cost. This includes sales price, development cost, HW cost, etc. | |
| − | + | '''Development time:''' | |
| − | When | + | Consider the time it must take to develop the system-to-be. When is the production expected to begin? When is the sale expected to begin? |
| − | '''Performance | + | '''Performance:''' |
| − | Consider the performance of the product when it is to be used. Is it an expensive high quality product or is it a low price product which is to be sold in large quantities? | + | Consider the performance of the product when it is to be used. Is it an expensive high-quality product, or is it a low-price product which is to be sold in large quantities? If it is a product for which a customer has paid a large amount of money, no defects are accepted. If the system-to-be is a product which must be safe in use, optimal performance is necessary and malfunctions are not accepted. |
| − | Another important aspect is | + | Another important aspect is to consider where you plan to sell the product-to-be. Many countries have different legislation. If you are planning to sell the product-to-be in European countries, you must test your product in compliance with appropriate EU standards (e.g. CE conformity mark). |
| − | '''Reliability and lifetime | + | '''Reliability and lifetime:''' |
| − | The reliability and lifetime must be considered. | + | The reliability and lifetime must be considered. If the system-to-be is a product which must be safe to use, the reliability and lifetime are paramount; no failures are accepted. Examples are: Electronically controlled wheelchairs, systems for use in hospitals, etc. |
| − | '''Already developed parts | + | '''Already developed parts:''' |
| − | + | In case you need to reuse already developed parts, you need to take this into account early in the project phase, as it will have an effect on the selection of the technical platform. The reused parts may not fit completely into the system-to-be. You have to consider how they worked in previous projects. Do they fit into the new project? Was it the design you intended, or did some parts have defects? Are they good enough, or will you have to design new parts? | |
| − | '''Service and maintenance''' | + | '''Service and maintenance:''' |
| − | Consider service and maintenance. No matter how well- developed the system-to-be is, it will sometimes fail or must be maintained. Maintenance can be different sorts of adjustments of the system-to-be. | + | Consider service and maintenance. No matter how well-developed the system-to-be is, it will sometimes fail or must be maintained. Maintenance can be different sorts of adjustments of the system-to-be, e.g. replacing old HW or changing SW. |
| − | '''Type of | + | '''Type of system:''' |
| − | Consider which type of system is wanted. | + | Consider which type of system is wanted. |
| − | It is possible to design systems containing much or little electronics. The more electronics the more features are normally possible. The choice could be a system that contains no electronics at all. | + | It is possible to design systems containing much or little electronics. The more electronics the more features are normally possible. The choice could be a system that contains no electronics at all. It is, for instance, possible to construct a heating installation with no electronics where the parts used are purely mechanical featuring only a few adjustment possibilities. It is also possible to construct a heating installation containing much electronics. In this case, there are many adjustment possibilities, and it will be easy to guide the user. |
| − | = | + | ==Why== |
| + | Constraints limits the developers choices when designing the system-to-be. Therefore it is necessary to know exactly the boundaries the developer should work within before the design starts. If failing to find and note down the limits, time may be waisted on trying different designs that would not be possible for the specific project. | ||
| − | = | + | ==Examples== |
| + | |||
| + | In an electrical wiring a 100A current flows. The tables will tell that this cannot be accomplished using a #16 size wire - it will simply burn out and/or cause a fire. | ||
| + | |||
| + | Another example would be tensile strength in steel when building a structure. One has to be well within in a safe limit before the steel shears or starts to deform and causes the structure to crumble. | ||
| + | |||
| + | If there is a deadline, eg. may 16 - this year, this is a time constraint, that can be used to layout a timeschedule, tasks and assign manpower. | ||
| + | |||
| + | If the system-to-be shall use strong encryption consider what will be the necessary performance requirement in order to calculate the crypto algorithms within time - and at the same time leave CPU cycles for other tasks to be performed within reasonable time. Also consider the performance in the selection of libraries available. If the CPU type and speed are set by other constraints the most efficient library with regards to calculate using the least amount of CPU cycles may be the preferred. | ||
| + | |||
| + | If a system is going to implement e.g. the JSON protocol are there libraries available for the selected programming language, or should time be set off to develop a library specifically for the project. | ||
Latest revision as of 11:32, 21 September 2015
Contents
What
Design constraints are limiting parameters or boundaries within which the system is to be designed.
How
A design constraint can be seen as a non-functional requirement which the final product should meet.
Prepare the design constraints. Consider the following topics:
The price of the product:
Consider how much the product should cost. This includes sales price, development cost, HW cost, etc.
Development time:
Consider the time it must take to develop the system-to-be. When is the production expected to begin? When is the sale expected to begin?
Performance:
Consider the performance of the product when it is to be used. Is it an expensive high-quality product, or is it a low-price product which is to be sold in large quantities? If it is a product for which a customer has paid a large amount of money, no defects are accepted. If the system-to-be is a product which must be safe in use, optimal performance is necessary and malfunctions are not accepted.
Another important aspect is to consider where you plan to sell the product-to-be. Many countries have different legislation. If you are planning to sell the product-to-be in European countries, you must test your product in compliance with appropriate EU standards (e.g. CE conformity mark).
Reliability and lifetime:
The reliability and lifetime must be considered. If the system-to-be is a product which must be safe to use, the reliability and lifetime are paramount; no failures are accepted. Examples are: Electronically controlled wheelchairs, systems for use in hospitals, etc.
Already developed parts:
In case you need to reuse already developed parts, you need to take this into account early in the project phase, as it will have an effect on the selection of the technical platform. The reused parts may not fit completely into the system-to-be. You have to consider how they worked in previous projects. Do they fit into the new project? Was it the design you intended, or did some parts have defects? Are they good enough, or will you have to design new parts?
Service and maintenance:
Consider service and maintenance. No matter how well-developed the system-to-be is, it will sometimes fail or must be maintained. Maintenance can be different sorts of adjustments of the system-to-be, e.g. replacing old HW or changing SW.
Type of system:
Consider which type of system is wanted.
It is possible to design systems containing much or little electronics. The more electronics the more features are normally possible. The choice could be a system that contains no electronics at all. It is, for instance, possible to construct a heating installation with no electronics where the parts used are purely mechanical featuring only a few adjustment possibilities. It is also possible to construct a heating installation containing much electronics. In this case, there are many adjustment possibilities, and it will be easy to guide the user.
Why
Constraints limits the developers choices when designing the system-to-be. Therefore it is necessary to know exactly the boundaries the developer should work within before the design starts. If failing to find and note down the limits, time may be waisted on trying different designs that would not be possible for the specific project.
Examples
In an electrical wiring a 100A current flows. The tables will tell that this cannot be accomplished using a #16 size wire - it will simply burn out and/or cause a fire.
Another example would be tensile strength in steel when building a structure. One has to be well within in a safe limit before the steel shears or starts to deform and causes the structure to crumble.
If there is a deadline, eg. may 16 - this year, this is a time constraint, that can be used to layout a timeschedule, tasks and assign manpower.
If the system-to-be shall use strong encryption consider what will be the necessary performance requirement in order to calculate the crypto algorithms within time - and at the same time leave CPU cycles for other tasks to be performed within reasonable time. Also consider the performance in the selection of libraries available. If the CPU type and speed are set by other constraints the most efficient library with regards to calculate using the least amount of CPU cycles may be the preferred.
If a system is going to implement e.g. the JSON protocol are there libraries available for the selected programming language, or should time be set off to develop a library specifically for the project.
