What intentional and unintentional errors in business analysis can lead to...and what impact it can have. This blog provides a guide to help the business analyst understand the consequences of errors in requirements and designs.
Unintentional:
One of the most unlikely incidents occurred due to a software bug in the Therac - 25 medical radiation therapy device in 1985-87. This machine was used to administer radiation doses on patients, and in several cases the faulty device administered excess quantities of radiation. In some cases, it exceeded 100 times more than the intended dose, and resulted in several injuries and three deaths.
(Source: https://en.wikipedia.org/wiki/Therac-25)
Technology is like a 'Gift of Fire,' as correctly mentioned by Sara Baas in her book where she gave many examples of such disasters.
Correlating to her thought, it would be appropriate to ask a business analyst, “are you designing for a disaster?”
Many business analysts working on a project, especially a large project, fail to see the complete picture. This alone can lead their company or their client to the disaster.
Along with software design, development and testing, requirement analysis and design is key part of developing software solutions.
It is the business analyst who elicits a particular requirement or functionality document, confirms, and sign it off before communicating the requirements to the technical team. The requirement states precisely how it works under normal conditions, in an alternate process and possible error it may have.
What are the rules applied to the requirement? What is acceptable and not acceptable in terms of data, rules, format and so on?If the error lies in the requirement/functionality, intentionally and unintentionally goes undetected, could it lead to major disaster depending on the project/product it is used?For example, a decimal place mentioned incorrectly in a requirement document in banking software that deals with millions of transactions could potentially make a serious impact with loss of few millions dollars.
A particular requirement or function used in laser arm robotic surgery could be seriously impaired.
Defective transportation software could potentially cause loss worth millions and delay.
A space ship or flight software could cause an accident if any fault occurs in the system.
These are just a few examples of the thousands of potentially damaging situations that could arise if the software requirements are not documented and implemented correctly.
Intentional:
Of course, there could be intentional error in the requirements for designing the software solution to mislead authority. The most notorious example is how Volkswagen managed to manipulate the car emission system for two decades. Of course, when they are caught, they have to cough up close to 18 billion dollars in penalties, not considering the loss of face and brand value.
Oops...How brilliantly one can misuse the use of software... The team of business analyst/stakeholders/project manager who designed software never thought it would ultimately cost billions...
(Source: http://time.com/4046994/volkswagen-emissions-golf-crisis/)
Undetected hole in the ozone layer over Antarctica: This is another serious issue that impacts the whole world. The software that was used by NASA to map ozone layers had been designed to ignore certain values that deviated greatly from expected measurements.
Therefore, the hole in the ozone layer went undetected until 1985, even though the project was launched in 1978. It was only found after the scientists at NASA reviewed the data for abnormal results and found the error and the big hole.
(Source: http://royal.pingdom.com/2009/03/19/10-historical-software-bugs-with-extreme-consequences/)
The business Analyst's role goes far beyond the requirement lifecycle, as their role and responsibilities are not limited to just requirements or the solutions...but the total solution and its overall impact on the organization and beyond. Their contribution could possible make or break the organization.
Please read my book for more details: Business Analysis: The Question and Answer Book available on Amazon and other places in Kindle and paperback.
Unintentional:
One of the most unlikely incidents occurred due to a software bug in the Therac - 25 medical radiation therapy device in 1985-87. This machine was used to administer radiation doses on patients, and in several cases the faulty device administered excess quantities of radiation. In some cases, it exceeded 100 times more than the intended dose, and resulted in several injuries and three deaths.
(Source: https://en.wikipedia.org/wiki/Therac-25)
Technology is like a 'Gift of Fire,' as correctly mentioned by Sara Baas in her book where she gave many examples of such disasters.
Correlating to her thought, it would be appropriate to ask a business analyst, “are you designing for a disaster?”
Many business analysts working on a project, especially a large project, fail to see the complete picture. This alone can lead their company or their client to the disaster.
Along with software design, development and testing, requirement analysis and design is key part of developing software solutions.
It is the business analyst who elicits a particular requirement or functionality document, confirms, and sign it off before communicating the requirements to the technical team. The requirement states precisely how it works under normal conditions, in an alternate process and possible error it may have.
What are the rules applied to the requirement? What is acceptable and not acceptable in terms of data, rules, format and so on?If the error lies in the requirement/functionality, intentionally and unintentionally goes undetected, could it lead to major disaster depending on the project/product it is used?For example, a decimal place mentioned incorrectly in a requirement document in banking software that deals with millions of transactions could potentially make a serious impact with loss of few millions dollars.
A particular requirement or function used in laser arm robotic surgery could be seriously impaired.
Defective transportation software could potentially cause loss worth millions and delay.
A space ship or flight software could cause an accident if any fault occurs in the system.
These are just a few examples of the thousands of potentially damaging situations that could arise if the software requirements are not documented and implemented correctly.
Intentional:
Of course, there could be intentional error in the requirements for designing the software solution to mislead authority. The most notorious example is how Volkswagen managed to manipulate the car emission system for two decades. Of course, when they are caught, they have to cough up close to 18 billion dollars in penalties, not considering the loss of face and brand value.
Oops...How brilliantly one can misuse the use of software... The team of business analyst/stakeholders/project manager who designed software never thought it would ultimately cost billions...
(Source: http://time.com/4046994/volkswagen-emissions-golf-crisis/)
Undetected hole in the ozone layer over Antarctica: This is another serious issue that impacts the whole world. The software that was used by NASA to map ozone layers had been designed to ignore certain values that deviated greatly from expected measurements.
Therefore, the hole in the ozone layer went undetected until 1985, even though the project was launched in 1978. It was only found after the scientists at NASA reviewed the data for abnormal results and found the error and the big hole.
(Source: http://royal.pingdom.com/2009/03/19/10-historical-software-bugs-with-extreme-consequences/)
The business Analyst's role goes far beyond the requirement lifecycle, as their role and responsibilities are not limited to just requirements or the solutions...but the total solution and its overall impact on the organization and beyond. Their contribution could possible make or break the organization.
Please read my book for more details: Business Analysis: The Question and Answer Book available on Amazon and other places in Kindle and paperback.
#BusinessAnalysis #Design #Disaster #SoftwareDevelopment #RequirementManagement #ProjectManagement
No comments:
Post a Comment
Thank you for your feedback!
Please do not add any promotional link or website or products as they will be removed. If you wish to create an advt to promote your products, services and company on my blog, please write to me at - sandhya@anisans.com