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—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 just helps to convey it.
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.
Although a naive user may not be interested in specific algorithms or software libraries that you may be planning to use, it is important that you mention their existence. The reason is again that your customer (or course instructor) needs to be assured that you know what you are up to. Otherwise, the cutomer may be worried that you don’t really know what you may need, and this may be an open-ended project that may take forever and very likely may fail. If you say that you will reuse an existing software or algorithm, this significantly reduces the uncertainty about the proposed work.
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.
When working in a team, it is important to create a blanaced division of labor. This will ensure that all team members are contributing to the success of the project. The best approach for balanced workload is to assign product ownership. Your “product” is what you deliver to your customer. User interface, graphic design, database interaction, unit testing, etc. are not products. Different parts of that product (i.e., functional features) should be owned by different team members.
Product ownership does not necessarily equal labor division. Your customer wants to know who is the person to go to when she wants to know about the progress or any issues related to a given functional feature. Who actualy did the work is your concern and should be reported in the individual contributions breakdown in your future deliverables. That canot be planned in advance. Ideally, the product owner should build the product he owns, but the actual owrk may be subcontracted if need be, because of individual expertise available in the team.
Novices often make mistake by subdividing the work along the lines of different computer disciplines or indiviual expertise. For example, one person says “I’ll do the database,” another person says “I’ll do the user interface,” etc. Do not subdivide the work by sub-systems of the proposed system. It’s too early for such subdivision while writing the proposal. You don’t know what subsystems will be there, what architecture you will adopt, and how much effort will be needed. Instead, subdivide your work by functional features.
Initially we split work to different functions, but later we may drop some use cases if important ones turn out to be very difficult, so we need to reassign responsibilities. That's ok now, when we know what is difficult and why people need to be moved, but we cannot know that initially, so initially we make a guess that every person will be able to develop one function.
Check whether you like one of the project ideas described here.
Note that the purpose of project descriptions that you will find there is not to specify what you should do in your project.
The reason why I provided these project descriptions is just to save you some time wondering what to do and give you some preliminary ideas, so that you can start thinking about your own proposed system. So, this is just to start you thinking about the issues. You can add or subtract anything that you feel would be appropriate.
You should also check what the student groups in the past years did.
If you choose to work from an existing project, 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 can find example past proposals by student groups in the download materials provided on project pages. They are not posted as separate documents, but they are included in the final reports, in the section called “Customer Statement of Requirements (CSR)”.
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)