Running head: SOFTWARE DEVELOPMENT PROJECTS SOFTWARE DEVELOPMENT PROJECTS: A CASE STUDY OF FAILURE AND SUCCESS Direct Research Project in Partial Fulfillment of the Requirements for the Degree of Master of Science Information Systems – Software Engineering Management Submitted By Carol A. Harstad, BS (IS-Pr) 1240 Apopka Lane, Kissimmee, Florida 34759 (863) 427-0890 [email protected]
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Running head: SOFTWARE DEVELOPMENT PROJECTS
SOFTWARE DEVELOPMENT PROJECTS:
A CASE STUDY OF FAILURE AND SUCCESS
Direct Research Project in Partial Fulfillment
of the Requirements for the Degree of Master of Science
Information Systems – Software Engineering Management
To err is human, but to really foul things up you need a computer ~ Paul Ehrlich
When proper software engineering techniques and processes are neglected or ignored,
software development projects can suffer. They can cost more than estimated, take longer than
anticipated, be low in quality, and maintenance can be difficult. At worst, the project could be
completely abandoned. By using the proper processes and procedures, an organization has a
better chance of completing a high quality, maintainable software project on time, and less
expensive than one that is disorganized and in disarray.
The purpose of this study was to determine processes we can implement to ensure the
successful delivery of a development project. The main question that was answered by this
research project was; what can we do within the development process to ensure a successful
delivery of software projects and to avoid possible failure? To answer that question, the
knowledge areas of software engineering were laid out, examples of failures were discussed,
methods were outlined, and tools were identified. The results were obtained from websites,
textbooks, newspaper articles, websites, and industry publications.
Software Development Projects
TABLE OF CONTENTS
ACCEPTANCE PAGE.....................................................................................................................iABSTRACT....................................................................................................................................iiLIST OF FIGURES........................................................................................................................viCHAPTER 1 - INTRODUCTION...................................................................................................1
Context of the Problem................................................................................................................1Statement of the Problem.............................................................................................................2
FBI Virtual Case File...............................................................................................................2The Ariane 5 rocket (Flight 501).............................................................................................5The Federal Aviation Administration Advanced Automation System....................................5Other Software Development Failures....................................................................................5
Research Question and Subquestions..........................................................................................7Significance of the Study.............................................................................................................7Research Design and Methodology.............................................................................................8Objectives of the Study................................................................................................................8
CHAPTER 2 – LITERATURE REVIEW.......................................................................................9Software Project Challenges and Failure.....................................................................................9Reasons of Software Project Challenge or Failure....................................................................10Software Project Success...........................................................................................................10Conclusion.................................................................................................................................11
CHAPTER 3 – KNOWLEDGE AREAS OF SOFTWARE ENGINEERING..............................12Software Requirements..............................................................................................................12
Fundamentals.........................................................................................................................12Process...................................................................................................................................13Elicitation...............................................................................................................................14Analysis.................................................................................................................................14Specification..........................................................................................................................15Validation and verification....................................................................................................15
Software Processes and Product Quality...................................................................................22Analysis and Findings................................................................................................................23
CHAPTER 4 – CAUSES OF CHALLENGED AND FAILED PROJECTS................................24Introduction to Challenged and Failed Projects.........................................................................24Causes of Challenged and Failed Projects.................................................................................24
Bad project planning..............................................................................................................24Vague objectives....................................................................................................................26Inadequate project requirements............................................................................................26Lack of risk management.......................................................................................................27Lack of scope management...................................................................................................27Inadequate project management methodology......................................................................28Inadequate development management methodology.............................................................28Inadequate quality management............................................................................................29Poor performance by suppliers of hardware/software...........................................................29Lack of resources...................................................................................................................29Lack of user involvement......................................................................................................30Lack of executive support......................................................................................................30Unrealistic expectations.........................................................................................................31Incorrect cost estimation........................................................................................................32Project restarts.......................................................................................................................32Technology incompetence.....................................................................................................33Insufficient senior staff on the team......................................................................................34Poor social skills....................................................................................................................34
Remedy Attempts of Challenged Projects.................................................................................34Analysis and Findings................................................................................................................35
CHAPTER 5 – PRACTICES FOR PROJECT SUCCESS............................................................37Introduction to Best Practices....................................................................................................37Best Practices.............................................................................................................................37
CHAPTER 6 – TOOLS & MODELS............................................................................................55Introduction to Tools and Models..............................................................................................55Project management software....................................................................................................55CASE tools................................................................................................................................56Diagrams and other graphical representations...........................................................................57Testing Tools.............................................................................................................................59
CHAPTER 7 – SUMMARY AND CONCLUSION.....................................................................60Summary....................................................................................................................................60Conclusion.................................................................................................................................61
REFERENCES..............................................................................................................................63APPENDIX A. REQUIREMENTS DOCUMENT.......................................................................68APPENDIX B. CHANGE REQUEST LOG.................................................................................71APPENDIX C. POSSIBLE THREATS FOR RISK MANAGEMENT........................................72
Software Development Projects
LIST OF FIGURES
Figure 1. September 11, 2001. (Photo obtained from http://delong.typepad.com/images/911.gif) 4Figure 2. Standish CHAOS Summary (by percent) (Galorath, 2008).............................................9Figure 3. Microsoft Project Sample View.....................................................................................40Figure 4. Sample Gantt Chart (Stellman & Greene, 2009)............................................................40Figure 5. Systems Development Life Cycle (SDLC) (U.S. Department of Justice, 2003)...........46Figure 6. Success Potential Chart (The Standish Group, 1994)....................................................47Figure 7. PERT Chart (Image released to public domain by: Jeremy Kemp, 2005).....................55Figure 8. Sample Gantt Chart (Stellman & Greene, 2009)............................................................56Figure 9. Class Diagram................................................................................................................57Figure 10. Data Modeling Process.................................................................................................58Figure 11. Entity Relationship Diagram........................................................................................58
Software Development Projects
SOFTWARE ENGINEERING METHODS
CHAPTER 1 - INTRODUCTION
Context of the Problem
What issues can a company face if they perform a software development project
inappropriately? If not done properly, developing a new software package can be lengthy, taking
longer than expected to reach completion. Additionally, it can result in low quality, more
expensive, and harder to maintain software. Improper design and planning could possibly lead to
disastrous results. This paper shows that by applying the proper methods and procedures to the
development process, and using the proper tools, an organization can avoid these issues and
develop a high quality, less expensive, easier to maintain software in a timely manner (Software
Engineering, 2009).
The Institute of Electrical and Electronics Engineers (IEEE) defines software engineering
as “the application of a systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software (The Joint Task Force on Computing Curricula, 2004).”
A software engineer “focuses on the computer as a problem-solving tool (Pfleeger & Atlee,
1998).” In essence, developing a software application is similar in nature to building a puzzle. If
some of the pieces are missing, you will end up with a puzzle that is incomplete and virtually
useless. However, depending on which pieces are missing, the puzzle could provide some
usefulness, and give part of the picture, but you may still be enticed to throw it away.
This paper presents acceptable software engineering methods, tools, and procedures. It also
presents the issues an organization could face if they are not used. Areas of concern included in
the study are as follows: modeling, planning and managing, securing the requirements, design,
programming, testing, delivering, maintaining, evaluating, and improvement.
Software Development Projects
Statement of the Problem
Proper software engineering methods are required for a high quality software solution. Not
using the proper methods could result in software that is low in quality, expensive, hard to
maintain, and take longer to build (Software Engineering, 2009). Most universities teach the
proper methods to their students, however many organizations do not allow their consistent use
due to time constraints and other reasons, and they pay the price for such practice.
Sometimes, an organization will see the deadline, and decide that the proper planning and
designing will take too much time they could be using for coding. Additionally, there are
programmers who feel that proper planning is unnecessary and just busy work. This is often seen
in Extreme Programming, where the programmers sometimes try to skip most processes and
jump immediately into programming. In essence, they are skipping the essential pieces that
would inevitably prevent them from back stepping and reworking.
If the organization does not perform proper planning and design, they may miss essential
pieces to the solution that could prevent disaster. If they miss enough of the solution, they may
have to scrap the entire project and start over. The worst possible outcome could be catastrophic
(Glass, 1997). Webster’s dictionary defines catastrophic as “utter failure.” While there are many
projects that have ended in failure, the following cases show just how catastrophic a failure can
be.
FBI Virtual Case File.
The Federal Bureau of Investigation needed to bring its software into the 21st century. They
needed “a networked system for tracking criminal cases that was designed to replace the
bureaus’ antiquated paper files (Eggen & Witte, 2006).”
Software Development Projects
After several years of development, and $170 million, The Federal Bureau of
Investigation’s Virtual Case File system was considered incomplete and unusable. It was deemed
a failure and ultimately sent to the grand ole project graveyard. Attributed to its failure was “poor
conception and muddled execution of the steps needed to make the system work (Eggen & Witte,
2006).” Another issue attributed to the demise of the Virtual Case File project was the open-
ended contract with SAIC, with few safeguards. SAIC knew there were issues with the project,
but failed to notify the client that the project would not work. They kept collecting payments and
forging ahead with the project.
After the terrorist attacks in September of 2001, the system became top priority. The FBI
moved up deadlines, expanded requirements, and ultimately the costs ballooned (Eggen & Witte,
2006). SAIC should have been experts in the field of software engineering, yet failed in their
responsibilities to ensure that the project was successful.
The Office of the Inspector General attributed the following reasons to the delay and costs
of the Virtual Case File system (Office of the Inspector General, 2007):
poorly defined and evolving design requirements
contracting weaknesses
IT investment management weaknesses
lack of an Enterprise Architecture
lack of management continuity and oversight
unrealistic scheduling of tasks
lack of adequate project integration, and
inadequate resolution of issues raised in reports
Software Development Projects
Now that the system was scrapped after several years and $170 million, a new system
needed to be completed. The new system, called Sentinel, was estimated to run $425 million.
Add that to the amount previously spent on the Virtual Case File system, and ultimately, you
have a system that cost the FBI nearly $600 million, not to mention delivery of a system that was
needed many, many years earlier. If the system had been in place at the time, it is thought that
the United States could have prevented the activities of September 11, 2001.
Figure 1. September 11, 2001. (Photo obtained from http://delong.typepad.com/images/911.gif)
Software Development Projects
The Ariane 5 rocket (Flight 501)
“Ariane 5 ECA is [a] version of the Ariane 5 launcher. It is designed to place payloads
weighing up to 9.6 [tons] into geostationary transfer orbit [(or low Earth orbit)] (European Space
Agency, 2006).” “On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in failure.
Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the
launcher veered off its flight path, broke up and exploded (LIONS, 1996).”
This disaster was due to an incorrect variable conversion in the software running the rocket.
Considered one of the most expensive bugs in history, the Ariane 5 prototype cost US$1 billion
to build.
The Federal Aviation Administration Advanced Automation System
Another huge failure in the history of software development was the Federal Aviation
Administration (FAA) Advanced Automation System (AAS). This project was in development
for thirteen years before it was realized to be a “train wreck.” It was a $2.6 billion disaster, of
which $1.5 billion was considered unsalvageable for future development. “At its peak, the AAS
program was costing the government $1 million a day, 2,000 IBM employees, and producing a
hundred pages of documentation per line of code.” It was considered “the greatest debacle in the
history of organized work (Rosenberg, 2008).”
Other Software Development Failures
In addition to the above-mentioned disasters, many more can be used to show how
disastrous a project can be. For example:
Software Development Projects
The California Department of Motor Vehicle system cost $45 million and was
ultimately cancelled (McManus, 1994).
The American Airlines CONFIRM Reservation System was cancelled after three
and a half years, $125 million, and the use of 500 technical personnel (Confirm
Project, 2009).
Sydney Water Corp aborted a project midway through, after spending US$32
million due to inadequate planning and specifications, which led to numerous
When the testing process is being performed on the application, there are tools that can be
used to aid in the process. Static and dynamic code analysis tools are tools available to report
information pertaining to the written code. When the programming is executing, dynamic
analysis is done, and static analysis is done when it is not executing. Examples of tools available
for static analysis include code analyzers, structure testers, data analyzers, and sequence
checkers. An example of a dynamic tool is a program monitor that reports the applications
behavior (Pfleeger & Atlee, 1998).
In addition to the tools available for testing the actual written code, tools are available for
the planning and running of the tests such as capture and replay (or capture and playback) tools,
stubs and drivers, automated testing environments, and structured test case generators (Pfleeger
& Atlee, 1998).
Software Development Projects
CHAPTER 7 – SUMMARY AND CONCLUSION
Summary
Surveys show that software development failures occur too often. Based on findings of the
surveys, we can see the issues that can ultimately cause such failures. Most of these causes can
be directly attributed to certain knowledge areas of software engineering. If we make ourselves
experts in those knowledge areas, we can better manage, plan, design, develop, test and maintain
our projects. We can also see, from the evidence given, that by not using methods and processes
for one knowledge area carries defects or issues into other knowledge areas.
Once initiation of the project begins, a plan is created for the project. The requirements are
then completed, which leads into the design. Upon completion of the design, the development
begins. After the application has been developed, it is then tested, implemented and maintained.
At each stage of this process, the plan is consistently updated and maintained in order to keep the
development effort on track. If planning is not done, or done inadequately, the whole project
could be inaccurately estimated in terms of time, cost, and resource allocation and the team will
be unable to detect late or missed milestones.
Other issues that can be attributed to challenged and failed projects include: vague
objectives, inadequate requirements, lack of risk and scope management, inadequate project or
development management, inadequate quality management, poor performance by suppliers, lack
of resources or user involvement, lack of executive support, unrealistic expectations, incorrect
cost estimation, technology incompetence, insufficient staff, and poor social skills.
On the other hand, if the opposite of the above is present in the development process, there
is a better chance at success. Better planning leads to better time and cost estimation. Better
requirement specifications lead to more complete and correct design and development. Better
Software Development Projects
development leads to a better overall project. If the client is happy with the delivered product,
they will return for future efforts.
Conclusion
“Mistakes are a part of being human. Appreciate your mistakes for what
they are: precious life lessons that can only be learned the hard way.
Unless it's a fatal mistake, which, at least, others can learn from.”
~ Al Franken
Regardless of which studies you look at, the percentage of software development failures
and challenges are too high. The purpose of this research project was to determine the activities
we can do to ensure a successful delivery of software development projects and avoid failure.
To be successful, we must know the knowledge areas of software engineering. We must
know the causes of past failures to avoid future failures. We must be familiar with the proper
processes, methods, and tools of the various knowledge areas. We can learn from the mistakes
we have made, or the mistakes of others.
Too many organizations bypass important processes and procedures because they think
they will save time. In the end, they do not save time. They do however, go over budget, over
time, and end up with a low quality product, if the project even makes it to completion. They can
end up reworking parts of the application because they did not take the time up front to ensure
the requirements are as complete and correct as possible. They may not have taken the time to
design the system properly. Any time a developer needs to go back and rewrite code, it must be
retested and documented, and needs to go back through quality control. Additionally, if the
Software Development Projects
developer does not properly document the code as he is writing it, it will be nearly impossible to
maintain in the future.
If we are to raise the success rate of software projects, we must be sure that all curriculums
teach the necessary fundamentals of the knowledge areas. Additionally, organizations must be
more proactive and ensure their teams are knowledgeable in software engineering and proven
methods. If they are not adequately knowledgeable, it is worth the expense to ensure they are
properly taught.
The time added to a project by following all proper processes may be irritating or
cumbersome to some, but is a necessity in order to complete a successful software development
project.
Software Development Projects
REFERENCES
Alleman, G. B. (2009, April 29). Standish Report and Naive Statistics. Retrieved July 25, 2009, from Herding Cats: http://herdingcats.typepad.com/my_weblog/2009/04/standish-report-and-poor-statistics.html
Baltzan, P., & Phillips, A. (2009). Business Driven Information Systems (2nd ed.). The McGraw-Hill Companies, Inc.
Brenner, R. (2001, April 25). Restarting Projects. Point Lookout , 1 (17) . Chaco Canyon Consulting.
Brown, N. V. (2008). 11 "Laws of IT Physics". Off-Line and Off-Budget: The Dismal State of Federal Information Technology Planning (pp. 8-9). http://hsgac.senate.gov/public/_files/BrownTestimony.pdf.
Burd, S. D. (2006). Systems Architecture. Boston, Massachusetts: Thomson.
Carnegie Mellon. (2009). Software Engineering Institute. Retrieved July 11, 2009, from Software Engineering Institute: http://www.sei.cmu.edu/
CBC News. (2004, February 13). Gun registry cost soars to $2 billion. Retrieved July 30, 2009, from CBC News Canada: http://www.cbc.ca/canada/story/2004/02/13/gunregistry_rdi040213.html
Centers for Medicare and Medicaid Services. (2008, March 27). Selecting a Development Approach. Retrieved August 10, 2009, from U.S. Department of Health and Human Services: http://www.cms.hhs.gov/SystemLifecycleFramework/Downloads/SelectingDevelopmentApproach.pdf
Charette, R. (2009, August 26). "Coding" Error Creates Anxiety Among US Veterans. Retrieved August 26, 2009, from IEEE Spectrum: Risk Factor: http://spectrum.ieee.org/blog/computing/it/riskfactor/coding-error-creates-anxiety-among-us-veterans
Charette, R. (2005, September). Why Software Fails. Retrieved July 30, 2009, from IEEE: Spectrum: http://www.spectrum.ieee.org/computing/software/why-software-fails
Charvat, J. (2003). Project Management Methodologies. Hoboken, NJ: John Wiley & Sons, Inc.
Chellar, D. (2009, June 25). Who Are Your Stakeholders? Retrieved September 4, 2009, from The Project Management Hut: http://www.pmhut.com/who-are-your-stakeholders
Confirm Project. (2009, July 12). Retrieved July 12, 2009, from Wikipedia, The Free Encyclopedia: http://en.wikipedia.org/w/index.php?title=Confirm_Project&oldid=301706064
Software Development Projects
DeWeaver, M. F., & Gillespie, L. C. (1997). Real-world Project Management: New Approaches for Adapting to Change and Uncertainty. New York, NY: Quality Resources.
Eggen, D., & Witte, G. (2006, August 18). The FBI's Upgrade That Wasn't: $170 Million Bought an Unusable Computer System. The Washington Post , p. A01.
Erdil, K., Finn, E., Keating, K., Meattle, J., Park, S., & Yoon, D. (2003). Software Maintenance As Part of The Software Life Cycle. Tufts University. Department of Computer Science.
European Space Agency. (2006, March 12). First Ariane launch of 2006. Retrieved August 10, 2009, from ESA News: http://www.esa.int/esaCP/SEMAJ8MVGJE_index_0.html
Galorath, D. (2008, June 7). Software Project Failure Costs Billions. Retrieved July 25, 2009, from SEER: http://www.galorath.com/wp/software-project-failure-costs-billions-better-estimation-planning-can-help.php
Gerlich, R., & Denskat, U. (1994). A Cost Estimation Model for Maintenance and High Reuse. Proceedings, ESCOM 1994. Ivrea, Italy.
Glass, R. L. (1997). Software Runaways: Monumental Software Disasters. Prentice Hall.
Haughey, D. (2008). Project Planning: A Step by Step Guide. Retrieved August 10, 2009, from Project Smart: http://www.projectsmart.co.uk/project-planning-step-by-step.html
Higuera, R. P. (1996). Software Risk Management. Pittsburgh, PA: Carnegie Mellon University.
Hoffman, G. (2002, August 8). Why IT Projects Fail: Lack of User Involvement. Retrieved August 10, 2009, from Montana Associated Technology Roundtables: http://www.matr.net/article-4206.html
IEEE Computer Society. (2009, July 11). IEEE: The world's leading professional association. Retrieved July 11, 2009, from IEEE: The world's leading professional association: http://www.ieee.org/portal/site
IEEE-CS/ACM Joint Task Force. (1999, October). Engineering Code of Ethics. Computer Society Connection , 84-88.
Internet Center for Management and Business Administration, Inc. (2007). PERT. Retrieved August 15, 2009, from NetMBA: http://www.netmba.com/operations/project/pert/
Johnson, J., Boucher, K. D., Connors, K., & Robinson, J. (2001, February). Collaboration: Development & Management (Collaborating on Project Success). Retrieved July 20, 2009, from SoftwareMAG.com - The IT Software Journal: http://www.softwaremag.com/archive/2001feb/collaborativemgt.html
Leveson, N. G. (2004). Role of Software in Spacecraft Accidents. Journal of Spacecraft and Rockets 4 .
Software Development Projects
LIONS, P. J. (1996, July 19). ARIANE 5 - Flight 501 Failure - Report by the Inquiry Board. Retrieved July 25, 2009, from Massachusetts Institute of Technology (MIT): http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
Long, L. N. (2008, January). The Critical Need for Software Engineering Education. Retrieved July 11, 2009, from Software Technology Support Center: http://www.stsc.hill.af.mil/Crosstalk/2008/01/0801Long.html
Lowry, G. (2009, June 2). ASP.net Forums: Community. Retrieved July 11, 2009, from Microsoft ASP.net: http://forums.asp.net/p/1429826/3201693.aspx
Lynch, J. (2009, April 23). CHAOS Summary 2009. Retrieved July 20, 2009, from The Standish Group International: http://www1.standishgroup.com/newsroom/chaos_2009.php
Makar, A. (2009, July 22). Earned Value Management Tutorial. Retrieved August 10, 2009, from Tactical Project Management: http://www.tacticalprojectmanagement.com/earned-value-management-tips/who-is-afraid-of-eva.html
Management Sciences for Health and the United Nations Children's Fund. (n.d.). Stakeholder Analysis. Retrieved September 4, 2009, from The Guide to Managing for Quality: http://erc.msh.org/quality/ittools/itstkan.cfm
McConnell, S. (2001, September). The Nine Deadly Sins of Project Planning. Retrieved August 12, 2009, from Construx.com: http://www.construx.com/Page.aspx?hid=1190
McManus, J. (1994). Risk Management in Software Development Projects. Burlington, Massachusetts: Butterworth-Heinemann.
Office of the Inspector General. (2007, August). Sentinel Audit III: Status of the Federal Bureau of Investigation’s Case Management System. Retrieved July 25, 2009, from United States Department of Justice: http://www.usdoj.gov/oig/reports/FBI/a0740/intro.htm
Office of the Inspector General. (2005, February). The Federal Bureau of Investigation's Management of the Trilogy Information Technology Modernization Project. Retrieved July 25, 2009, from United States Department of Justice: http://www.usdoj.gov/oig/reports/FBI/a0507/findings.htm
Parikh, G., & Zvegintzov, N. (1983). Tutorial on Software Maintenance. Silver Spring, MD: IEEE Computer Society Press.
Pfleeger, S. L., & Atlee, J. M. (1998). Software Engineering. Upper Saddle River, New Jersey: Pearson Education, Inc.
Project Shrink Publishing. (2007, August 25). Software Requirements Management. Retrieved August 10, 2009, from Software Projects: http://www.softwareprojects.org/software-requirement-management-01.htm
Software Development Projects
Qassim, A. A. (2008, June 10). Why Information Systems Projects Fail: Guidelines for Successful Projects. Retrieved July 25, 2009, from INTOSAI Working Group on IT Audit: http://www.intosaiitaudit.org/intoit_articles/26_p12top17.pdf
quality assurance. (2009). Retrieved August 20, 2009, from Merriam-Webster Online Dictionary: http://www.merriam-webster.com/dictionary/quality assurance
Requirement. (2009, August 19). Retrieved August 24, 2009, from Wikipedia, The Free Encyclopedia: http://en.wikipedia.org/w/index.php?title=Requirement&oldid=308942062
Rittinghouse, J. W. (2004). Managing Software Deliverables. Burlington, MA: Digital Press.
Rosenberg, S. (2008). Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software. New York: Three Rivers Press.
Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2007). Systems Analysis and Design in a Changing World (4th ed.). Boston, Massachusetts: Thomson.
Sauer, C., Gemino, A., & Reich, B. H. (2007, November). The impact of size and volatility on IT project performance. 50 (11), pp. 79-84.
Simon, P. (2009, June 5). Why New Systems Fail - Theory and Practice Collide. Retrieved July 25, 2009, from Phil Simon Systems - Optimizing Enterprise Systems: http://www.philsimonsystems.com/sitebuildercontent/sitebuilderfiles/chapter1.pdf
Software Engineering. (2009, July 6). Retrieved July 11, 2009, from Wikipedia, The Free Encyclopedia: http://en.wikipedia.org/w/index.php?title=Software_engineering&oldid=300600273
Stellman, A., & Greene, J. (2009, August 14). Software Project Planning Practices: Project Schedule. Retrieved August 15, 2009, from Applied Software Project Management: http://www.stellman-greene.com/aspm/content/view/18/38/
Stoneburner, G., Goguen, A., & Feringa, A. (2002). Risk Management Guide for Information Technology Systems. Gaithersburg, MD: National Institute of Standards and Technology.
SWEBOK. (2004). Guide to the Software Engineering Body of Knowledge. (A. Abran, J. W. Moore, P. Bourque, & R. Dupuis, Eds.) Los Alamitos, California: The Institute of Electrical and Electronics Engineers, Inc.
The Joint Task Force on Computing Curricula. (2004, August 23). Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering . IEEE Computer Society.
The Standish Group. (1994). The Chaos Report. Retrieved July 20, 2009, from The Standish Group International: http://www.standishgroup.com/sample_research/chaos_1994_1.php
Software Development Projects
U.S. Department of Justice. (2003). Information Resources Management. Washington, DC: Department of Justice.
U.S. House of Representatives. (2001). Proc. of the Aviation Subcommittee Meeting. Washington, DC.
Webster, G. (1999). Managing Projects At Work. Brookfield, VT: Gower Publishing Limited.
1. IntroductionThis document contains the system requirements for project name. These requirements have been derived from several sources, including brief listing of most important sources.
1.1 Purpose of This DocumentThis document is intended to guide development of project name. It will go through several stages during the course of the project:
1. Draft: The first version, or draft version, is compiled after requirements have been discovered, recorded, classified, and prioritized.
2. Proposed: The draft document is then proposed as a potential requirements specification for the project. The proposed document should be reviewed by several parties, who may comment on any requirements and any priorities, either to agree, to disagree, or to identify missing requirements. Readers include end-users, developers, project managers, and any other stakeholders. The document may be amended and re-proposed several times before moving to the next stage.
3. Validated: Once the various stakeholders have agreed to the requirements in the document, it is considered validated.
4. Approved: The validated document is accepted by representatives of each party of stakeholders as an appropriate statement of requirements for the project. The developers then use the requirements document as a guide to implementation and to check the progress of the project as it develops.
1.2 How to Use This DocumentWe expect that this document will be used by people with different skill sets. This section explains which parts of this document should be reviewed by various types of readers.
Types of ReaderIn this section, list the different types of reader this document is aimed at. For example, Flash programmers, graphic designers, end-users, project managers, etc. For each type of reader, clearly state which sections are most pertinent to them, and which may be safely skipped.
Technical Background RequiredDescribe here the technical background needed to understand the document in general, and any particular expertise or understanding that is needed for specific sections.
Overview SectionsList here the sections that should be read by someone who only wishes to gain an overall understanding of the project, or which should be read first before technical requirements are reviewed.
Reader-Specific SectionsIn this section, name any parts of the document which are intended only for one or another of the reader types identified above, and which may therefore be skipped by other readers.
Software Development Projects
Section Order DependenciesIf readers will need to read certain sections in a specific order, note those sections here. Also, point out any sections that may be read independently with no loss of understanding.
1.3 Scope of the ProductInclude a brief narrative here that describes the product as you intend it to be realized. Use this section to define boundaries and set expectations.
1.4 Business Case for the ProductWhy is this product required? How will it contribute to the goals of your institution? This section can be used when requirements are being negotiated, to assess whether a particular change is a good idea. This section also helps readers understand why certain requirements have been included. 1.5 Overview of the Requirements DocumentIf your project is small to medium in size, include a summary of the requirements here. This may be a numbered list of the most important requirements. The purpose of this section is to give the reader a general understanding of the requirements and focus attention on the most critical ones. This section may also help point readers to the specific requirements that are of particular interest to them.
2. General DescriptionThis section will give the reader an overview of the project, including why it was conceived, what it will do when complete, and the types of people we expect will use it. We also list constraints that were faced during development and assumptions we made about how we would proceed.
This section contains a nontechnical description of the project, usually in narrative form, which may serve to acquaint new readers with the purpose of the project. It also sets the stage for the specific requirement listing which follows.
2.1 Product PerspectiveWhy have you chosen to develop this product? What need does it serve? Who are the primary stakeholders, who is developing the project, and who will benefit from the finished product?
2.2 Product FunctionsWhat does your product do? What activities can users perform while using it? List the main functions that you will build into your product here.
2.3 User CharacteristicsWho do you expect to use your finished product, and why? What is their technical background, their training or education, their motivation to use it? What obstacles might they encounter, and what specialized skills will they need?
2.4 General ConstraintsDid you work under any constraints such as platform or development environment? Did you have to make your product compatible with any existing software or other products currently in use?
2.5 Assumptions and DependenciesIn this section, list any assumptions you made about your project (for example, did you assume that the finished product would need to be delivered over the internet?). If your project depends on any particular technical infrastructure, or requires administrators or others with specific skills, note that here.
3. Specific Requirements This section of the document lists specific requirements for name of project. Requirements are divided into the following sections:
Software Development Projects
1. User requirements. These are requirements written from the point of view of end users, usually expressed in narrative form.
2. Reporting requirements.3. System and Integration requirements. These are detailed specifications describing the functions
the system must be capable of doing.4. Security Requirements5. User Interface requirements. These are requirements about the user interface, which may be
expressed as a list, as a narrative, or as images of screen mock-ups.
3.3 System and Integration RequirementsList detailed system requirements here. If your system is large, you may wish to break this into several subsections. Include dependencies on existing systems.
3.4 Security Requirements
3.5 User Interface RequirementsList interface requirements here; or include screen mockups. If you use mockups, be sure to explain major features or functions with narrative to avoid confusion or omission of desired features.
5. Customer SupportHow will it be supported internally?
6. AppendicesIf you wish to append any documents, do so here. You may wish to include some or all of the following:
Personas and scenarios developed for this project Transcripts of user interviews, observations, or focus groups Copies of communications which contain user requirements Original project proposals or other historical documents Lists of similar projects or products, with notes about how they differ from yours A list of requirements which were "wish-listed" or marked unfeasible at present Original screen mockups, if they are relevant
7. GlossaryInclude a glossary of definitions, acronyms, and abbreviations that might be unfamiliar to some readers, especially technical terms that may not be understood by end-users or domain-specific terms that might not be familiar to developers.
8. ReferencesList references and source documents, if any, in this section.
9. IndexIf your document is very large, consider compiling an index to help readers find specific items.
Economic exploitationInformation theftIntrusion on personal privacySocial engineeringSystem penetrationUnauthorized system access(access to classified, proprietary, and/or technology-related information)
Insiders (poorly trained, disgruntled, malicious, negligent, dishonest, or terminated employees)
CuriosityEgoIntelligenceMonetary gainRevengeUnintentional errors and omissions (e.g. data entry error, programming error)
Assault on an employeeBlackmailBrowsing of proprietary informationComputer abuseFraud and theftInformation briberyInput of falsified, corrupted dataInterceptionMalicious code (e.g., virus, logic bomb, Trojan horse)Sale of personal informationSystem bugsSystem intrusionSystem sabotageUnauthorized system access