As we set off on our journey to develop software, it makes sense to take some time to consider what makes good software. That is, what are the characteristics that differentiate good software from bad software? The answer to this question will vary based on how you are connected to the software. A user will likely have a very different list of things that they believe make good software than a developer might have. While a user might be interested in ease of use, a developer might be concerned with the ability to easily modify code. Further still, a client might be focused only on staying within budget.

What Makes Good Software?

Take a moment to think about the software you’ve developed or used. Based on your experiences, what makes good software?

Now put yourself into the shoes of the various different people who might interact with a software system: the client, the user, future developers, testers, or individuals from other external sources who might influence the design and implementation of software (such as government agencies, or professional associations). How do you think they would characterize good software?

Ultimately, good software requires three main things: General Requirements, Legal Requirements, and Specific Requirements.

General Requirements

General requirements are general in the sense that they apply to all software development. In many cases, general requirements meet the needs of the software designers, coders, and testers. This includes things such as well-documented, readable, modifiable, testable, and portable code.

Legal Requirements

Legal requirements will vary by location – and whether or not they lead to “good” software might be debatable. However, at the very least, building these requirements into the software ensures that we can distribute it without getting into trouble – and that’s probably a good thing.

In Ontario, at least two pieces of legislation affect the design of whatever software we might be building. And there’s at least one piece of legislation that we need to be aware of at the federal level. This includes legislation related to spam and privacy, as well as legislation that ensures software is accessible to all Ontarians. These include:

• the Accessibility for Ontarians with Disabilities Act (AODA)
• the Personal Information Protection and Electronic Documents Act (PIPEDA), and
• Canada’s Anti-Spam Legislation (CASL)

The Accessibility for Ontarians with Disabilities Act (AODA) was established in 2005 to ensure that all Ontarians – regardless of
their abilities – have equitable access to physical spaces, as well as online.

This means that we need to consider potential barriers to any online software or mobile apps that we might develop – including barriers related to impaired motor skills, cognitive functioning, visual or audio challenges, and more. The AODA legislation was also described in stages, with institutions like the University of Guelph beginning the transition to improved accessibility with commitments to achieve different levels of compliance each year. You can find more details about this here. We will explore AODA considerations again later in this manual.

The Personal Information Protection and Electronic Documents Act became law in 2000. This law outlines how businesses are allowed to use personal data that are collected as part of their ongoing activities.

Federal legislation known as the Canadian Anti-Spam Legislation was enacted in 2014. This law was developed to protect the privacy of Canadians.

Of course, new legislation is created all the time, and old laws are rewritten. With this in mind, AODA, PIPEDA, and Anti-Spam legislation may not be the only pieces of legislation that are important to your design choices. As a software developer, it is essential that you stay up to date on any other laws that might affect how and what you design.

Specific Requirements

Specific requirements help define the problem we are trying to solve. They identify the WHAT of the system – not the HOW. That is, a specific requirement tells us something that the system we are designing will need to have for it to be considered a solution to the problem. It does not tell us how to build that thing that is required. In fact, there are probably any number of ways that each requirement could be satisfied.

For this reason, a requirement is not an instruction. But what is the difference, and why does it matter when we begin the process of understanding and solving a problem?

A quick Google search provides the following definitions of instructions and requirements. Do you see the difference?

But how do we identify the specific requirements of our system? The short answer is through research. Now before you worry that this means you’re going to need to review numerous academic journals and conference proceedings, recognize that research can include:

• Scientific literature (peer-reviewed academic journals and conference proceedings)
• Grey literature (research produced by industry that hasn’t been peer-reviewed, or that is available on reputable blogs)
• Domain expertise (chatting with the client and people familiar with the problem you are trying to solve)
• User studies (work with the users of the system to ensure you understand their needs)

While our work might involve reviewing a few academic papers or grey literature documents, most of the work we do will be informed by domain expertise and user studies. While you might think that this will be simpler than reviewing numerous reports, gathering knowledge from domain experts and user studies takes time and care. In CIS3750, we’ll begin learning some of the skills required to do this.

Building Good Software

Beyond understanding the problem and developing a good list of software requirements, we as developers need to live up to a certain standard to ensure that the software we produce is good. To do this, we need to:

• practice and continue developing excellent coding skills; including keeping up to date on standards and new methods or tools,
• develop and practice excellent communication skills; within your team, between teams, and with the client and users, and
• have excellent planning skills; to ensure we can deliver what we need to deliver in a timely manner.

At this point in your education, we assume that you have excellent coding skills (and continue to develop them). For this reason, your coding skills are not a focus of CIS3750. However, communication and planning are the bedrock of this course. As such, you will spend much of your time in situations to develop your skills in these areas.

Review Questions