Process of design in software development

You can think of developing software as a process that takes a problem and produces a solution involving software. Normally, it’s an iterative process, with each iteration taking a set of requirements through to a working and tested implementation and eventually building up a complete solution.

Many developers are eager to go straight into coding despite not fully understanding what to program in the first place. Evidence suggests that diving straight into implementation work is a leading cause of project failure.

In a survey from The Standish Group, the most common causes of project failures are related to issues in requirements and design. For example, about 13% of respondents noted incomplete requirements impaired their projects. Unless you want your projects to fail, take your time to form requirements and create a design. You might not get them perfect, but their importance to effectively making good software should not be overlooked.

We will cover how eliciting requirements involves actively probing a client’s vision, by asking questions about issues that the client may not have considered. With a clear idea of what you are trying to accomplish, you can pivot to Conceptual Design mock-ups and eventually, Technical Design diagrams. You may be eager to tackle implementation work and get something working, but the requirements and design activities are critical. This starting point is known as eliciting requirements.

Eliciting requirements involves not only listening to what the client is telling you but asking questions to clarify what the client has not told you. The art of eliciting requirements is found in asking revealing follow up questions. Once these questions are answered, you now have an initial set of requirements allowing you to start thinking of possible designs. The design activity involves taking requirements and outlining a solution.

This activity involves producing a conceptual design and then a technical design, which results in two corresponding kinds of artifacts, conceptual mockups and technical diagrams.

Conceptual mockups provide your initial thoughts on how the requirements will be satisfied. At this point, you focus on design by identifying major components and connections and defer the technical details.

I recommend finishing the conceptual design before moving on to forming the technical design. The clearer your conceptual design is, the better your technical designs will be. After the conceptual mockups are done, it is time to define the technical details of the solution.

From the conceptual design, you know all the major components and connections and their associated responsibilities. Describing how these responsibilities are met is the goal of technical design. In a technical design, you start specifying the technical details of each component. This is done by splitting components into smaller and smaller components that are specific enough to be designed in detail.

Suppose that we have a design task for searching courses for a school website.

Requirement: As a learner, I want to search for relevant courses through a search page.

Now, let’s do a conceptual design.

We recognize the search page and course as the components, and the search page has the responsibility of searching for relevant courses.

When we look at our requirement: as a learner, I want to search for relevant courses through a search page. We recognize the search page and course as the components, and the search page has the responsibility of searching for relevant courses. By sketching a mockup of our user interface, we notice many missing components.

You’re probably wondering about how a search keyword is entered into the search page.

How is the search started?

How is the list of search results displayed?

These flaws in the initial mockup require further clarification with your client or more conceptual design work. Eventually, we generate a more comprehensive conceptual design or user interface mockup. The search page contains an input field and search button, and transitions to the result page. The course component is a way of displaying the result. From this mock up, we recognize many connections.

From a conceptual design, we move to make a technical design where, you try to add detail on how those components, connections and responsibilities can be implemented.

For example, how does the search page fulfil its responsibility of searching a list of courses? Does the page need to talk to an external system?

Suppose the school already has a Course Database component to which your course Search Page can connect. Since Search Page requires Course Database in order to fulfil its responsibility of search, a connection exists between Search Page and Course Database. Here, we can’t really use a conceptual user interface mockup, since we are now designing internal software components.

When they are refined enough, turn into collections of functions, classes or other components. These pieces then represent a much simpler problem that the developers can individually implement. You can easily imagine that larger systems require more design time. With large systems, there are also more components, connections and responsibilities to keep track of. And since these components themselves will be big, they will be refined to many more components before the design can be detailed.

You now have learned to take some time to think about the problem and outline the conceptual and technical design before actually implementing the solution. Design artifacts, like conceptual mockups, help to clarify design decisions with clients and users. Technical diagrams help to coordinate development work.