Importance of Requirements engineering using case studies of two failed projects

1. Requirements
Engineering:
Case study of failed projects
Aisha Alimi

2. “
Requirements engineering is a highly
important phase of the Software
Development Life Cycle.
WHY?
2

3. Importance of RE
▪ Increasing customer satisfaction - Result of communication with
stakeholders and no expectation gap.
▪ Improving software quality – Requirements have been thinned and
verified
▪ Better estimation of resources needed
▪ Improving traceability
▪ Tracking progress and auditing the software development process
▪ Saving time and budget resources, due to less rework and fewer
unnecessary features
▪ Aiding testing, as defects due to poor requirements are nearly
eliminated
▪ Improving project’s accommodation for changing requirements 3

4. 1.
US Census Bureau –
Field Data Collection
Automation (FDCA)

5. Synopsis
▪ Conducting the census is a $10B project that takes a full
ten years to plan, execute and complete.
▪ There were concerns about escalating costs and questions
about the accuracy of the data being collected.
▪ The US Census Bureau decided to eliminate the paper-
based system used by field workers and replace it with
modern handheld computing devices.
5

6. Problems
▪ While the business processes being implemented were
relatively simple, introducing technology turned out to be
more complex than the Bureau had envisaged.
▪ Having first attempted to do the project in-house, the
Bureau changed direction and outsourced the project.
▪ Lack of due diligence on behalf of the Bureau and failure to
establish effective communications with the supplier
resulted in a significant number of missing requirements.
▪ Ultimately, time ran out and the Bureau had to revert back
to using pen and paper.
6

7. The RE problem
▪ External auditors identifies the following issues;
□ Underestimation of complexity
□ Lack of communication between Census Bureau and
its prime contractor
□ Failure to establish and stabilize requirements
resulting in significant requirements volatility (at one
point 400 plus change orders had been raised)
□ Lack of risk management.
7

8. The RE problem
▪ Failure to establish firm requirements
□ There was no emphasis on proper requirements elicitation.
“It’s a simple process”
▪ No change control process.
□ New requirements were continually added without being
validated
▪ System wasn’t tested against criteria set in performance
requirements.
□ Auditors noted that specific measurable performance
requirements were not defined
8

9. 2.
Apple –
Copland Operating
System

10. Synopsis
▪ When Microsoft Windows 95 came out, it arrived with
multitasking and dynamic memory allocation, neither of
which was available in the existing Mac System 7
▪ Apple intended to release the Copland OS to be released
as System 8, a successor to System 7 in 1996.
▪ It was to introduce features such as protected memory,
preemptive multitasking and multi-user functionalities
while retaining compatibility with existing Mac
applications.
10

11. Problems
▪ As the new OS came to dominate resource allocation
within Apple, project managers began pushing for their
products to be incorporated into System 8.
▪ A developers' release came out in late 1996, but it was
very unstable, unusable for development and wasn’t very
distinguishable from the previous OS.
▪ Before another developers’ release could come out, Apple
made the decision to cancel Copland.
11

12. The RE problem
▪ Some of the challenges that the Copland project faced are;
□ Dysfunctional personnel management
□ Project creep - New requirements were added more
rapidly than they could be completed.
□ Technical struggles.
12

13. The RE problem
▪ Poor requirements management.
□ Even though proper initial requirement analysis had been
done, increasing additional requirements were not
supervised suitably
□ Due to internal corporate empire-building, even features
that were meant for Copland’s successor were added.
□ Certain requirements weren’t checked against realism. The
technology simply wasn’t there yet.
13

14. Conclusion - Lessons learnt
▪ Time-to-market pressures shouldn’t override proper
requirements engineering.
▪ You don’t have to do everything at once, requirements
should be ranked and prioritized
▪ Poor requirements affects other phases of the
development cycle.
▪ It is important to invest resources into defining, analyzing,
validating and maintaining requirements to avoid project
failure.
14

15. 15
Thanks!
Any questions?