By Jesse Stay
Below is a research essay, written Sept., 2004 as part of my Undergrad in CIS. It is a must-read for any Project Manager or Software Engineer out there:
According to Standish group, 31 percent of software projects are cancelled before they are even finished. 53 percent of software projects in the same study cost more than 189 percent of the originally estimated costs. Due to “feature creep”, only 42 percent of the features originally planned in the original product end up in the final result. (Abbott) As evident by these results one can only wonder why such money is spent on software projects when they usually cost more than what is originally budgeted. The question is brought to mind, “What can be done to alleviate such harsh statistics?” That question is answered through good software requirements.
Many project managers are unaware of such statistics. Many pass by the developers telling them to start programming while they go get the requirements. Because of this, many projects fail, information is lost, productivity becomes lacking, and developers fail to develop in an efficient manner. When in fact, the more effective managers come back from the customer with the requirements, and tell the programmers to start programming while they figure out how much time it’s going to take. Between 40 and 60 percent of all software defects can be attributed to bad software requirements. (Abbott) However, this does not have to be the case.
Through good use-case modeling and specification techniques, one can develop a good requirements document that would prevent most, if not all of the feature-creep that is seen in the Software Development Lifecycle. As Ben Stein puts it, “The indispensable first step to getting the things you want out of life: decide what you want.” (Larmen, p. 1) Without knowing what the customer needs that customer will not get what they want out of the project on the first try.
So how do we figure out what the customer wants? There are generally 4 major requirements that if followed well will lead to a good requirements document. Those 4 requirements are a system feasibility study, the elicitation and analysis of requirements, the specification of requirements and their documentation, and the validation of those requirements. (Sommerville, p. 122) Each of these, if executed properly, will reduce flaws in the final project and save costs in the long-term for both the company and the customer.
A system feasibility study determines the worth of the project that the organization is trying to accomplish. In other words, through the proper outlining of a system and how it will be used one can figure out if the project is indeed worth accomplishing due to cost and effort. (Sommerville, p. 123) Without a proper system feasibility study, it is likely a system would veer away from the objectives of the organization or the customer, causing the need for the project to vanish, therefore bringing doom upon the project itself. If the system will end up using technology that is non-existent, and exceed cost and/or time-constraints, this can lead to feature creep and shortcuts down the road.
The next phase in the requirements engineering process model is requirements elicitation and analysis. This requirement often takes the longest time perhaps because it is most important. The key term associated with requirements elicitation and analysis is “stakeholders.” Once the project is deemed feasible, one then determines all “stakeholders” of the project – this would include the customer, engineers and developers working on the project, business managers, domain experts, trade union representatives, or anyone else in the organization that might have a stake in the project. (Summerville, p. 124)
It is this phase that makes it extremely important for not just the project manager and business people to understand the need for good requirements before a project is started. Most often the project management team and business people organizing projects know things from the end-user standpoint, not from the technical standpoint that will take the least time to develop and cause the least headache in the future. As developers and stakeholders of a project it is very much up to those with the technical expertise to have a say at this point. They have the experience. They have the expertise. Therefore developers should always take a strong interest in not just allowing management to lead requirements definition, but should take a strong part as well. Project Managers also need to recognize this fact. (Piquet)
Other important factors in requirements elicitation and analysis are domain understanding, requirements collection, classification, conflict resolution, prioritization, and requirements checking. (Sommerville, p. 125) Without domain understanding, one cannot fully understand the organization and how it is supposed to work. Without this understanding, the person managing the project cannot fully put out the requirements that will satisfy the customer. Misunderstandings will occur and miscommunication is bound to happen due to the inability of the person managing the project and it’s stakeholders to understand the terms and scope of whom the customer is.
Without proper requirements collection, as mentioned before, the stakeholders cannot fully give their input. It is hard to understand the user-interface and functionality requirements of the customer. The system will be developed inefficiently due to poor communication with the developers. Legal issues could arise. Tax ramifications could ensue. All of these could lead to the demise of the project or the loss of key features originally requested by the customer due to poor communication during the collection process.
Poor classification can lead to improper prioritization among developers and engineers. If requirements are sorted poorly engineers will develop their code and systems in the same manner as the requirements, if not worse. This also goes right along with conflict resolution and prioritization. Conflicts between software developers and user interface designers can lead to poor code design or a bad user interface. If a certain technology is needed and it’s cost is prohibitive from a business standpoint requirements may not get met. Improper prioritization of requirements can lead to the inability to finish a project on time due to improper focus by the stakeholders. If requirements are not then checked once the entire process is done with, certain key requirements could be left out and stakeholders’ input would not fully be taken into account. This could lead to need for modification and longer coding times down the road.
Often during this phase a use-case model is put into place. In such a model, all stakeholders are identified and then put into a diagram that shows how each of them have input and receive output from the project being developed. Elements of the project are broken out and interactions between the stakeholders and these elements are sequenced in an event-based diagram that shows when and how the stakeholders will interact with the system. Without such diagramming and modeling techniques, it becomes hard to see from a glance where flaws in the requirements definition occur. According to Craig Larmen:
- “Perhaps it seems obvious to stress providing observable user value, but the software industry is littered with failed projects that did not deliver what people really needed. The feature and function list approach to capturing requirements can contribute to that negative outcome because it does not encourage the stakeholders to consider the requirements in a larger context of using the system in a scenario to achieve some observable result of value, or some goal. In contrast, use cases place features and functions in a goal-oriented context.” (Larmen, p. 4)
Therefore, a use-case model is more than just a diagram to help the project manager himself, but an overall “story” to relate to each stakeholder during the requirements definition process. Without something that can relate to each stakeholder, the requirements list just becomes a list of garbled information that is hard to understand and use.
The third phase in the requirements engineering process model is requirements validation. During this phase, the project manager or requirements engineer work out a plan to ensure all requirements have been met. Requirements must be consistent, not conflict, be efficient, and meet all requirements of the stakeholders. One useful method of testing this is through prototyping.
A successful prototype gives a working example to the stakeholders, showing them an overall view of what the project will entail, how it will be presented to the end user, possible end-costs to a scale of such a system, and overall scope of the project. Like a use-case model, a prototype takes the final requirements taken from all stakeholders and puts them into a working model that they can actually play and work with. This brings the project down to their level to fix any errors in the requirements definitions and makes the project less error-prone.
Without such a mechanism to work with users a system can still be built, but the system cannot be seen until it is developed. This often leads to not all system requirements being met according to the user standpoint and leads to poor communication among stakeholders. If this communication and output can be simulated ahead of the end project much of this can be avoided, and the project is much more likely to succeed and succeed well.
Even with the first four phases being followed, business objectives are bound to change. Therefore, to avoid the downfall of the project and introduce minimal feature-creep as these changes occur, the last phase in the requirements engineering process model is critical. That phase is requirements management. During this time the project manager or requirements engineer must pay close attention to each of the stakeholders and know what new requirements may arise as they are further exposed to the project. If business objectives change they must properly be presented to the software engineers and developers so minimal change will need to happen in their development efforts. Often developers will become more exposed to a project and their own requirements may evolve as they understand it more. (Summerville, p. 140) It is important to recognize these and readapt and re-plan as these things happen so the project keeps moving in the right direction with the business objectives.
Without proper management during this phase the project will veer away from the requirements of the customer, or the costs can become prohibitive. Improper coding could also lead to longer completion times, extending the time of the project’s critical path.
Overall, it can be seen that bad requirements are often the root cause of failed and poorly planned projects. They affect every element of the software development lifecycle. With improper requirements definition, systems cannot be fully designed. Without a good design, implementation does not meet the customer’s expectations. Without good requirements and design, a good test plan cannot be put in place that ensures bugs and problems will not be introduced when in full-scale production in the future. And with all of this, operation and maintenance becomes a nightmare. It is crucial that a good requirements definition is planned well, and follows every element of the requirements engineering lifecycle efficiently, or the project will for sure become among one of the statistics of most organizations out there.
Bibliography
Sommerville, Ian (2001), Software Engineering, 6th Edition. Essex, England: Pearson Education Unlimited.
Larmen, Craig. USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT, from http://www.craiglarman.com/book_applying_2nd/06-use%20cases.pdf
Piquet, Lori (2003). Are you Passing the Requirements Buck? DevX.com, The Know-how behind Applications Development. Retrieved November 4, 2004, from 8http://www.devx.com/devx/editorial/11728
Abbot, Bruce (2001). Requirements set the mark. InfoWorld. Retrieved November 4, 2004, from http://www.infoworld.com/articles/tc/xml/01/03/05/010305tcreqs.html
