Skip to content

Creating Software: The Design Phase

Posted on:July 15, 2008

Creating software is difficult. You need to first get the requirements from the client (or create them yourselves), then you’ll use the requirements and design a working system. Once you’ve designed the system, turn the design into code. Next you’ll test your code to make sure it works and finally deliver the completed project to the client.

Today I’m going to look at the second part of the Creating Software series : The Design phase. There are a number of aspects to designing software. You need to take the requirements you gathered previously and start to create your software. At this point, you’ll have very little code (and possibly none at all). Don’t let this fool you though, the design phase is extremely important, and many projects have failed because they either didn’t design, or improperly designed their software.

Here are three things you can do in the design phase to make your software project more likely to succeed.

Use Cases

Use Cases

Use Cases are basically a description of your system’s behaviour as it responds to a request that originates from outside of that system. In layman’s terms, they essentially give yourself and your developers an idea of what the project will consist of and how it will behave.

A use case consists of:

I generally find that I have a pretty good idea of what I have to build after I’ve written out the Use Cases. While there are many other things that you’ll need for a proper design of the software, you should make sure that you include Use Cases.

Paper Prototyping

Paper Prototyping

The client always wants to see a mock-up of the project before its anywhere close to being done. They want to see how the design is coming to get a rough estimate of when it will be completed. A novice would quickly code a semi-functioning UI and show it to the client with hopes that they’ll like it. THIS IS BAD!

What happens when the client uses the rough design and love it. They think you’re showing them a fully functioning product even when its only bare-bones. I’ve done this once and I’ll never do it again (I cringe whenever I see a noobie developer fall into this trap). The problem is, that the client will think that you are almost done and wonder why the project is taking so long to complete.

Instead of writing up a semi-functioning UI, you should write down a mock-up of your software on paper and show them that. This has a few pros.

By understanding the different uses of the system (through Use cases), you can essentially put the entire project on paper and have the client walk through how they would use it. This will show you any pitfalls in your design of the system. It will also not give the client the wrong impression of your progress. Paper prototyping is a Win-Win in my opinion.

Evaluate the Design against the Requirements

Evaluate the Design against the Requirements

While you’re designing the software you need to keep in mind the requirements you collected from the client (or the ones you made yourself). As you continue to design you need to refine your requirements and make sure that you’re making the product that your client works. This is called verification.

Verification is the process of determining whether you’ve built the right program from the given requirements and validation means checking to see if the product does what the customer (or user) actually wants the product to do under real-world conditions, or as-close-to-real-world conditions as you can possibly simulate.

You may have to go back to the client and ask to re-clarify requirements, goals, etc… if you find that your verification fails.

Your Thoughts?

Your Thoughts?

How do you go about designing your software projects? Do you bother with Use Cases and Paper Prototyping? What do you find works the best when trying to get a full understanding of the project? Tell me your stories or tricks in the comment section below.

Related Posts