It has been a long time. I have been working on many different projects. I wanted to take a moment and give a quick review of the Grip Master, Heavy Tension, Hand Exerciser by Prohands (http://www.prohands.net/)
This is a device that is common to instrument players, but can also be used by sports athletes and anyone that rely on finger strength.
The device is used by placing it in the palm of your hand, placing a finger on each of the buttons, and pressing down on the buttons. The Prohands web site has a lot of great exercise examples to look at.
- This is a great device to strengthen your fingers.
- It comes in multiple levels of tension (3 lbs, 5 lbs, 7 lbs, 9 lbs, and 11 lbs).
- The wide range of tensions allow plenty of range of difficulty for all people. I use the Heavy tension and it is tough. A good work out for the fingers.
- There are third party accessories for guitar players to build up the finger tips.
- Price is very reasonable, at around $15 it is a great buy. It would be a great gift for anyone, or even a stocking stuffer at Christmas time.
- Great construction
- No apparent degredation of tension strength after 6 months of regular use.
- I have not found anything really bad about the device. I have used it for about 6 months now and it is still great.
- It has not lost any tension strength.
- The only negative is my own fault. I started with the Heavy Tension and I probably could have done a little lighter tension to start with. I have built myself up to the Heavy Tension and now use it regularly.
- Requires dedication and daily use. It will take time to notice a difference. Took me a couple of weeks to notice a difference in my playing guitar.
I would highly recommend the Grip Master by Prohands. It is a great product with good construction, good design, and seems to have some good longevity to it. It is a great gift for any guitar, violin, piano, or other instrument practitioner in your life.
After years of working in this business I have learned a lot. Most of what I have learned “not to do” came from observing other people, co-workers. I learned over the years just as much from my own mistakes as I did from watching others make them too. Not everyone will agree with what I have to say, but it is a culmination of many years experience. It might reflect a little of my own work ethic, but I believe it is all in good measure.
So, what makes a Test Engineer. Some people may not know what a Test Engineer is; even people who do it for a living. Let’s go over some of the things I believe are true.
(1) A Test Engineer’s job is to break things. That is a rather simple statement, but essentially that is true. We are expected to find all the flaws in a software, or hardware product. We get paid to file Change Requests (a.k.a CR’s). Everything that a person own’s should have, if it has not, gone through the hands of a test engineer. I am not talking about an Inspector 7 tag in your clothing. I mean an Engineer. Now for the technical part; we find flaws in a product by creating tests that challenge the product to meet the design requirements and safety regulations of the market or industry it is intended (for those with concern, yes, I mixed verification and validation by using the word test). Without good requirements flaws in the design can get past the engineer and make their way out into the market. Same can be said about testing. Without great testing all flaws will make their way into the market. There are a lot of products that could use some better testing.
(2) Know the tools of the trade. By this I mean MS Office, email, and any other tool used regularly in the office. Anyone can open MS Word and create a document. A Test Engineer is creating documents and reports all the time. I have met so many people that had their skill set end with being able to open MS Word. Tables and other features in the applications are crucial to creating good reports and tests. It is also an outward demonstration of our work. If an engineer creates sloppy protocols, tests, and studies, they are probably doing sloppy work. Some may consider it an act of professionalism. I like to think of it as a little of both. My Grandfather once told me, “A man’s word is all he will ever own. Lose that and you lose everything.” He was not just speaking of the spoken word. He was speaking of everything we do, everything that represents ourselves. Take pride in your work, create an outstanding document and use the tools to all their advantages.
(3) Fast learner. This goes with the previous item #2. As a Test Engineer we have to work on so many different things. We may be assigned something that we have no clue about. In these situations we have to research as much as possible to understand the product, the customer, requirements, design, and how we should be testing it. This requires some knowledge of both electronics, mechanics, and software engineering practices. A Test Engineer is truly a Jack-of-all-trades. Reverse engineering, or taking something that exists and breaking it down to the functional parts to gain an understanding of how it works is a crucial ability in this work. We may not have specs or requirements for everything we need to use in our testing. So we need to figure them out, discover how they work so that we can utilize their functionality to our advantage.
(4) Problem Solving. All of our work is intent on creating problems. Getting the computer to not start, getting the memory to be corrupted, and getting something that is guaranteed to work every time to fail. Once these failures occur, we then have to retrace them and figure out a Root-Cause, as best we can. Gathering in all the information we can so that a CR can be submitted. Engineers that just file a CR and state, “XYZ is broken.” This person did not investigate, or understand the problem. Often what happens is that the rest of the engineering team will come to the Test Engineer to fix problems, or to discuss functionality, because the Test Engineer knows the entire product; where a design engineer will only know a single part. Often I will have another engineer come to me and ask, “Should I file a CR?” The answer is always “YES”. The question is, what sort of CR is it? Is this really a problem with the product, or a problem with our testing, or perhaps a problem with the specifications. We have to interpret all of these things.
(5) Great documentation and organization skills. We have to manage a lot of things as Test Engineers. If an Engineer cannot stay organized they cannot write good tests. It is that simple. There is a logic to creating tests that requires some organization and planning. If these skills are not present then they cannot effectively do their job.
(6) I have friends! It is great to have friends in the office. It is nice to have someone to go to lunch with, if you take one. It is nice to have some sort of relationship with those we work with, our Colleagues. Being a Test Engineer is not a popularity contest. It is not a high school competition, Jocks and Cheerleaders against the Band people. We file CRs and people get offended. We find flaws in their design, and people get offended. We find things that could kill someone, but still engineers get offended. We are not doing this job for popularity. A Test Engineer finds flaws and defects in the product. They increase the quality of the product and in many cases have to hold a firm position on their duties. We cannot worry about upsetting our coffee buddy if it means a defect gets out the door. Let me tell a little story. At one time there was a product that killed someone. That person died because the person administering the product did not clearly see the period in the number they were looking at. This is why we test things and push for things that are wrong, no matter who it upsets, or how ridiculous the problem might be. Because even a decimal point can kill someone.
(7) How should it work? We test to specifications, requirements, and regulations. We never write a test on interpretations. This is not an art piece hanging on the wall, where five different people look at it and see a different picture. If it is not written in a requirement it does not get tested, if it works differently than the requirements it fails. This is so clear, and yet I occasionally meet an Engineer that will say, “But that is not how the software works.”
(8) Intuition. Sometime a lot of what we do is based on experience and intuition. Let’s test this function, because it is similar to this other function that just failed. Intuition comes with experience, it also comes with a lot of testing. Sometimes a Test Engineer actually has to run tests to get a feel for what the other person will see when they run the tests. Ad-Hoc, or free-form, testing is a testing method that is based entirely on free will and intuition. It is also a good tool to use when determining how good a Test Engineer has honed his intuition skills. A good Engineer, with a lot of good intuition, can find a lot of defects in Ad-Hoc testing.
(9) Integrity. Sometimes a test Engineer will be working for a company that has stronger regulatory relations. Such as a Medical research facility, or Medical Device company. Let’s get one thing clear; very rarely have I met a design engineer or developer that really understood what it was they were creating. See the bigger picture. Many times the Engineer working on a product does not realize that a person could die from their product. To them it is just a circuit, or a line of software code. As the Test Engineer we are the last line of defence. We have to have the understanding that this product may support, or end, someone’s life. Have pride, integrity, and good firm beliefs in what our job is for. If someone tries to convince you that something is not important, or something does not need to be tested; always remember the decimal place.
There are probably a lot more things to mention. These are just the big ones I could think of off the top of my head. I am sure there are people that will object to this. Some may even feel offended. Hopefully someone will read it and see a Test Engineer in a new light. Maybe others will understand their own role a little better.
For anyone that does not know me, I play guitar. Technically speaking, I play classical guitar. I started years ago, with the influence of my late Grandfather. Like many youngsters I tried jumping into electric guitar, then moved to acoustic, and now have fallen in love with the Classical guitar.
I have been wanting to do some recordings. Nothing that is meant to be a demo recording, or anything professional. I just wanted to record some stuff for my own learning purposes, and possibly to share with family and friends.
In my past, recording meant purchasing a microphone, plugging it into a tape recorder and pressing the record button. Actually the hardest part was pressing the record and play buttons simultaneously. Not very complicated.
When I explored the possibility of recording I thought that I would be able to just record something, but the absence of tape decks became a small hurdle. I decided to figure out a way to hook my guitar into my iMac and use Garageband for the recording. First, I tried a pickup but that did not have the desired effect. I then decided to go the old fashioned way and find a microphone.
My search for a microphone revealed that there were many types available. They were not the simple devices they were years ago. Now they required power and mixing. A microphone was starting to make me aware that a mixer was needed and then cables to connect everything. I ended up with a nice microphone, mic stand, a 5-channel mixer with phantom power supply, and all the cables to connect it to the computer.
For this article I will talk about some of this equipment and go over some of the details. I will not discuss the specific models that I used, or purchased, but the information should be helpful to anyone looking to purchase a microphone and recording equipment.
The microphone is the key to my whole recording process. I needed a good microphone that would be able to capture the rich sounds of my Classical guitar without having it sound metallic. I also had to make my purchases on a budget. I am not a professional, and I do not own a recording studio, therefore owning an expensive microphone or equipment did not make sense to me.
The microphones come in different types. There is a condenser microphone and a dynamic microphone. The main difference between them is the type of recording that will be done. First, Condenser mics are good for studio recording, and dynamic mics are good for stage and outdoors. Condenser microphones have better filtering built in, but are more sensitive to moisture and damage. Condenser microphones also record acoustic instruments better then dynamic microphones. This was the decision point for me. I wanted a microphone for indoor recording of my Classical guitar.
The down side to my decision is that a condenser microphone requires a phantom power source. This is basically an external power supply that is attached to the microphone and provides the power to it needed to capture the sound. A phantom source can be purchased, but since I would like to have some control over the input to the computer, I decided to get a mixer. The mixer connects the microphone through cables, provides a phantom power supplies, and provides a single output source that can be connected to the computer. The mixer also provides amplification and filtering capabilities to increase output sound quality to the computer. Without this amplification the computer would not be able to properly receive the signal for recording.
Garageband turns out to be a very simple recording tool. It is not much more than the old tape recorder I mentioned previously. It has appeared to me that it is a great tool for inexperienced people to throw together music without playing anything. There are some learning capabilities, but I do not need them, and will not spend time discussing them.
Recording is done within the software. Basic editing is possible after the recording has finished. Sections can be deleted and joined. One thing that is greatly missing is to have some filters, or equalizer effects that can be done to a recording. Perhaps there is some that exist in the software that I could not find, but I could not find them when I needed them. I was aware that there were some equalizers available when performing the recording, but it would be more useful to apply a filter after the recording has been made.
The sharing capabilities allow me to export the song to an album in iTunes, and later synched to my iPod, or iPad. I would also like the ability to send them to friends, but I have not figured this out either.
As a result of all my searching and playing with what I purchased, I can say that I am happy with the outcome. The recordings are getting better the more I play with the equipment and microphone positioning. There are so many combinations of settings that they will keep me busy for a long time trying to find the right combination for my instrument.
At this point in the development of our new product, we have spoken to the customer, created our business requirements, and compiled our requirements documents. We may have also started our Hazard Analysis and created requirements around safety as well.
It is important to begin the mechanism that will be used for traceability. This may be a simple spreadsheet, or a complicated requirements and trace management suite. In either case, it is important to begin the work of entering in the requirements so that they may be used by other groups.
Every design document that is generated moving forward should have a trace from a requirement to the document. This includes architecture documents, Firmware design documents, test protocols, and even test cases.
Why is this important? Well the answer goes into manageability. When we are developing our product it is important to mitigate changes in design and determine the overall impact. This is even more important in a company with no historical data to make design change decisions, or has continually missed their estimates in scheduling. If a change is made to a requirement it can be traced to each and every design location, including documents and code files, and an assessment can be made regarding the impact.
Incomplete traces is one of the biggest problems in project management. No one wants to maintain these traces. In many cases, in my experience, companies have failed to properly implement and utilize requirements management suits that could relieve much of this burden. As time in the product life-cycle continues the corruption created in the integrity of the system grows like a cancer until the system itself is no longer viable. Proper maintenance produces a more accurate impact analysis on the schedule of development.
Returning to the discussion of changes. A change is made to a requirement and indicators can be triggered to indicate what documents, what code, what hardware, what materials, and what test cases need to be updated. If a single requirement touches eighty-percent of the product design elements then it may be a more critical change than anticipated and delay the project significantly. Without the trace data that eighty-percent cannot be determined without guessing. Even with our best guess most project members forget to include the documents that need to be updated to reflect the new design changes. Proper Tractability captures all the changes that are needed in the project.
This brings me to my purpose of starting this series. In my experience stretching more than twelve years, I have developed a tractability method which traces the requirements to the test steps. In this method the requirement number is placed on the step, where it is being Verified. Seems like such a simple concept, but many companies and supervisors over the years have rejected my suggestions for implementing such a test design step. In many cases the feedback given is that it creates too much overhead in test maintenance. My experience and use of this technique proves otherwise.
Placing a requirement number at the step that is being tested allows for several things. For one, it helps to reduce redundancy and duplicate testing. Second, it improves test maintenance by decreasing the risk of missing test steps for the requirement. Third, it decreases the risk of missed coverage. Fourth, it increases the accuracy of reporting defects. Finally, it improves the search time for a requirement and reduces maintenance time.
Redundancy and duplication of requirements testing is a problem. One author may include a requirement and another not know it has been implemented in a test. This increases the test load unnecessarily and lengthens test cycles. Typically on a project the test team always takes the biggest hit in time. Time is allocated for testing and then when other delays happen that extend development time. That time is subtracted from the test time so that the product launches on the same completion date. Testers are rushed and quality of the product is always impacted. Defects slip through test and make its way into the customers product. Neither of which is a good success factor. By identifying which test the requirement is tested, the coverage and traceability of that requirement is reduced to a single point, which can be maintained more easily. Testing a requirement in multiple test cases creates redundancy and problems maintaining test cases.
When a test case is generated for a requirement there are typically multiple paths to successfully test it. There is positive and negative testing, boundary testing, failure testing, and happy-path testing. A requirement may be tested in multiple places within the document. Identifying the requirement with a simple bracket, like [R100], allows the maintainer perform a simple search within the doucment to locate the requirement and then make the necessary adjustments. This enables the maintainer to see immediately that they have some ‘x’ number of steps that need to be updated to properly implement the changes for that requirement. This search technique can also be used in audit situations. For example, in the healthcare industry an auditor may say, “Show me where this requirement is tested.” With the requirement in the document, not only can a response be given that shows it is tested in this document, but that it is tested at all these identified steps.
Decreasing the risk of missed coverage is important. It is even more important when there are safety critical requirements that need all the proper coverage. Having a requirement number in the test step helps an auditor to look at the test design more efficiently and determine if the requirement has the necessary coverage. Having the ability to search for the requirement reduces the auditors time looking for the test steps and improves the ability of the auditor to review more material in a shorter time.
When a defect happens and a test step fails, in many cases the tester is left to leave unclear information in the change request (CR). Some testers with knowledge and access to the requirements documentation may be able to look through the requirements and determine which requirement has failed, so that they can include this information in the CR. Having a requirement number at the test step increases the accuracy of reporting defects by giving the tester the immediate information they need to file their CR. The requirement is inserted into the CR and then the review board will have the information available to them to make a more accurate mitigation of the issue. The tester does not need to scour through the requirements document, hunting for the requirement that might be tested at the step that failed.
The key benefit repeated through these cases for evidence is that he requirement number at the step improves the search time for a requirement and reduces time. Time is very important to a project and this technique helps to maintain a more efficient time management of documents.
This type of traceability could be done through design documents as well, and would be encouraged. If a design document has a passage in it regarding the implementation of a requirement then it should include the requirement number. When a change is indicated and the trace is made to the document, the auditor can perform a simple search within the document to locate the passage.
It might even be said to include the requirements number inside the code, as a comment. Again, the point of this is to reduce the chance of error in missing a change related to a requirement. A requirement changes and it is important to know where that change is impacted, so that no further problems are created by the changes.
A response may be given that this level of detail is too much work, or too much overhead. It is minimal to put a number inside of brackets. It is such a minor amount of time to put a number, or identifier, in brackets at a test step when comparing it to the amount of time lost throughout the course of a project. Time that is lost searching through documents, reading test cases, or trying to understand a defect that has been filed. I have used this technique successfully for over twelve years. This minor step could actually shorten the overall project timeline, and that warrants some consideration.
In continuation with the theme, set in the previous post on Customer Requirements, this article will speak of requirements. In my last article, the importance of gathering and recording customer requirements. These requirements are used later at the end of the project, or the Validation portion of the project, to determine the successful outcome. The statement was made that no project can be successful without customer requirements. This is true, because without capturing and recording them there is no measure to determine if the project was a success or failure.
In this stage of the product development the customer requirements have been captured and recorded. Now is the time to do something with these customer requirements. Some companies will classify them, others will categorize them, some may even just divide up the list. Which ever is the method used, it all relates to the requirements process. These customer requirements now need to be expanded upon into more system related requirements.
These requirements can be gathered and recorded in any way that simplifies the process. When the end of the process is complete there will be a set of system requirements that will define the product in greater detail and allow research into development to begin.
It is also important to note that when we write requirements that they follow some simple rules.
- A requirement must be clear and cannot be ambiguous. This always is a challenge for most people. It happens so frequently in our language that we do it and do not even realize we do it. For example, the button will react properly under ideal conditions. Wow, that is a mouth-full of ambiguity. First, what defines “react properly”? Second, what defines “ideal conditions”?
It is important that a requirement be very clear. If there is an Action, then there is some reaction to that action. This must be very clear. Sometimes it helps to read the requirement back and ask, “Did I capture the specific requirement?” “Is there any part that may only be understood by me?” “Are there words used that can have multiple meanings?”
Other great examples: “The button will work.” “The device will recharge at least 10,000 times over the lifetime of the device.” “The colors will be pleasant to the user.” “The software will be easy to use by design.” “In the ideal condition the device will…”
Try to identify the ambiguity and subjectivity in the statements above. These may seem incredible, and some actually from requirements of real devices on the market today. This leads to the next rule.
- Singularity. A requirement should elicit a singular understanding and objective. For Example, “When the user presses the Exit button the software will Exit.” There is an action, pressing the exit button; and a clear result, The software exits. There is no ambiguity, well maybe the term Exit, but this could be defined in a glossary within the requirements document.
Some examples of failure of this rule: “The list screen will display a File, Edit, View, Tools, Windows, and Help menus.” “The screen will be able to display up to 256 colors. (See appendix A for a table of all the colors)” “The button will have a label, in Arial font, size 10px, with an icon, and data value.”
Reading the examples given will help to demonstrate what it means to have a requirement that does not follow the rule of singularity. There is also an example that combines the failure of this rule and the failure of the ambiguity rule.
- Contradictory. A requirement that conflicts or opposes the functions defined by another requirement. This can more commonly happen when multiple people are writing the requirements for different areas. One person may write a requirement that states, “The button shall be blue.” Then in another section a different author, referring to the same button, might say, “The button shall be red.” These are conflicting, or Contradictory requirements. It becomes a problems because it is not unclear if the button should be blue or red.
Other examples: “The On button will turn on the light.” “The On button will turn on the monitor.” “The data field will display the result.” “If the result in invalid it cannot be displayed.” “The screen will have a Cancel button.” [same screen] “The screen will have a Back button.”
- Test-ability. This is one that most requirements analysts miss. This is why it is so important to have a member of the test team present when creating the requirements at the very beginning of the project. It might even be helpful to hire someone with a lot of test experience, and requirements experience, to write the requirements for the project. Test-ability is a hard thing to think about. Sometimes I believe it is impossible for a Marketing, or person with an MBA, to consider this rule. A business requirement may be, “The device will recharge 10,000 times over the life of the product.” That may be a good thing to put in the advertisements, but from a testing and Engineering perspective it is a nightmare. First, what is the MTBF, or life expectancy, of the product? Secondly, how to we drain and charge the device 10,000 times? I have read business, and marketing requirements, that would take years to fully test. Most companies do not have years and no test team is ever, EVER, given the time they budget at the start of a project. The people we entrust to measure the safety, quality, and reliability of our products are always shorted their time needed to perform these duties. They are almost always expected to put in long hours, for as many as seven days a week, to make up for the time shorted to them by project management. They are rushed, tired, and stressed. In the end when something goes wrong, or a person is injured by the product, or killed by the product, the test team is blamed for not catching it. Good requirements are the first step to ensuring good design and good reliable testing.
While the requirements are being generated the test team can begin planning the test suits that can be used to test the product. Some test drafts may even be created during this time. These draft tests will help to perform some integration testing during the creation and design of the device.
Another concurrent process is a Hazard and Risk analysis of the system. Although not all projects will require this, it is required for Aviation, Medical Devices, Government Contracts, and System Critical applications. The hazard and risk mitigation generated by this review are fed back to the requirements team, who then can create safety related requirements for the development team. This will help to ensure that these safety items get the proper implementation and test coverage.
The final piece of the requirements madness is the Traceability matrix. A Traceability matrix is a table that identifies a link between the requirements, their source, and where they are tested. This trace will eventually become a reverse tree structure that is more narrow at the top and wider near the bottom. The top of the table begins with the user requirements and then ends at the bottoms with hardware, or firmware requirements.
It is very important to establish this matrix as quickly as possible. So many companies fail at this step. Almost all, including companies within Agile organizations, will not complete this until the end of the project, which is the wrong time. A Traceability matrix is more than a sustainability tool, it is a product development tool.
A Forward and Backwards traceability matrix will ensure that if any requirement changes at the top or the bottom, the connected requirements are identified. This enables developers to narrow their focus on changes, and enables the test team to redefine the proper test cases. The over all impact is a faster turn around to changes and defects found during development and reduces the overall all time to completion. I will say that again for the project managers listening. This method, if done properly, will help to reduce the project time to completion. Delays kill the project time line. Any method that can reduce or mitigate those delays is vital. I am really surprised that more project managers do not incorporate this documentation and tool earlier than is done.
A traceability matrix can be done manually, but not many know how to any more. These can also be done with software tools that can be expensive and cumbersome to manage. Total reliability on the software to handle this without knowledge of the software can cripple a project team at the wrong time. Not being able to extract the proper information, or extracting false information can hurt the project timeline. It is important to understand that although the software tools may help in the creation, usability, and maintainability of the traceability matrix it comes at a price. Without proper training of the team, and proper management of the database this can lead to disaster.
At this point the planning stages are set. Requirements are being generated, analyzed, planned for, and traced. There is still so much more to do on the project and we have only gotten through the start of it. However, shorting these initial steps could lead to problems later in redesign and rework. As much as people in software development complain of the overhead related to the CMM [Capability Maturity Model], there is one thing that holds true 100% of the time: “Catch a mistake early and it could cost nothing, catch a mistake when a product goes to market and it could cost millions.”
When I thought about the first article I wanted to write for my big return, I thought about something that I have been researching and working on for over ten years. Then I thought it would be better to start at the beginning of things.
For such a long time I have been in the business of Engineering software. In particular, Software Quality Control, Software Test, Regulatory, Requirements Management, Documentation, Software Quality Assurance, Systems Engineering, Product Support Specialist, and more. In addition to all this, I have written software and delivered software products to customers that were not related to my normal full-time job.
Since my background is in software development I thought I would begin with that as my first topic. What better place to begin than with requirements?
This field has so many conflicting, and alternate, view points that many that read this will say, “This guy is an idiot, that is not how it works.” In reality, NO ONE GETS ANY OF THIS PERFECT. That means for the person I just quoted above, I have some bad news, your way does not work either. I can say this because if there was a company out there that did everything perfect, there would be no room for improvement. We could just all do it their way, and no one would have to write articles like this. If it is one thing that anyone on a project in this field knows, this is all about constant improvement.
Back to my topic. The first step in any project regarding anything and everything that is, and will be, created is research. There is this idea, a concept, and someone wants to know how it can become a reality. It is a concept that applies outside the realm of Engineering, and in it at the same time. It requires some creativity and some really good communication skills.
No project can exist or succeed without this step. I will repeat that so that someone already bored and wants to just reach the end can hear it again. NO PROJECT CAN EXIST OR SUCCEED WITHOUT THIS STEP.
The project begins with research. Gathering details about your idea. What is it? How will it work? Here is the most important part. What will others want? That is the part most companies fail at. It is fine that a developer wants to create the next big software calculator. The real questions are, how will you do it different then the multitudes of other calculators, and most importantly what is the user missing in all of them?
Customer requirements are fundamental to the project. Without them there is no gauge to determine success. Sure a product could be made and developed but if it does not satisfy the customer it fails. This first stage in development becomes very important.
Most companies, in my experience, have these products that they have engineered for a field, or industry. Some have bought products that another company engineered. Many of these companies do not even perform basic research to determine what the customer wants. They assume that the world needs another calculator and they are going to make one to fit in with the others.
A calculator is a simple idea, but there are companies that feel the same way about medical equipment, automobiles, operating systems, shoes, fishing poles, mountain bikes, and so many other things.
A medical device that can preserve or kill a persons life, but the company concern is only making money. That have not asked what the customer is interested in, or needs. This one thing causes everything they do to fail.
To summarize, customer opinion matters. If a person needs a calculator, a watch, a television, a new shoe, a car, a pencil, a pen, a book cover, headphones, a sewing machine, or anything imaginable, find out what they really need. Asking questions, talking to people, gathering the opinions, feelings, and needs of them. Find out what they like AND dislike about other products. Find out if they have a product and how it could be improved to make their job, or process, better.
Once these customer requirements are gathered, then the real design work can begin. That is when the writer writes, the Engineer designs, the seamstress sews, and the carpenter builds.
Then when we are all done with our work we can look back at those requirements and ask the customer, did we hit the target? Did we succeed at filling the void, or did we create a new one? This is not a question that we can ask ourselves. It has to come from the customer because they are the ones willing to pay for it. They were the ones that asked for it when we spoke to them about what they needed. They are the ones that give meaning to designing and creating new things. If no one buys the product then it is a failure. It does not matter how good the design is, it fails.
If you are on a project, or even creating the next great calculator. Ask the users if they need this, or what they want. It will make a difference later in the success of any project. A simple idea, and yet so hard for many to do.