Complete thesis - Murdoch University

architecting, and testing beyond unit testing, and even that istypically quite weak.They are rarely given training in requirements engineering because most of the requirementsthey see are unanalyzed but merely poorly specified requirements written in theirnative languages.And since software engineers are obviously literate (even if feware good technical writers), managers and many software enginersfeel that they are therefore automatically qualified to‘‘write’’ requirements. To them,requirements elicitation, requirements analysis, and requirements management are notcritically important or can be done informally and intuitively.Professional requirements engineers and academics who specializein requirements engineering know better, but are vastly outnumbered bythe rank and file who think they understand requirements engineering because they canread textual requirements and have only been associated with RE that has been performedinformally(by this I do not mean not using a formal requirementsspecification language such as Object-Z, state charts, ordecision trees, but rather in the common non-technical meaningof being performed in a casual, non-technical way withoutprocess, method, or techniques).So if you want to discover a major reason why bad requirementsare such a major cause of project failure, you need look nofurther than the common observation thatthe vast majority of requirements are not engineered and not developed by anyone whohas learned any significant amount of RE, and the reason for that is that most peopleon the project do not see any need for RE because writing requirements to them is justfinding out what the application should do and writing it down.41