Why Software Design Matters

When people imagine creating software, they often picture coding.

While coding is certainly important, good software rarely begins there.

Before writing code, software developers need to understand the problem they are trying to solve, who will use the system, what the system needs to do, and how different pieces of the solution will work together. This process is known as software design.

At its core, software design is the process of thinking carefully before building.

It involves asking questions, gathering information, identifying needs, exploring possible solutions, planning timelines, and making thoughtful decisions about how software should function.

In other words:

Good software does not happen by accident.

Good software is usually the result of thoughtful planning, communication, testing, and revision.

Think about software you use every day.

Some software feels intuitive and easy to use. It solves problems efficiently, works reliably, and helps you accomplish tasks without much frustration.

Other software can feel confusing, frustrating, or poorly designed. Maybe it crashes often, feels difficult to navigate, or fails to meet your needs.

What explains the difference?

In many cases, the difference comes down to the quality of the software design process.

Software Design Is Not One-Size-Fits-All

One important thing to understand is that there is no single “correct” way to design software.

The methods used to design software will depend on many factors, including:

• the size of the project,
• the number of people involved,
• timelines and available resources,
• project complexity,
• user needs,
• and the goals of the organization.

For example:

• A single developer creating a small application may rely on a simple list of user stories and sketches.
• A small development team may use prototypes, timelines, use cases, and regular feedback sessions.
• A large software company building a complex system may require detailed requirements documents, testing plans, UML diagrams, timelines, and multiple development teams.

The important takeaway is this:

Good software designers adapt their process to fit the problem.

Because different situations require different approaches, developers have created many ways to organize software development over time. These approaches are called software design processes.

You may already be familiar with some of these approaches from previous courses, internships, co-op placements, or workplace experience. Examples include:

• Waterfall
• Agile
• Spiral
• Scrum

Each process has its own strengths, weaknesses, and preferred situations.

At first glance, these approaches may seem very different from one another. However, most software design processes share something important in common:

They generally move through similar stages of development.

These stages often include:

1. Planning – understanding the problem and organizing the project
2. Analysis – evaluating ideas, requirements, and constraints
3. Design – developing and testing possible solutions
4. Implementation – building the software
5. Testing – identifying problems and improving quality
6. Maintenance – updating and improving software over time

In the next section, we will explore each of these stages in more detail and discuss what software developers actually do during them.

Stages Of Software Design

Although software design processes may look different from one another, most follow a similar pattern.

Whether a team uses Waterfall, Agile, Scrum, or another approach, software development usually moves through a series of stages that help teams understand problems, make decisions, build solutions, and improve them over time.

Most software design processes include six broad stages:

1. Planning
2. Analysis
3. Design
4. Implementation
5. Testing
6. Maintenance

At first glance, these stages may seem straightforward. However, software design is rarely as neat and orderly as a checklist.

Teams often move back and forth between stages, revisit earlier decisions, or rethink ideas after learning something new. In other words:

Software design is iterative.

You will often discover things during the process that require you to rethink earlier assumptions.

Let’s explore what each stage involves.

Planning

The planning stage focuses on understanding the problem and organizing the project.

Before building anything, software developers need to understand:

• What problem are we trying to solve?
• Who are the users?
• What do users and clients actually need?
• What resources are available?
• What constraints exist?

Answering these questions often requires research.

Depending on the project, research might include:

• interviews or conversations with clients,
• surveys or focus groups,
• observations of users,
• reviews of competing software,
• market research,
• literature or policy reviews,
• discussions with experts.

For example, imagine a community organization wants a system to coordinate volunteers.

Before building anything, you would probably want to understand:

• how volunteers currently sign up,
• what frustrations exist,
• who manages scheduling,
• what information needs to be tracked,
• and what the organization can realistically support.

Planning also includes making decisions about timelines, responsibilities, goals, priorities, and the overall direction of the project.

Most importantly:

Planning is not coding.

While it can feel tempting to jump straight into implementation, taking time to understand the problem almost always leads to better software.

Analysis

The analysis stage involves thinking critically about ideas, assumptions, and decisions.

This is the stage where teams ask questions like:

• Do we fully understand the problem?
• Are we solving the right problem?
• Is this feature necessary?
• Do we have enough time and resources?
• What risks or unintended consequences might exist?

Analysis often overlaps with planning.

For example, you might begin with one idea for a solution, only to discover through conversations with users that your assumptions were incorrect. This is normal.

Good software designers are willing to revise their thinking when new information becomes available.

Analysis may also involve considering:

• privacy,
• security,
• ethics,
• accessibility,
• equity,
• unintended consequences.

For example, a system that works well for one group of users may unintentionally create barriers for another.

In many ways, the analysis stage is about slowing down and asking:

“Are we confident this makes sense?”

Design

The design stage is where ideas begin to take shape.

Once a team better understands the problem, they can begin exploring possible solutions and creating representations of how the software might work.

This process is known as prototyping.

A prototype is simply a representation of a possible solution.

Many students immediately think of screens or interfaces when they hear the word prototype — but prototypes can take many forms.

Depending on the project, teams might design:

• sketches,
• paper prototypes,
• wireframes,
• storyboards,
• workflows,
• database structures,
• UML diagrams,
• pseudocode.

The goal of prototyping is not perfection.

Instead, prototypes help teams:

• clarify ideas,
• identify problems,
• ask better questions,
• gather feedback,
• test assumptions.

Most importantly, prototypes make ideas easier to discuss with users and clients.

Rather than asking:

“Would you like software that helps manage volunteers?”

you can instead ask:

“What do you think about this proposed system?”

That conversation is usually much more useful.

The design stage often results in some form of design documentation that guides future development.

Implementation

The implementation stage is where software begins to get built.

This is the stage most people think about when they imagine software development:

coding

Implementation may involve building:

• databases,
• APIs,
• interfaces,
• mobile applications,
• backend systems,
• integrations with other tools.

However, implementation is about more than writing code.

Teams must also monitor progress, communicate with one another, revisit timelines, and adapt when problems arise.

Projects rarely unfold exactly as expected.

New challenges emerge, timelines shift, bugs appear, and priorities change. Good teams adapt.

Implementation also often includes regular communication with clients or users to gather feedback and ensure development remains aligned with project goals.

Testing

Testing should happen throughout the software design process — not only at the end.

While formal testing may happen later in development, software teams should be asking critical questions from the beginning.

For example:

• Does this idea make sense?
• Are users responding positively?
• Did we overlook something?
• Does the system behave as expected?

Formal testing may include:

• unit testing,
• usability testing,
• edge case testing,
• accessibility testing,
• integration testing.

But testing also means challenging assumptions and checking whether the solution is actually solving the problem it was designed to address.

A simple rule to remember:

Do not wait until the end to test.

Maintenance

Most software is never truly “finished.”

After release, software often continues to evolve.

Users discover bugs, new needs emerge, technologies change, and laws or standards shift over time.

For example:

• accessibility standards may change,
• privacy requirements may evolve,
• users may request new features,
• software dependencies may stop working.

The maintenance stage focuses on keeping software useful, functional, and relevant over time.

This may include:

• fixing bugs,
• improving performance,
• updating features,
• improving usability,
• addressing security issues,
• responding to user feedback.

Good software continues to improve.

Why These Stages Overlap

You might have noticed that these stages do not always happen in a perfect order.

Real software design is messy.

Sometimes teams return to planning after learning something new during implementation.

Sometimes testing reveals problems that require redesign.

Sometimes users provide feedback that changes priorities completely.

This is normal.

Software design is rarely a straight line.

Instead, think of it as a cycle of learning, building, reflecting, and improving.

Where CIS3750 Fits In

By now, you may have noticed something important:

CIS3750 is not primarily a coding course.

For some students, this can feel surprising — or even frustrating at first.

Many students enter the course excited to start building software immediately. That reaction makes sense. When we encounter an interesting problem, our instinct is often to jump straight into implementation.

However, one of the biggest lessons in software design is this:

Good software starts with understanding the problem.

Before developers begin building, they must first understand:

• who the users are,
• what problem needs to be solved,
• what the system should do,
• what constraints exist,
• and how success will be measured.

Skipping these steps often leads to wasted time, unnecessary frustration, and software that does not actually solve the intended problem.

Why CIS3750 Focuses on Planning, Analysis, and Design

CIS3750 is an introductory software design course.

Because of this, our primary focus is on the first three stages of software development:

1. Planning
2. Analysis
3. Design

These stages help teams understand problems, organize ideas, gather feedback, and make thoughtful decisions before implementation begins.

Throughout the semester, you will learn methods that help you:

• identify user and client needs,
• write requirements,
• prioritize and organize ideas,
• estimate timelines,
• build prototypes,
• collect feedback,
• and communicate software ideas clearly.

These are foundational skills that support good software development in any environment.

“But When Do We Start Coding?”

This is one of the most common questions students ask.

The short answer is:

Later — and with much more confidence.

Many software projects fail because teams rush into implementation before fully understanding the problem.

For example, imagine spending weeks building a system only to discover:

• you misunderstood the client’s needs,
• users wanted something different,
• accessibility concerns were overlooked,
• or the feature was never actually necessary.

Careful planning helps prevent these problems.

Think of software design like building a house.

Most people would not begin construction by randomly pouring concrete and hoping things work out. Instead, they would spend time understanding the goals, creating plans, identifying constraints, and reviewing designs before construction begins.

Software works in much the same way.

The Goal of CIS3750

By the end of the semester, you should feel more confident answering questions such as:

• How do I identify the right problem to solve?
• How do I gather and organize requirements?
• How do I evaluate competing ideas?
• How do I communicate software ideas to others?
• How do I prototype and improve a solution?

These are the skills that make software implementation more successful later.

In other words:

CIS3750 helps you learn how to think like a software designer before asking you to think like a software developer.

And while this may feel slower at first, students often discover that taking time to understand the problem ultimately makes implementation easier, faster, and more effective.

Where Software Design Processes Come From

Software design processes did not appear overnight.

They developed over time as software teams worked on real projects, encountered challenges, learned from mistakes, and identified practices that helped teams work more effectively.

In many ways, software design processes are collections of lessons learned.

Over time, developers began noticing patterns:

• certain approaches worked better for certain kinds of projects,
• some methods improved communication,
• some planning tools reduced mistakes,
• some testing strategies improved software quality.

Eventually, these ideas were combined into formal approaches to software development.

That is how software design processes such as Waterfall, Agile, and Spiral emerged.

Importantly, no process guarantees success.

There is no perfect method that prevents challenges, uncertainty, or mistakes.

Instead, software design processes provide:

guidance based on the experiences of people who have solved similar problems before.

You can think of them as organized collections of best practices.

Choosing the Right Software Design Process

So, how do you decide which software design process to use?

The answer depends on the project.

Different situations call for different approaches.

Factors that influence this decision include:

• project size,
• team size,
• timelines,
• complexity,
• available resources,
• client needs,
• uncertainty,
• and organizational preferences.

For example:

• A small, fast-moving project may benefit from an Agile approach that emphasizes flexibility and quick feedback.
• A large project with clear requirements and multiple teams may benefit from a more structured approach.

The important takeaway is this:

There is rarely one universally “best” process.

Good software designers select methods that fit the situation.

Throughout CIS3750, we will continue revisiting this idea as we learn different tools and methods. For each method, we will discuss:

When might this be useful?
When might this not make sense?

Learning software design is not about memorizing one process.

It is about developing the ability to make thoughtful decisions about which tools and approaches best fit a particular challenge.