Back to Basics: Software Design Ideation & Requirement Specifications

By Taryn Engmark

Associate Editor

Embedded Computing Design

One thing every engineer — whether you’re a beginner, hobbyist, or pro — will need to do at some point is conceptualize a project. But what does that process look like from start to finish? Where do you even begin? Well, we’ve got you covered.

Welcome to Back to Basics, a series where we’re reviewing basic engineering concepts that require a more complex explanation than Google can provide.

Over the next several articles in this series, we’ll be outlining each step in the process of creating and executing a software project, starting, of course, with step 1: Ideation.

Get That Brain Fluid Flowing

When starting a project of any size, it’s important to know where you’re going. Ideation and design requirement search are two essential tools for accomplishing this goal.

Ideation is the simple process of asking yourself a few essential questions:

What is my project supposed to do? Code at its most basic form is just a set of instructions that perform a task or solve a problem. Before you start your project, you should be able to articulate your end goal.
Who is my project for? Every project is written for some person. Knowing the eventual end user and scope of your software will help inform later design requirement decisions.

Asking the above questions will help you focus your energy on concrete, large-scale goals for your work, rather than aimlessly coding or getting too overwhelmed. So, now that you have a clearer idea of what you want your finished project to accomplish, you can start looking into requirement specs.

Know Your Limits

Any project you undertake in your education or career will have requirement specifications, or limitations and criteria that the project must fit in or meet in order to be considered “good” or “complete.” For instance, in an education setting, you’ll most likely find most of your requirement specs in a rubric provided by your professor.

While a rubric is a great example, it’s not an end-all list of everything you will need. There are multiple requirements that should be considered for any project, including:

Budget: Any project is going to cost something, whether it is time, money, or effort. How much do you have to spend on the project?
Materials Access: There are limitless tools to help you with software design, but what do you have access to? Are you willing to count that in the overall cost?
User Design Reqs: A user will have a vision in mind for what your software will do, how it will look, or how well it will run. What are they asking of you, the developer?
Hardware Limitations: If you’re writing code for a less powerful machine, it will limit or shape how you write. What can your hardware handle?
Personal Design Reqs: The user may have a set of requirements, but you, as the developer, have your own vision. How do your vision and the user’s overlap or deviate?

Between ideation and spec requirements, you should have a solid grasp of your project’s broad strokes and the resources you’ll need for successful code writing. In the end, this should save you a lot of resources, limiting the amount of unnecessary code written or time spent banging your head against the wall.

The next installment of this series is focused on gathering the development tools you’ll need to actually begin writing your project, so click here to read on!

Click here to read the third installment of Back to Basics: Configuring the Environment

Click here to read the fourth installment of Back to Basics: Pseudocode

Click here to read the fifth installment of Back to Basics: Coding and Commenting

Click here to read the sixth installmen of Back to Basics: Debugging Code

Click here to read the seventh intallment of Back to Basics: Quality Assurance & Testing

Click here to read the eighth and final installment of Back to Basics: Software Release