Software Requirement Analysis— Necessary or Unnecessary?

Steve Jobs Never Listened to His Customers

“It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.” — Steve Jobs

Apple doesn’t do market research; Steve Jobs never listened to his customers. [1] Customers use products, while producers develop products. It is hard for customers to imagine an ideal product without seeing it, and tell the producer what they want. Innovation is of great importance for the survival of a company. If a company can always put innovation in the first place, it will has a great many opportunities to give customers surprises, offering real attractive products to the world.

We are not Steve Jobs

Exactly, we are not Steve Jobs. Besides Apple, there are certainly other companies did graceful innovative works, and managed running successful business. However, lacking of requirement analysis in software developing can cause huge risks. What if a company has spent a lot of time developing software that customers do not really need?

For example, customers want a kind of software that can help children to be interested in reading. To achieve this goal, an attractive GUI is required, as well as a nice sound effect. Nonetheless, the company comes up with software with huge font size, saying that this is to help children to remember words better. In the end, it is probably that the software will be a disappointing product. You may think: how can a company be such an idiot? Well, it is just a simple example, what I really want to say is, understanding the requirement of a software is undoubtedly necessary.

Software Requirement Analysis is Like a Translator

The purpose of software requirement analysis is to understand the exact requirement of a product, and build a basic standard for the product. To be noticed, the requirement of software is probably changing all the time; as a result, requirement analysis is necessary to be done throughout the whole development process. Requirement analysis is like a translator, to help both the customer and producer to understand each other’s “languages”, so that they can have the same understanding for the product. [2]

Understanding the Background of the Software is Necessary

However, as a developer, does it mean it is enough if we just understand what customers tell us to do? Absolutely not!

One of the basic principle of software requirement analysis is to understand how the requirement comes, i.e., why does it needed. Why it is necessary to understand “why”? The answer is, we can know more about the background of the needed software. So, why it is necessary to understand the background?

A developer basically has a good skill of producing software of good quality; however, when the product is used in different situations, does it really of good use? The answer would be not sure. This is the reason why developers also need to understand background of the software. Besides the needs mentioned explicitly by customers, there are also some implied needs. A “good” requirement analysis can describe the required functions well, and help developers to come up with satisfactory functions for the product; a “better” one can go further based on the background. [3s]

For instance, if a chain company requires a system for handling their products sales status, so that the branch offices can collect and pass the data to their head office. This is quite a simple requirement for the product. However, after the analysis of the background of this company, it has been found that the company has tens of chains. As a result, the producer suggests a distributed and parallel system for the company, so that information can be managed without complicated manual sending and receiving processes. What’s more, data consistency can be easily achieved.

Understanding the Change of Requirement is Necessary

Understanding the change of requirement, or communication, is necessary. Communication always lies in the center of many processes of software development, in requirement analysis, it also does.

The key to the success of analysis is a perfect understanding of every requirement, while the requirement keeps changing. Today, your customer tells you he needs a kind of software to record how much money he spends each month; tomorrow, he may ask for another function for suggesting how to save money. When it comes across a large-scale software development project, the requirements change more rapidly, making the whole process more complicated. Thus, a good communication is of great value to help developers to know exactly what the customers want and catch whatever changes in time. Guessing the requirements of customers may bring a software product into a disaster.

So, a Good Software Requirement Analysis is Necessary (A Summary)

Of course Jobs is right, innovation can give quite a lot opportunities for a company. Infinite market researches or requirement analysis may stop his company from making progress. But as far as I can see, a large amount of software products need to be developed based on software requirement analysis.

Software requirement analysis is like a translator, which can help companies to understand what the customers really want (to obtain comprehensive and detailed requirements of customer), and keep pace with the latest requirement without omitting any small changes (to prevent the misunderstandings of the requirements). A good requirement analysis can help a company to provide splendid products for customers, avoiding wasting time and energies on useless works.


[1] Why Steve Jobs Never Listened to His Customers


[3] Davis, Alan M. Software requirements: analysis and specification. Prentice Hall Press, 1990.

Response to Article: “Earned Value Management is not a mathematical game” by s1335336

This is a response article to “Earned Value Management is not a mathematical game” by s1335336 (

Paper Summary

In the article, firstly, the basic concept of Earned Value Management (EVM) is introduced. Secondly, a practical project case is presented in an interesting way, to give a more comprehensive explanation of the use of EVM in real-life situation, and how EVM benefit the whole project management process. Thirdly, factors that give negative impressions on using EVM are mentioned. Fourthly, considerations of how to improve EVM performance in terms of its three basic elements- Planned Value (PV), Actual Cost (AC), and Earned Value (EV), are discussed.

Merits and Drawbacks of the Article

I agree with the author that EVM does benefit a lot in the process of project management. As we know, EVM provides an estimation of whether the cost and performance of project is acceptable or not, by comparing and calculating PV, AC, and EV. Of course, many other methods can also be used in measuring project performance and progress, such as Function Point Analysis, Cost Estimation Methods. However, many subjective human judgment errors can be made when using those “other methods”, causing inaccuracy of the estimation of the progress and cost. EVM can measure project performance and progress in an objective manner, providing a more reliable result of the estimation. Using PV, AC, and EV, the project progress can be expressed in a mathematical way; numbers are the evidences of every conclusion.

I agree with the author that, EVM provide a mathematical way to estimate the cost and performance of projects, but it is not a mathematical game. Numbers do present a great many facts of the project that can rely on to make proper changes to the project plan; however, numbers are not everything, they are only valuable under the support of facts. For example, if an important step of the project is carelessly treated, or the feasibility of the project is too low, the project will still be a disaster although the mathematical result seems to be graceful.

I also agree with the author that the performance of EVM is not one hundred percent successful, many factors can lead non-ideal results, such as bad project planning and tracking, and lacking of reliable data from the project.

Besides, I think this article can be improved in the following aspects.

On one hand, the article present how EVM is made of good use in the example. I think a summary should be added to conclude how EVM benefit the whole project. As far as I can see, from the article, it can be summarized that EVM can give a project better investigation about its status. By using EVM, the project tracking and control process, as well as the decision making process can be better implemented. Whenever the project progress or the actual cost is unacceptably biased, EVM can gracefully help to analyse the situation and come up with the relative solutions to mitigate the situation and reduce the overall project risk.

On the other hand, I think methods to measure earned value is also worthy of mentioning. Although the relevant calculation of EVM is not complicated, accurate measurement task of EV is not that easy, and is the key point of EVM. There are some common measurement methods of EV [1]. (a) Linear growth measurement: The overall cost will be allocated proportionally to different part of the project, but in each sub-part, the cost will be equally allocated. EV is recorded according to the completion percentage. (b) 50-50 rule: 50% of the cost is recorded at the beginning of the task; the other 50% will then be recorded at the end of the task. This method is more suitable when the task has multiple sub-tasks. (c) Quantity measurement: The cost is allocated equally to each small part of the task. EV is recorded according to the number of the completed parts. (d) Node measurement: Divide the whole project into multiple nodes and assign each of them an EV. When a node finishes its task, the EV of the task is recorded and added to the overall EV.

More about EVM

Based on the research I did about EVM, I’d like to mention more about it, to stress some ambiguous points.

First, if a project has a valuation of planned work, progress and budget, then EVM is a good choice for this project. [1]

Second, EVM can always decide what is going to be done in the future work of the project; this is the reason why EVM is not only a tool for control and tracking, but also a tool for planning. [3]

Third, huge amount of data of the project needs to be recorded in EVM process. When the data comes from different teams, different departments, or even different companies, the situation is harder. As a result, in order to make good use of EVM, teamwork and communication is of great significance. [1]

Fourth, EVM needs to be used together with other project management methods. Relevant methods can make great improvement for the performance of EVM, such as Gantt chart and milestone chart. [2]

Fifth, trying to re-define the process of EVM is not a good idea. Changes in EVM can affect a great deal of the project progress, or even bring the project into a disaster. [3]


In conclusion, I appreciate the usefulness of EVM in project tracking and control, as well as the accuracy of the mathematical results. Project risk can be reduced in a good manner by using EVM. What’s more, I added some extra comments on the measurement methods of EV, which is not as easy as other related calculations of EVM. Furthermore, I mentioned some considerable points in the process of EVM.


[1] Fleming, Quentin W., and Joel M. Koppelman. Earned value project management. Project Management Institute, 2000.

[2] Ferguson, J., and Karl Heinz Kissler. Earned value management. No. CERN-AS-2002-010. 2002.


A Review of Two Software Risk Management Methods

Software risk management is necessary

Currently, information industry is growing quite fast. Not only the number of the technologies but also the complexity of the user requirement of software development is increasing. As a result, software companies need to try their best to improve the product quality as well as reduce the development cost. Hence, only when software risks are managed and controlled well can the companies run their business successfully.

In the process of developing a software, when an unsatisfied outcome that can cause negative impacts has a certain possibility to happen, it can be called as a risk.[1] To handle these risks, a great amount of approaches had been developed. In this article, two of the popular ones will be briefly introduced and compared– Boehm’s Risk Management Method and SEI’s Risk Management Method.

Two popular methods

* Boehm’s risk management  method[6]

Boehm, a famous software engineer, contributed a lot in the area of software engineering. Boehm’s risk management methods is also a classical one which can give developers a lot of graceful ideas.


As Figure 1 shows, there are 2 primary phases in Boehm’s method, risk assessment and risk control. In risk assessment, there are three sub-steps: risk identification, risk analysis, and risk prioritization. In risk control, there are also three sub-steps:risk-management planning, risk resolution and risk monitoring. Now a brief explanation for each of the sub-step will be given below:

➤ Risk identification: Produces a list of the risk items according to the specific project. One of the major techniques for this is Boehm’s top-10 software risk items checklist contains the top-10 risk items produced by Boehm in terms of his research, and the management techniques from Boehm for each risk item.

➤ Risk analysis: Makes assessments of the relevant loss and the possibility of the unsatisfied outcome, in terms of each of the risk item listed in the risk identification phase. Besides, assesses the compound risks when all the risk items appear in the same project.

➤ Risk prioritization: Produces a ranked ordering of the risk items. One of the major techniques is calculating the “risk exposure” quantity by multiplying the relevant loss and the possibility of the unsatisfied outcome of each risk item, then make a combined consideration of the three values, i.e., the risk exposure quantity, the possibility of the unsatisfied outcome, and the relevant loss of the outcome.

➤ Risk-management planning: Provides a plan for each risk item, as well as an overall plan for the whole project. A useful tool here is also Boehm’s top-10 software risk items checklist. Plans of numbers of specific risk items can be made according to the checklist without wasting too much time and effort. This phase makes a preparation for the risk control process.

➤ Risk resolution: Implements all the elements in the plan to provide a suitable situation for eliminating or resolving the risk items.

➤ Risk monitoring: Offers the whole project a tracking, in order to ensure the risk management process is under control.

* SEI’s risk management method[2]

Software Engineering Institute(SEI), is a federal research center for software engineering funded by the US Air Force, to improve software system quality, safety, reliability, and so on.

Figure 2 presents the SEI’s Software Management Model, known as SEI-SRM Model, consisting of six parts: identify, analyze, plan, track, control, and communicate.


In the phases of identifying risks, analyzing risks, planning and part of communication, the Software Risk Evaluation (SRE) [2] methodology acts as an important role. SRE Team consists of numbers of software engineers. The duty of SRE Team is analyzing relevant issues and document the result according to the requirement of the project. [2] SRE Team also offers helps when there are unexpected situations.

➤ Identify: Each member of the SRE Team identifies the risk items according to a taxonomy which lists all the potential risk areas, then documents them on the Statement of Risk, which is part of the Risk Management Form.

➤ Analyze: This phase is also supported by SRE Team. Each risk item identified in the first phase will be analysed in terms of its possibility of occurrence and the relevant loss, etc. After that, items will be prioritized and set as different Risk Levels. Lists of risk items with their Risk Levels and an updated Risk Management Forms are produced.

➤ Plan: SRE Team members make a combined consideration of both individual risk items and the whole project, then produce a Risk Management Plan. What’s more, documentations about how to make sure the risks being handled are also provided by SRE Team.

➤ Track: The status of the risk are always being monitored. Whenever the threshold in the relevant documentation is exceeded, actions should be taken to mitigate the risk.

➤ Control: In the Risk Management Plan, there might be deviations. Risk control acts as a role to manage risk plans and make corrections to the deviations, so that the whole process can be improved.

➤ Communicate: Communication lies at the center part of the SEI-SRM model, connected with every other parts. In the whole software risk management process, communication is also significant. Whenever there is information being collected, it should be passed to others for integration so that personnel can share information together, work in the most effective way and come up with the best results. Communication is also necessary between different organizational levels, such as the developer, the customer, and the user. Without an effective communication, no successful risk management process can be implemented.

What are the merits and drawbacks of them?

After the introduction to each of the two risk management methods, a discussion of them will be given below.

Boehm’s method has a high reputation among the software risk management area. The top-10 software risk checklist is a useful tool in many phase of the whole process, saving personnel, time and efforts.[3] The concept of “risk exposure” is also a graceful estimation technique for the criticality of the risk item. A good many investigators have been inspired by Boehm’s idea for further researches. However, several drawbacks cannot be ignored. The top-10 list is just a summary of risk items by integrating relevant information. It lacks convincing articles about its fundamental theories, original data, and induction methods. As time goes by, it is changing continuously, and of course needs to be modified continuously. Moreover, the listed risk items can also be changed according to different risk management methods, so it does not fit all the situations. Thus, the top-10 list needs to be improved and expanded although it has certain universality and practicality. Besides, the estimation of both the possibility of the occurrence of the risk and the relevant loss cannot be one hundred percent accurate. As a result,  the “risk exposure” quantity itself is a risk item.[4]

With the participation of SRE Team, relevant discussion can be made whenever and wherever needed during the risk identification, analysis, and planning process, making the information collection and integration more graceful. This increases the reliability and the efficiency of the risk management process. This works even better when the environment is well planned and the whole process is well managed.[5] However, it may take more time for all the SRE Team members to reach a final agreement in one case. If something went wrong in the communication phase, the situation will easily become a disaster. Furthermore, to organize and manage such a large team increases the expense of the whole risk management process.


This article introduction and a comparison of Boehm’s software risk management method and SEI’s risk management method. Boehm’s software risk management method gives basic techniques and tools for risk management, as well as a large amount of ideas for further investigations. SEI’s software risk management method provides a continuous process for management with the support of SRE Team and successful communication. Although both of them are of high reputation, there are drawbacks need to be improved. As far as we concerned, further researches should focus on the accuracy of data collection and the efficiency of data analysis, as well as the methods to save expense and human labor.


[1] C. J. Alberts and A. J. Dorofee, “Risk management framework,” tech. rep., DTIC Document, 2010.

[2] Y. B. et al, “Software risk management: A practical guide,” 2000.

[3] M. Keil, P. E. Cule, K. Lyytinen, and R. C. Schmidt, “A framework for identifying

software project risks,” Communications of the ACM, vol. 41, no. 11,

pp. 76–83, 1998.

[4] K. Lyytinen, L. Mathiassen, and J. Ropponen, “Attention shaping and

software risk–a categorical analysis of four classical risk management approaches,”

Information Systems Research, vol. 9, no. 3, pp. 233–255, 1998.

[5] R. C. Williams, G. J. Pandelios, and S. G. Behrens, “Sre method description

(version 2.0) & sre team members notebook (version 2.0),” 1999.

[6] B. W. Boehm, “Software risk management: principles and practices,” Software,

IEEE, vol. 8, no. 1, pp. 32–41, 1991.