This is when you present all the prototypes, documents, and information you have gathered.

As soon as
everybody agrees with the specification, you are ready to start studying the best way to implement this
part of your project.

It is worth mentioning that you might use the process described here for either the complete software or for just a
small part of it.

Using design techniques as a helpful tool

Defining a solution is not easy. Determining which technology to use is also difficult. It is true that, during
your career as a software architect, you will find many projects where your customer will bring you a solution ready
for development. This can get quite complicated if you consider that solution as the correct solution; most of the
time, there will be architectural and functional mistakes that will cause problems in the solution in the
future.

There are some cases where the problem is worse – when the customer does not know the best solution for the
problem. Some design techniques can help us with this, and we will introduce two of them here: Design
Thinking and Design Sprint.

What you must understand is that these techniques can be a fantastic option to discover real require-
ments. As a software architect, you are committed to helping your team to use the correct tools at the
correct time, and these tools may be the right options to ensure the project’s success.

Design Thinking

Design Thinking is a process that allows you to collect data directly from the users, focusing on achieving
the best results to solve a problem. During this process, the team will have the opportunity to discover all
the personas that will interact with the system. This will have a wonderful impact on the solution since you
can develop the software by focusing on the user experience, which can have a fantastic impact on the
results.

The process is based on the following steps:

Empathize: In this step, you must execute field research to discover the users’ concerns. This is
where you find out about the users of the system. The process is good for making you un-
derstand why and for whom you are developing this software.

Define: Once you have the users’ concerns, it is time to define their needs to solve them.

Ideate: The needs will provide an opportunity to brainstorm some possible solutions.

Prototype: These solutions can be developed as mock-ups to confirm whether they are good
ones.

Test: Testing the prototypes will help you to understand the prototype that is most connected to
the real needs of the users.

The focus of a technique like this one is to accelerate the process of discerning the right product
and considering the Minimum Viable Product (MVP). For sure, the prototype process will help stakeholders
to understand the final product and, at the same time, engage the team to deliver the best
solution.
Chapter 1 21 Design Sprint

Design Sprint is a process focused on solving critical business questions through design in a five-day
sprint. This technique was presented by Google, and it is something that allows you to quickly test and
learn from an idea when you are looking to build and launch a solution to market.

The process involves experts spending a week to solve the problem at hand, in a war room prepared for
that purpose. The week is like this:

Monday: The focus of this day is to identify the target of the sprint and map the challenge to
achieve it.

Tuesday: After understanding the goal of the sprint, participants start sketching solutions that may solve it.
It is time to find customers to test the new solution that will be provided.

Wednesday: This is when the team needs to decide the solutions that have the greatest chance
to solve the problem. The team must draw these solutions into a storyboard, preparing a plan for
the prototype.

Thursday: It is time to prototype the idea planned on the storyboard.

Friday: Having completed the prototype, the team presents it to customers, learning by getting

information from their reaction to the solution designed.

As you can see, in both techniques, the acceleration of collecting reactions from customers
comes from prototypes that will materialize your team’s ideas into something more tangible for
the end user.

Common cases where the requirements gathering

process impacts system results
All the information discussed up to this point in the chapter is useful if you want to design
software following the principles of good engineering. There is no encouragement to develop by
using tradi- tional or agile methods in particular, but a focus on building software professionally.

It is also a good idea to know about some cases in which failing to perform the activities you read about can
cause some trouble for a software project. The following cases intend to describe what can go wrong, and
how the preceding techniques can help a development team to solve the associated problems.

In most cases, very simple action can guarantee better communication between the team and the
customer, and this easy communication flow can transform a big problem into a real solution. Let
us examine three common cases where requirements gathering can impact software
performance, functionality, and usability.

Case 1 – my website is too slow to open that page!

Performance is one of the biggest problems that you as a software architect will deal with during
your career. The reason why this aspect of any software is so problematic is that we do not have
infinite computational resources to solve problems. The cost of computation is still high,
especially if you are talking about software with a high number of simultaneous users.