Note 1: Examples of software engineering project proposals are available here.
Students in my software engineering class developed those projects, and their reports and software code are also available here.
Note 2: This document describes how to develop a proposed software project in a structured manner.
Although primarily intended for an academic course in software engineering, it has wider applicability.
This document was originally intended for a Software Engineering course (Rutgers ECE 14:332:452). If you are a student in this course, you have two options:
When thinking about your own idea for a project, please keep in mind that the
project must be equivalent in required effort to the
example software projects.
Writing a solid software proposal requires a major effort (weeks or months of work) and you may not be able to produce it on time to start working on your project. You risk falling behind the rest of the class.
Therefore, only highly motivated and knowledgeable teams should consider proposing their own projects.
Working on a modified version of an existing project is not such a bad idea. After all, everything’s been done before, so we’re always building on existing ideas and products, regardless of whether they were developed in this course or somewhere else.
Although your own proposal may be novel, you should not expect different treatment from other teams in the class who are working on the projects that were defined for them (here). Working on your own project is your choice and you should be ready to invest any additional effort required to excel in the class.
Software engineering proposal is a document that a software developer submits to a business customer for acceptance. The proposal describes the problem to be solved and explains the resulting benefits to the customer.
The key for a great proposal is to invent a great idea.
There is no “official template” for writing software proposals.
To sum up: Content is the key. Form is irrelevant.
Keep in mind that this is a proposal only, so you do not know that it will be accepted as such. Therefore, you do not want to waste time on formalities by following some formal descriptions/formats/templates.
The key is to diagnose the problem and propose a treatment, so to convince the customer to accept your proposal.
The customer wants to know first that you know what you are proposing to do.
They are not interested in idiosyncrasies of software engineering or programming. They assume you know that.
Only if you receive the customer’s approval, will come the issue of knowing how to do it.
The most important thing about a software engineering proposal is that the proposal is about the problem domain, not about programming. The proposal should clearly describe the motivation for the proposed work and the proposed solution along with its expected business value. The proposal should not contain any technical jargon. There are three key components of a software engineering proposal:
To write a software engineering proposal, follow these steps:
Your proposal must be written in lay language, plain English, and you should avoid any engineering terminology (unless your problem domain is an engineering process, i.e., you will develop software to improve an engineering process).
The proposal should accurately describe the user experience, though in lay language rather than using software engineering jargon. The proposal is about the user experience of the proposed system, so this must be as accurate as possible. Otherwise, the decision to accept or reject the proposal will be based on inadequate information. On the other hand, the proposal should avoid discussing the implementation details of the system (how it will be done). It is useful, though, to include what is necessary to accomplish the proposed goal, such as access to certain data (e.g., financial reports, traffic reports, etc., depending on the problem domain), other resources (e.g., sensors, devices, equipment), or expertise (e.g., statistician, security expert). It helps to know whether such resources are available and at what cost.
Check here for more details about writing engineering documents.
See additional links of interest at the bottom of that webpage.
This document describes how to develop a proposed software project in a structured manner. Although primarily intended for an academic course in software engineering, it has wider applicability.
It is not that writing itself is difficult. What is difficult is learning about your problem domain, how things are done now, how your proposed system will change that. Even if you’re familiar with the domain, it takes time to think new solutions. For example, you may be using a parking garage every day, or even working as a garage operator, but it takes a great deal of time to figure out how to propose a smart parking system.
One may argue that it is to be expected at an initial stage that your proposal will be sketchy on details. Writing a detailed project proposal requires time. I agree. I spent a lot of time preparing these project descriptions.
That is why you should avoid wasting time on formalities and focus on what matters. Which is, diagnosing the problem and proposing a treatment. But you cannot diagnose a problem unless you have a deep understanding of your problem domain. You cannot tell your customer how you will improve their work unless you know very well how they are doing their work now!
This is where the problem arises. You may be excited about writing new programs, but you are not excited about learning biology or finance or restaurant functioning. But you cannot diagnose a problem and propose a treatment unless you know your problem domain. You must know how your customer does their business now and how your proposed system will affect your customer’s work. It is important that you are excited about developing something you feel is valuable and important.
A key quality of a great software engineer is that he or she is willing (scratch that, excited) to learn new problem domains.
A great software engineer will learn medicine if he or she is to develop a medical software system; he or she will learn sociology if he or she is to develop a social networking system (popup quiz: what’s Dunbar's number and why Path limits your social network to 150 friends?); the engineer will go observe how restaurant personnel do their work if he or she is to develop a software system to help run a restaurant; etc.
When deciding about the project, the most important thing to keep in mind is that the software product you will develop should require lot of programming. This is a design rather than a programming course. However, in order to learn good design, the process must include actual implementation of the design. Therefore, the project must include programming.
For example, creating a data-bank and processing this data is a programming task. If your system just allows the user to set or modify values of different database records, that is not data processing. Examples of programming (data processing) include, data-bank re-organization, keyword-based search and retrieval, filtering and summarization of the data-bank, selecting a small group of users for notification, etc. However, just saying: The system will provide search facilities, may mean that you are using SQL database calls and doing no programming at all. And, programming is done in a programming language, such as C, C++, Java, or C#.
Note: Designing web pages passive web pages which
contain only HTML is not programming. Therefore,
your project can include web page design, but that is not
On the other hand, designing active webpages using AJAX, Flash, etc., is programming and is perfectly acceptable for the class project.
Focus more on automatic data processing: not what user can manually do, but what system does automatically to save the user’s effort. For example, suppose you are designing a system for online purchasing of airline tickets. You could incorporate the following data processing features:
Keep in mind that the key purpose of this course is that you learn how to do modular design of software and how to document the design using symbolic representations, i.e., UML diagrams. Thus, you should avoid flashy user interfaces and proprietary software. These will definitely not contribute positively to your grade, and may have negative effects. Limit your software to the tools commonly and freely available on the Web.
The proposed topic can be almost anything; however, it is advisable to come up with something novel and innovative to keep you interested in its realization, and because innovativeness tends to make impression on the reviewers.
You could get an idea for interesting service(s) by exploring these web-sites:
The process of casting out the right-size project for a given period of performance can be very frustrating. You cannot ever know what you’ll encounter while working on it. I believe that it’s better to start more ambitious and later scale down, if necessary. Start with an initial idea of desirable services and discuss as much details as possible with your partners to figure out whether or not you as a team can develop it in the given time frame. Of course, you’ll have chance to adjust your goals during the semester, as you learn more details about your target product.
If you like one of the project ideas described here, your main task for the proposal is to describe how different will be your project from the projects that were done by past students in this course.
You may borrow ideas and implementation from past projects
as much as you like. It is fine that you borrow 100% from a past project, take everything and then build on top of it!
In fact, this approach would be preferred instead of seeing you reinvent the wheel.
However, what is important is that you contribute new value! For example, you can implement better some features/functions from an existing project; your implementation may be faster, or easier to use. Or, you may add novel features / extensions to an existing project.
Because the project is a team work, each team submits a
single document for the entire team. Email a PDF document
of your proposal to both the instructor and the TA
on or before the due date given here.
Submission deadline: 5:00 p.m. on the due date.
Here is a PDF writer you can use from Windows. Macs automatically convert postscript to PDF by clicking on the file icon. There are UNIX utilities that convert postscript to PDF for Linux users; make sure you include all fonts in the created PDF.
In case of novel project proposals (not based on the projects described in the class lecture notes), email immediately the breakdown of the individual contributions to the proposal.
We will provide written feedback only for novel project proposals via email in case we feel the proposal should be revised. No feedback will be provided for proposals based on the projects described in the class lecture notes. The only two reasons for revision could be:
The students are encouraged to be ambitious in the first
iteration of the project. You will have chance to revise your project
objectives at the end of the first iteration, by the time of Demo #1. At that time, you must be
realistic and you may have decide that you need to scale down
the project scope, so to be able to finish it by the end of the
♣ Angsuan Chackraborty: How to Write a Software Proposal
♣ Elizabeth Smith (Demand Media): How to Write a Proposal on Web Applications
♣ Sun Associates: 10 Tips for Technology Proposal Writers
♣ James Abela: EXAMINATIONS Writing a Proposal
♣ Georgia Perimeter College: Proposal Writing Stages and Strategies
♣ Sid Hutchinson: How to Write a Software Proposal (updated May 17, 2011)
♣ Andy Carr: How to Write a Software Development Proposal (updated May 11, 2011)