Case study example

Case Study Why are ambiguous business requirements the leading cause of system development failures? Explicit Businessrequirements hold a primary role in developing an efficient system. The prime reason identified for a project to fail is the bad business requirements that are ambiguous. Vague business requirements frequently occur due to the non-involvement of end-users in system development during its analysis and design phase. When different people interpret differently, the system loses its real essence and lead to dissatisfied customers/ clients
2. Why do the words “ and & or” tend to lead to ambiguous requirements?
The vague use of certain words can also lead to ambiguous business requirements causing failures. The words “ and & or” despite having well defined meaning, are frequently considered ambiguous and informal by most of the people. For example if the business requirement is stated as “ the light must turn on if button B is pressed and if button F is pressed.” This statement can be interpreted differently by different people because of the ambiguous use of the word “ and” and this may lead to distortion in the respective system.
3. Research the Web and determine other reasons for “ bad” business requirements.
A large number of business requirements fail in two prime dimensions; lack of true process orientation and lack of neuroscience required in defining the business requirement effectively. The perception of the business requirement makers that they know everything also leads to bad business requirements. Further, poor communication, constantly changing requirements in projects, less customer involvement, time and money constraints are some of the identifiable reasons resulting in bad business requirements.
4. What is wrong with the following business requirement: “ The system must support employee birthdays because every employee always has a birthday every year.”
The use of “ always” in a system means “ most of the time” however; sometimes, it can also create ambiguity. The above mentioned statement can be interpreted in the following ways; the system should support employee birthdays every year because birthdays come and are celebrated every year. What if an employee gets dead then still the system will always support his/her birthday despite employee’s demise? Further, if an employee gets retired or not celebrates his/her birthday every year, so should the system support his/her birthday? All these varying interpretations can be perceived from the above mentioned ambiguous business requirement leading to system failure.
Work Cited
Sims, J. Why Projects Fail: Part Two, Poor Business Requirements. Web. 27th Feb, 2014.