Chapter 3: Tips for managing requirements

  1. 3A. Proposing a project
    1. 3.1 Choose a worthy cause
    2. 3.2 Know your market
    3. 3.3 Target real users
    4. 3.4 Dream 'grand', promise 'doable'
    5. 3.5 Name it well
    6. 3.6 Sell the idea
  2. 3B. Dealing with product features
    1. 3.7 Put vision before features
    2. 3.8 Focus features
    3. 3.9 Categorise, prioritise
    4. 3.10 Focus users
    5. 3.11 Get early feedback
    6. 3.12 Gently exceed expectations
  3. 3C. Managing product releases
    1. 3.13 Publicise your product
    2. 3.14 Release gradually
    3. 3.15 Nurture early adopters
    4. 3.16 Act professional
    5. 3.17 Plan maintenance

Some project courses give a product specification for students to implement while other courses let student choose what to implement. Some projects have actual external/internal clients while others let students develop a product for an assumed potential market. Whichever the case in your course, at least some of these tips can help you manage the requirements of your project.

3A. Proposing a project

This section is useful if your project course allows you to define your own project.

3.1 Choose a worthy cause

The hardships of the project will be much easier to bear (and the final result much more satisfying) if you build something that you all believe in. Do not choose something that will simply fulfil the course requirements with the least amount of effort. For example, if you are building a utility that will solve a problem for someone, you should be convinced that it is a real problem worth solving. If it is a game, you should feel like it is a fun game to play and many others will enjoy playing it. 

For the same reason, do not opt to duplicate something that has been done before unless you plan to do it in a novel way or achieve a better outcome than the previous efforts.

Having chosen a product, continue to have faith in it. The battle is lost the moment you stop believing in your product; do not start a battle that is lost even before it is started.

3.2 Know your market

The trouble with most good ideas you have is that many others had the same idea long before you. If you have very little experience in the chosen product domain, it is helpful to do an extensive examination of all similar products in the market. Well, at least Google around a bit before you declare your idea 'ground breaking' or 'novel'. However, do not plagiarise things from existing products.

Note that the lack of or low level of competition can be the sign of a good opportunity or of a bad product idea. Sometimes, there is a reason why nobody else is doing it.

3.3 Target real users

Not many project courses allow students to build software for a specific customer, especially if the customer is a commercial entity. However, most will allow you to release the software to the public. In either case, having real people using your software and giving you feedback can be really motivating and useful at the same time.

If possible, choose to build something that you and your teammates can use so that you have some real users close at hand all the time. It is pretty hard to second guess user needs for a product that you cannot relate to, and the result would be rather inaccurate too.

While your course might not allow external clients, you might still be able to have internal clients from within the university. Check with professors in your university; most have software development needs that cannot be satisfied by their own research students. 

3.4 Dream 'grand', promise 'doable'

It is helpful to have a grand vision for your product. For example, rather than 'just another foo', you can go for something like 'the most streamlined foo', 'the most versatile foo', or 'the best foo on the platform bar'. The course duration may not be long enough to achieve this grand vision entirely, but it is still good to have such a vision. However, you should also promise to deliver a version of your product that makes significant progress towards your grand vision and yet is 'doable' within the given time constraints. If you are targeting real users, this version should be useful by itself to at least a sub-section of those users.

The idea here is that you should contribute something useful towards your grand vision before the course ends, and hopefully you will be motivated to continue the project towards your grand vision even after the course. Did you know that many successful products have roots in class projects?.

3.5 Name it well

Many students underestimate the benefits of a good product name. This is especially important if you plan a public release of the product. Here are some things to consider.

3.6 Sell the idea

If the course requires you put in a proposal for approval, take note of the following:

3B. Dealing with product features

3.7 Put vision before features

Combining a multitude of good features does not automatically give you a good product, just as duct-taping a good camera to a good phone [] does not give you a good camera phone. Resist the temptation to make up a product by combining feature proposals from all team members. The vision for your product is the first thing you should settle because it dictates the features for your product. Defining a vision after deciding features is like shooting the arrow first and painting the target where it landed. It is very important that you are clear about the vision, scope and the target market for the product. These should be documented and made available to others in the team, instructor and any other stake holders.

3.8 Focus features

Given the tight resource constraints of a student project, you cannot afford to be distracted by any feature that is not central to your product's vision. Ditch features that do not match the product vision, no matter how 'cool' or 'useful' they are.

Do not provide features because you think they 'can be given at zero cost'. There is no such thing. Every feature has some cost. Include a feature only if there is a better justification than "it costs nothing".

Some teammates might try to squeeze in their 'pet features' for their own enjoyment. Reject them gently but firmly; if 'password security' is not essential to your product vision, do not add it even if one team member claims he already has the code for it and it can be added in 'no time'.

Aim in one direction. Avoid having multiple 'main' features that pull in different directions. Choose other 'minor' features in a way that they strengthen this 'main' feature even more. One 'fully baked' feature is worth two 'half-baked' ones.

Do not feel compelled to implement all 'commonplace features' of similar products before you move to those exciting features that will differentiate your product. A product can survive with some 'glaring omissions' of common features if it has a strong 'unique' feature. Take note that the successful iPhone did not have many 'common' features such as 'SMS forwarding' when it was first released.

3.9 Categorise, prioritise

Categorise and order requirements based on criteria such as priority, urgency, cost, complexity, utility, risk, type of function and type of user. You won't have time to implement them all. In fact, there will not be enough time to do even the ones you thought you could. It is easier to make optimal keep-or-drop decisions if you already have your features categorised and ordered. Besides, having such a list can earn you extra credit because it shows how systematic you were in selecting features to implement.

3.10 Focus users

Larger targets are easier to hit but harder to conquer. It is better to target your product for a well-identified small market (e.g. faculty members of own university) than a vaguely-defined but supposedly larger market (e.g. all office workers). To take this approach to an extreme, it is even acceptable to identify a single real user and cater for that person fully than trying to cater for an unknown market of an unknown number of users.

It is critically important that you use the users' perspective when deciding what features to include in a product. What is 'cool' to you may not be 'cool' to users. Do not choose 'technically challenging' yet 'harder to implement' features if there is no significant benefit to the user.

3.11 Get early feedback

Get feedback from your client and from your supervisor. If you do not have a specific client, find a potential user who is willing to give you feedback. Force yourself to use the software; if you do not like it yourself, it is unlikely someone else will.

You can use requirements specifications or an early prototype as the basis for soliciting feedback. Another good strategy is to write the user manual very early and use that to get feedback.

Do not be afraid to change direction based on early feedback, when there is still enough time left. That is precisely why you need to get feedback early

3.12 Gently exceed expectations

Plan to deliver a little bit more than what is generally expected or previously promised. This will delight the evaluator. Conversely, delivering even slightly less than previously promised creates a feeling of disappointment, even if what you managed to deliver is still good.

3C. Managing product releases

This section is especially useful if you are releasing your product to the public.

3.13 Publicise your product

If you do a public release, try to spend some effort publicising your project among potential users. Note that most evaluators will not give extra marks for such efforts; but it is still worth doing. There are many websites, such as,, and that will host your software for others to download, rate your software, and even write reviews for your software. Here [] is a sample review for a software product written by students. If your software is good, even popular tech blogs such as and will start publishing reviews, boosting your download count even more. Here [] is such a review for a software written by students. It is helpful to have a website for your product, and even your own domain name. You can easily buy a domain name for less than $10/year. There are many ways to create a website for free (e.g. using Google Sites). Project hosting environments such as Google Code Project Hosting (GCPH), too, will let you create a project website. For example, is the home page of a sample student project hosted on GCPH.

Other ways to publicise your project:

3.14 Release gradually

It is not a good idea to throw your very first release at ALL your potential users. Releasing it gradually gives you more opportunities to refine your product to fit the market. For example, you can do an alpha release among your friends and get some friendly feedback. After that, refine the product and do a beta release to a small community such as posting in a public forum that you participate (but make sure the forum allows such posting, or you will be flamed for spamming). Next, refine it further before you go for a full public release. If time permits, and you are allowed by the course structure, do all these releases before the final project submission because the feedback you get from these releases will make your final submission all the better.

3.15 Nurture early adopters

Carefully nurturing early adopters is important to a new product as it is important for a budding leader to nurture early followers []. First of all, make sure they have a way to reach you. You can either build a 'give feedback' feature into the product or use an indirect mechanism such as Google Groups.

If possible, create a mechanism for current users to be notified about new releases. This way, you get a second shot at those who did not like the early release they tried. For example, you can build a 'check for updates' mechanism into the product, use the 'follow us on facebook/twitter' technique, or collect their email addresses so that you can email them about updates.

3.16 Act professional

You are a developer of a real product; act like one. Get out of your 'still a student' mentality. All public-facing materials should be professional and should inspire confidence in potential users. In my opinion, declaring the project a school project does not inspire confidence in potential users. Yes, people will be impressed to see how much you have accomplished even as students; but they will hesitate to become a real user of your software. Therefore, think twice before putting references to course-related matters in public-facing project materials.

3.17 Plan maintenance

It would be a pity to let your product die off after the course ends, especially if you already have some real users using it. Being 'one of the founders' of an existing product can be a real boost to your resumé. But more importantly, knowing that something you produced is being used by others is a really satisfying feeling. Therefore, try your best to keep the product alive after the course. However, note that the time and energy you can spend on the project will most likely be reduced after the course. Plan accordingly. Be wary of undertaking drastic changes to the product; rather, concentrate on sustaining and perfecting what you have. Also note that some project members might not continue with you and some may not be as available as before. This means there should be more than one person who can take care of a particular aspect at this stage. The project should not fall apart just because one of the team members dropped out of the project after the course.

Giving feedback

Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]

Sharing this book helps too!


---| This page is from the free online book Practical Tips for Software-Intensive Student Projects V3.0, Jul 2010, Author: Damith C. Rajapakse |---

free statistics free hit counter javascript