System requirements is a statement that identifies the functionality that is needed by a system in order to satisfy the customer’s requirements. [1] System requirements are a broad and also narrow subject that could be implemented to many items. Whether discussing the system requirements for certain computers, software, or the business processes from a broad view point. Also, taking it down to the exact hardware or coding that runs the software. System requirements are the most effective way of meeting the user needs and reducing the cost of implementation. [2] System requirements could cause a company to save a lot of money and time, and also can cause a company to waste money and time. They are the first and foremost important part of any project, because if the system requirements are not fulfilled, than the project is not complete.
System requirements are a broad and also narrow detailed statement that the customer makes in order to achieve their requirements. The statement should clearly explain what the customer exactly wants and how they want it. A customer’s need might be to satisfy a contract, solve a problem, achieve an objective, meet a standard, or to meet any other guidelines of the project. [1] System requirements will always vary depending on the project and no two systems would have identical requirements. For instance, if two companies were wanting to build a wireless phone. Company A could have requirements for the phone to be different colors, light weight, and transparent. Company B could have touch screen, all black, and also to be in-between 1 lbs. – 1.20 lbs. for their requirements. These examples are just the simple constraints for a product. There could be thousands of other requirements for the wireless phone. Including, chip maker, what products to use, and cost of course. There is no such thing as a correct amount of system requirements. This can vary from product to product or solution to solution. A flying plane could have millions of requirements, compared to a bicycle that could have a hundred requirements. As well, the requirements for solving the issue of hand washing would be a lot less than the requirements for sending a person to Mars. [3] Yet, having too many system requirements for a project could cause the cost and time to dramatically increase. On the other side of that, having to few requirements might cause your system to not work correctly, or last as long as you like. Thus making the requirements the most important aspect of a system. See sample picture below for customer requirement.
[5] Here is an example of the process of a system requirement for a customer.
System requirements can come from the customer, the company, or even other larger groups that set the requirements for specific and whole categories. From a macro view to a micro view or system requirements. Think of the highest of groups, the government, that could issue requirements for systems. These requirements are set on the highest stage and have to be implemented down to a single person. For example, the government has hundreds of divisions that set the general bench mark to certain system requirements. These requirements could be for vehicles, food, medical, and anything else. Not only do companies and customers have to meet these requirements, but also the requirements set forth by the customer/company. With system requirements being significant to the process of the project/product or what the customer needs, it is necessary for the person who is submitting the requirements to know exactly what they are. With system requirements being set by many factions. The ending customer usually has the most requirements to be set. For instance, the federal government has requirements on the environmental footprint a manufacture can have making requirements. [9] This is a system requirement that is based on the federal level. The next level could be state level requirements of stricter rules upon the first requirement and also a system requirement of how that product is tested and designed. Then the customer has their system requirements which are the most important and usually the most thorough and extensive list. The company or person who is trying to meet the system requirements should already be aware of the top two tiers of the requirements. The customer’s requirements are the ones that are most important and matter the most.
Requirements should not be verified by analysis or examination. They should be verified by test, and only test will be able to tell if the requirements were met. [4] System requirements are implemented to make something reliable. Some examples of system requirements could be; the size of memory needed to install a software on your computer, the miles per gallon a car needs to get, the printing speed of a printer, or could be any requirement for car in general – breaks, locks, engine, wheels. There can be simple requirements and extensive requirements. System requirements are necessary for any system that is trying to be successful. Yet, there are some requirements that should not even be listed. Requirements are not supposed to put further challenges on the project. The only system requirements that should be listed in the requirement statement are the ones needed. When the requirement does exist and is needed. The precision of the accuracy of the requirement can save time and money for the company. [8]
For system requirements, there are many methods for a company/person to improve their system requirements. Companies that want to increase their percentage of the system requirements met, can do many task. For example, if a company were to do significant system requirements on their product and find an issue in the development stage. It might cost the company a few extra dollars to have that fixed at once. If they didn’t have the system requirement for that design, than it could cost the company twice or more to fix the same issue. [6] Having the technology and skills to master the system requirements and to implement them can save a company a lot of money. Having the right processes and people to test out the requirements can help the customer get exactly what they want. The more improve requirement testing, the better satisfaction for the customer.
Having a well-designed requirements for a project can save the customer a lot of time and money. Listing out the details of specific requirements before the project proceeds and advances will do the company world of good. Having test and making products, and then learning that a requirement was skipped to save money will cost even more money down the road.
System requirements could be thought of being well designed to a customer, yet some requirements could have been misplaced simple do to cost or time cutting. In 2010 Toyota had an issue with some of their cars driving out of control. The issue was that the floor mats were becoming lodged under the accelerator. If the company had a requirement to test out all moving parts inside of the car, then that missed this requirement. This incident caused a five billion dollar recall cost to the company. [7] This would be an example of not having enough system requirements for the vehicle. The customer has to decide if the cost would be great to implement a well thorough system requirement, or pay the cost to fix the original design. When system requirements are poorly designed the project itself will more likely be a failure. Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects. [10] Companies that do not have a well-documented and thorough requirements and other business analysis will have three times more project failures as successes. Meaning system requirements is a necessity to the overall success of projects. These requirements could make or break a company some times. For a lot of companies, they think they will have success because there would be no failures/mistakes in the beginning. Yet, long term wise, the company could see failures in their products years down the road. The most recent example of system requirement failure would be Volkswagen. The requirement they set fourth was to have certain emissions from their diesel engines. These system requirement was a big selling point for their vehicles. Come to find out, the company had a software that could detect when it was being tested. The software than would change the performance of the test to show better than expected numbers. This was a total scandal and will probably ruin the company. There was a requirement that was presented, yet the company was doing illegal methods to reach it. This will cost them about $9.5 Billion in relation to the emissions scandal. This does not count the losses the stock has seen on the stock market. [10]
In conclusion, system requirements are one of the foundations to building a successful project. System requirements are a broad and also narrow detailed statement that the customer makes in order to achieve their requirements. The customer should have a list of exact requirements they specify. The more rigorous and quantity of requirements, the higher the price. The customer always needs to find the middle ground of having enough requirements to meet the needs and also to meet their budget. Having requirements from a top organizational unit all the way to the customer and then to the producer can have implications on products. That is why the thoroughness and completeness of the system requirements is a huge deal. Without system requirements, the project will be a failure and the company will fail. If the customer has system requirements that will satisfy their needs, then that company will have a higher percentage of success. Not only will they have success, but they will also have better chance of saving money and time. System requirements should be the building blocks and one of the first things established for any project.
1) Bahill, A. Terry, and Frank F. Dean. "4 Discovering System Requirements."Handbook of systems engineering and management (2009): 205.
2) Mumford, Enid. "Defining system requirements to meet business needs: a case study example." The Computer Journal 28.2 (1985): 97-104.
3) How Many Design Requirements? (n.d.). Retrieved November 3, 2015, from http://www.sciencebuddies.org/engineering-design-process/how-many-requirements.shtml
4) Grady, Jeffrey O. System requirements analysis. Academic Press, 2010.
5) Sample Process Diagram. (n.d.). Retrieved November 13, 2015, from http://blog.isocertsolutions.com/Portals/210543/images/sample process Diagram.png
6) Wiegers, Karl, and Joy Beatty. Software requirements. Pearson Education, 2013.
7) 5 Of The Largest Car Recalls In History - Slideshow | Investopedia. (2012, May 22). Retrieved November 1, 2015, from http://www.investopedia.com/slide-show/car-recalls/
8) Robertson, Suzanne, and James Robertson. Mastering the requirements process: Getting requirements right. Addison-wesley, 2012.
9) Five Areas of Government Regulation of Business. (n.d.). Retrieved November 5, 2015, from http://smallbusiness.chron.com/five-areas-government-regulation-business-701.html
10) Study: 68 percent of IT projects fail - TechRepublic. (n.d.). Retrieved November 4, 2015, from http://www.techrepublic.com/blog/tech-decision-maker/study-68-percent-of-it-projects-fail/
11) 5 Of The Largest Car Recalls In History - Slideshow | Investopedia. (2012, May 22). Retrieved November 19, 2015, from http://www.investopedia.com/slide-show/car-recalls/
Assess the Design's Ability to Meet the System Requirements. (n.d.). Retrieved November 5, 2015, from http://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/system-design-and-development/assess-the-designs-ability-to-meet-the-system-requirements
Benner, Kevin M., et al. "Utilizing scenarios in the software development process." Information system development process 30 (2014): 117-134.
Sommerville, Ian, and Pete Sawyer. Requirements engineering: a good practice guide. John Wiley & Sons, Inc., 1997.
Yu, Eric, Eric Dubois, and John Mylopoulos. "From organization models to system requirements. A cooperating agents approach." in: 3rd Intl. Conf. on Cooperative Inf. Sys.(CoopIS-95. 1995.
Robertson, Suzanne, and James Robertson. Mastering the requirements process: Getting requirements right. Addison-wesley, 2012.
Kulak, Daryl, and Eamonn Guiney. Use cases: requirements in context. Addison-Wesley, 2012.
Schamai, Wladimir, et al. "Virtual verification of system designs against system requirements." Models in Software Engineering. Springer Berlin Heidelberg, 2011. 75-89.
Barrett, Steven RH, et al. "Impact of the Volkswagen emissions control defeat device on US public health." Environmental Research Letters 10.11 (2015): 114005.
Robertson, Suzanne, and James Robertson. Mastering the requirements process: Getting requirements right. Addison-wesley, 2012.
Jonasson, Hans. Determining Project Requirements: Mastering the BABOK® and the CBAP® Exam. CRC Press, 2012.