Software architecture is one of the most discussed topics in the software industry today, and its importance will certainly grow more in the future. The more we build complex and fantastic solutions, the more we need great software architectures to maintain them. But the speed at which new features are added to these software solutions keeps increasing, and new architectural opportunities keep emerging. That is the reason why you decided to read this book; it's the reason why we decided to write its second edition.
It's not a simple task to write about this important topic, which offers so many alternative techniques and solutions. The main objective of this book is not to build an exhaustive and never-ending list of available techniques and solutions, but to show how various families of techniques are related, and how they impact, in practice, the construction of a maintainable and sustainable solution.
The need to keep our focus on creating actual, effective enterprise solutions keeps increasing; users always need more new features in their applications. Moreover, the need to deliver frequent application versions (due to a quickly changing market) increases our obligation to have sophisticated software architecture and development techniques.
The following topics will be covered in this chapter:
The case study of this book will take you through the process of creating the software architecture for a travel agency called World Wild Travel Club (WWTravelClub). The purpose of this case study is to help you understand the theory explained in each chapter, and to provide an example of how to develop an enterprise application with Azure, Azure DevOps, C# 9, .NET 5, ASP.NET, and other technologies that will be introduced in this book.
By the end of this chapter, you will be able to understand exactly what the mission of software architecture is. You will also learn what Azure is, and how to create your account on the platform. You'll also get an overview of software processes, models, and other techniques that will enable you to conduct your team.
If you are reading this book today, you should thank the computer scientists who decided to consider software development as an engineering area. This happened in the last century, more specifically, at the end of the sixties, when they proposed that the way we develop software is quite like the way we construct buildings. That is why we have the name software architecture. Like an architect designs a building and oversees its construction based on that design, the main goal of a software architect is to ensure that the software application is implemented well; and good implementation requires the design of a great solution.
In a professional development project, you must do the following things:
Software engineering defines these activities as the software development life cycle. All the theoretical software development process models (waterfall, spiral, incremental, agile, and so on) are somehow related to this cycle. No matter which model you use, if you do not work with the essential tasks presented earlier during your project, you will not deliver acceptable software as a solution.
The main point about designing great solutions is foundational to the purpose of this book. You must understand that great real-world solutions bring with them a few fundamental constraints:
Great solutions need to be sustainable, and you must understand that there is no sustainable software without great software architecture. Nowadays, great software architectures depend on both modern tools and modern environments to perfectly fit users' requirements.
For this reason, this book will use some great tools provided by Microsoft. The company has announced .NET 5 as a unified platform for software development, which gives us a great opportunity to create fantastic solutions.
Figure 1.1: .NET 5 platform
NET 5 is delivered together with C# 9. Considering the .NET approach of targeting so many platforms and devices, C# is now one of the most used programming languages in the world and runs on small devices up to huge servers in different operating systems and environments.
The book will also use Azure, which is Microsoft's cloud platform, where you will find all the components the company provides to build advanced software architecture solutions. One of them is Azure DevOps, an application life cycle management environment where you can build solutions using the latest approach for developing software.
Being a software architect means understanding the aforementioned technologies, and a lot of others, too. This book will guide you on a journey where, as a software architect working in a team, you will provide optimal solutions with the tools listed. Let us start this journey by creating your Azure account.
Microsoft Azure is one of the best cloud solutions currently available on the market. It is important to know that, inside Azure, we will find a selection of components that can help us define the architecture of twenty-first-century solutions.
If you want to check the variety of components Microsoft Azure has, just check this incredible website developed by Alexey Polkovnikov: https://azurecharts.com/.
This subsection will guide you in creating an Azure account. If you already have one, you can skip this part.
Start your access into Azure using the website address https://azure.microsoft.com. There, you will find the information you need to start your subscription. Translation to your native language is usually set automatically.
Once you finish the form, you will be able to access the Azure portal. As you can see in the following screenshot, the panel shows a dashboard that you can customize, and a menu on the left, where you can set up the Azure components you are going to use in your solution. Throughout this book, we will come back to this screenshot to set up the components to help us create modern software architecture. To find the next page, just select the left-menu icon (hamburger menu) and click on All services.
Figure 1.2: The Azure portal
Once you have your Azure account created, you are ready to understand how a software architect can conduct a team to develop software, taking advantage of all the opportunities offered by Azure. However, it is important to keep in mind that a software architect needs to go beyond technologies because this role is played by people who are expected to define how the software will be delivered.
Today, a software architect not only architects the basis of a software, but also determines how the whole software development and deployment process is conducted. The next topic will cover some of the most widely used software development paradigms the world over. We'll start by describing what the community refers to as traditional software engineering. After that, we'll cover the agile models that have changed the way we build software nowadays.
As a software architect, it's important for you to understand some of the common development processes that are currently used in most enterprises. A software development process defines how people in a team produce and deliver software. In general, this process relates to a software engineering theory, called a software development process model. From the time software development was defined as an engineering process, many process models for developing software have been proposed. Let us review the traditional software models, and then look at the agile ones that are currently common.
Some of the models introduced in the software engineering theory are already considered traditional and quite obsolete. This book does not aim to cover all of them, but here, we will give a brief explanation of the ones that are still used in some companies – waterfall and incremental models.
This topic may appear strange in a software architecture book from 2020, but yes, you may still find companies where the most traditional software process model remains the guideline for software development. This process executes all fundamental tasks in sequence. Any software development project consists of the following steps:
Let us look at a diagrammatic representation of this:
Figure 1.3: The waterfall development cycle (https://en.wikipedia.org/wiki/Waterfall_model)
Often, the use of waterfall models causes problems related to delays in the delivery of a functional version of the software, and user dissatisfaction due to the distance between expectations and the final product delivered. Besides, in my experience, having application tests start only after the completion of development always feels terribly stressful.
Incremental development is an approach that tries to overcome the biggest problem of the waterfall model: the user can test the solution only at the end of the project. The idea of this model is to give the users opportunities to interact with the solution as early as possible so that they can give useful feedback, which will help during the development of the software.
Figure 1.4: The incremental development cycle (https://en.wikipedia.org/wiki/Incremental_build_model)
The incremental model presented in the preceding picture was introduced as an alternative to the waterfall approach. The idea of the model is to run for each increment a set of practices related to software development (Communication, Planning, Modeling, Construction, and Deployment). Although it mitigated the problems related to the lack of communication with the customer, for big projects, fewer increments were still a problem because the increments remained too long.
When the incremental approach was used on a large scale—mainly at the end of the last century—many problems related to project bureaucracy were reported, due to the large amount of documentation required. This clunky scenario caused the rise of a very important movement in the software development industry – agile.
At the beginning of this century, developing software was considered one of the most chaotic activities in engineering. The percentage of software projects that failed was incredibly high, and this fact proved the need for a different approach to deal with the flexibility required by software development projects.
In 2001, the Agile Manifesto was introduced to the world, and from that time forward various agile process models were proposed. Some of them have survived up until now and are still very common.
The Agile Manifesto is translated into more than 60 languages. Please check out its link at https://agilemanifesto.org/.
One of the biggest differences between agile models and traditional models is the way developers interact with the customer. The message that all agile models transmit is that the faster you deliver software to the user, the better. This idea is sometimes confusing for software developers who understand this as – let's try coding, and that's all, folks!
However, there is an important observation of the Agile Manifesto that many people do not read when they start working with agile:
Figure 1.5: Manifesto for Agile software development
A software architect always needs to remember this. Agile processes do not mean a lack of discipline. Moreover, when you use the agile process, you'll quickly understand that there is no way to develop good software without discipline. On the other hand, as a software architect, you need to understand that soft means flexibility. A software project that refuses to be flexible tends to ruin itself over time.
The 12 principles behind agile are foundational to this flexible approach:
Even 20 years after the launch of the Agile Manifesto, its importance and connection to the current needs of software teams remain intact. Certainly, there are many companies where this approach is not well accepted, but as a software architect you should understand this as an opportunity to transform practices and evolve the team with you are working.
There are many techniques and models that were presented to the software community with the agile approach. The next subtopics will discuss Lean software development, Extreme Programming, and Scrum, so that you can decide, as a software architect, which ones you might use to improve your software delivery.
After the Agile Manifesto, the approach of Lean software development was introduced to the community as an adaptation of a well-known movement in automobile engineering; Toyota's model for building cars. The worldwide Lean manufacturing method delivers a high level of quality even with few resources.
Mary and Tom Poppendieck listed seven Lean principles for software development, really connected to agile and to the approach of many companies of this century. I've listed them here:
The Lean principles cause a team or company approach to improve the quality of the features that the customer really needs. It also creates a reduction in time spent on features that will not be used by the time the software is delivered to the customer. In Lean, deciding the features that are important to the customer guides the team in delivering software that matters, and this is exactly what the Agile Manifesto intends to promote in software teams.
Just before the release of the Agile Manifesto, some of the participants who designed the document, especially Kent Beck, presented to the world the Extreme Programming (XP) methodology for developing software.
XP is based on values of simplicity, communication, feedback, respect, and courage. It was considered later as a social change in programming, according to Beck in his second book about the topic. It certainly promotes a huge change in the flow of development.
XP indicates that every team should have the simplicity to do only what it was asked for, communicating face to face daily, demonstrating the software early to get feedback, respecting the expertise of each member of the team, and having the courage to tell the truth about progress and estimates, considering the team's work as a whole.
XP also delivers a set of rules. These rules may be changed by the team if they detect something is not working properly, but it's important to always maintain the values of the methodology.
These rules are divided into planning, managing, designing, coding, and testing. Don Wells has mapped XP at the site http://www.extremeprogramming.org/. Although some of the ideas of the methodology were criticized strongly by many companies and specialists, there are many good practices that are used today:
It is worth mentioning that many of these rules are today considered vital practices in different software development methodologies, including DevOps and Scrum. We will discuss DevOps later in this book, in Chapter 20, Understanding DevOps Principles. Let's get into the Scrum model right now.
Scrum is an agile model for the management of software development projects. The model comes from Lean principles and is one of the widely used approaches for developing software nowadays.
Please check this link for more information about the Scrum framework: https://www.scrum.org/.
As you can see in the following figure, the basis of Scrum is that you have a flexible backlog of user requirements (Product Backlog) that needs to be discussed in each agile cycle, called a Sprint. The Sprint goal (Sprint Backlog) is determined by the Scrum Team, composed of the Product Owner, the Scrum Master, and the Development Team. The Product Owner is responsible for prioritizing what will be delivered in that Sprint. During the Sprint, this person will help the team to develop the required features. The person who leads the team in the Scrum process is called the Scrum Master. All the meetings and processes are conducted by this person.
Figure 1.6: The Scrum process
It is important to notice that the Scrum process does not discuss how the software needs to be implemented, nor which activities will be done. Again, you must remember the basis of software development, discussed at the beginning of this chapter; that means Scrum needs to be implemented together with a process model. DevOps is one of the approaches that may help you use a software development process model together with Scrum. Check Chapter 20, Understanding DevOps Principles, to understand it better.
Fantastic! You just started a software development project. Now, it's time to use all your knowledge to deliver the best software you can. Your first question is probably – How do I start? Well, as a software architect, you're going to be the one to answer it. And you can be sure your answer is going to evolve with each software project you lead.
Defining a software development process is the first task. This is generally done during the project planning process, or might happen before it starts.
Another very important task is to gather the software requirements. No matter which software development process you decide to use, collecting real user needs is part of a difficult and continuous job. Of course, there are techniques to help you with this, and you can be sure that gathering requirements will help you to define important aspects of your software architecture.
These two tasks are considered by most experts in software development as the keys to success at the end of the development project journey. As a software architect, you need to enable them so that you can avoid as many problems as possible while guiding your team.
There are many different ways to represent the requirements. The most traditional approach consists of you having to write a perfect specification before the beginning of the analysis. Agile methods suggest instead that you need to write user stories, as soon as you are ready to start a development cycle.
Remember: You do not write requirements just for the user; you write them for you and your team too.
The truth is, that no matter the approach you decide to adopt in your projects, you will have to follow some steps to gather requirements. This is what we call requirements engineering.
Figure 1.7: Requirements engineering process
During this process, you need to be sure that the solution is feasible. In some cases, the feasibility analysis is part of the project planning process too, and by the time you start the requirements elicitation, you will have the feasibility report already done. So, let us check the other parts of this process, which will give you a lot of important information for the software architecture.
There are a lot of ways to detect what exactly the user needs for a specific scenario. This process is known as elicitation. In general, this can be done using techniques that will help you to understand what we call user requirements. Here, you have a list of common techniques:
As soon as you apply one or more of these techniques, you will have great and valuable information about the user's needs.
Remember: You can use these techniques in any situation where the real need is to gather requirements, no matter if it is for the whole system or for a single story.
At that moment, you will be able to start analyzing these user needs, and detecting the user and system requirements. Let's see how to do so in the next section.
When you've detected the user needs, it's time to begin analyzing the requirements. To do so, you can use techniques such as the following:
Figure 1.8: Use case diagram example
While you are analyzing the requirements of the system, you will be able to clarify exactly what the users' needs are. This is helpful when you're not sure about the real problem you need to solve, and is much better than just starting to program the system and hoping for the best. Time invested in requirements analysis is time invested in better code later.
After you finish the analysis, it's important to register it as a specification. The specification document can be written using traditional requirements, or user stories, which are commonly used in agile projects.
A requirements specification represents the technical contract between the user and the team. There are some basic rules that this document needs to follow:
Some additional information can help the team to understand the context of the project they are going to work on. Here are some tips about how to add useful information:
If you decide to write user stories, a good tip to follow is to write short sentences representing each moment in the system with each user, as follows:
As <user>, I want <feature>, so that <reason>
This approach will explain exactly the reason why that feature will be implemented. It's also a good tool to help you analyze the stories that are most critical, and prioritize the success of the project. They can also be great for informing the automated acceptance tests that should be built.
Detecting requirements is a task that will let you understand the software you are going to develop. However, as a software architect, you have to pay attention to more than just the functional requirements for that system. Understanding the non-functional requirements is important, and one of the earliest activities for a software architect.
We are going to look at this in more detail in Chapter 2, Non-Functional Requirements, but at this point, it's important to know that the principles of scalability, robustness, security, and performance need to be applied for the requirements gathering process. Let us look at each concept:
It is worth mentioning that all these concepts are requirements for the new generation of solutions that the world needs. What differentiates good software from incredible software is the amount of work done to meet the project requirements.
Once you have the specification written, it is time to confirm with the stakeholders whether they agree with it. This can be done in a review meeting, or can be done online using collaboration tools.
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 both the complete software or for a small part of it.
Defining a solution is not easy. Determining its technology increases the difficulty of doing so. 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 requirements. 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 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 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:
The focus of a technique like this one is to accelerate the process of detecting the right product, 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.
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 an alternative that allows you to quickly test and learn from an idea, needing to build and launch a solution to market.
The process is based on a week dedicated by experts to solve the problem mentioned, in a war room prepared for that purpose. The week is separated like this:
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.
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. This discussion is not related to developing by using traditional or agile methods, but focuses on building software professionally or as an amateur.
It's also a good idea to know about some cases where failing to perform the activities you read about caused some trouble for the software project. The following cases intend to describe what could go wrong, and how the preceding techniques could have helped the development team to solve the problems.
In most cases, simple action could have guaranteed better communication between the team and the customer, and this easy communication flow would have transformed a big problem into a real solution. Let's examine three common cases where the requirements gathering impacted the results of performance, functionality, and usability.
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. Besides, the cost of computation is still high, especially if you are talking about software with a high number of simultaneous users.
You cannot solve performance problems by writing requirements. However, you will not end up in trouble if you write them correctly. The idea here is that requirements must present the desired performance of a system. A simple sentence, describing this, can help the entire team that works on the project:
Non-functional requirement: Performance – any web page of this software shall respond in at least 2 seconds, even when 1,000 users are accessing it concurrently.
The preceding sentence just makes everybody (users, testers, developers, architects, managers, and so on) sure that any web page has a target to achieve. This is a good start, but it's not enough. A great environment to both develop and deploy your application is also important. This is where .NET 5 can help you a lot; especially if you are talking about web apps, ASP.NET Core is considered one of the fastest options to deliver solutions today.
If you talk about performance, you, as a software architect, should consider the use of the techniques listed in the following sections together with specific tests to guarantee this non-functional requirement. It's also important to mention that ASP.NET Core will help you to use them easily, together with some Platform as a Service (PaaS) solutions delivered by Microsoft Azure.
Caching is a great technique to avoid queries that can consume time and, in general, give the same result. For instance, if you are fetching the available car models in a database, the number of cars in the database can increase, but they will not change. Once you have an application that constantly accesses car models, a good practice is to cache that information.
It is important to understand that a cache is stored in the backend and that cache is shared by the whole application (in-memory caching). A point to focus on is that when you are working on a scalable solution, you can configure a distributed cache to solve it using the Azure platform. In fact, ASP.NET provides both, so you can decide on the one that bests fits your needs. Chapter 2, Non-Functional Requirements, covers scalability aspects in the Azure platform.
When you develop ASP.NET applications, you need to keep in mind that your app needs to be designed for simultaneous access by many users. Asynchronous programming lets you do this simply, giving you the keywords async
and await
.
The basic concept behind these keywords is that async
enables any method to run asynchronously. On the other hand, await
lets you synchronize the call of an asynchronous method without blocking the thread that is calling it. This easy-to-develop pattern will make your application run without performance bottlenecks and better responsiveness. This book will cover more about this subject in Chapter 2, Non-Functional Requirements.
One very good tip to avoid a lack of performance is to understand how the Garbage Collector (GC) works. The GC is the engine that will free memory automatically when you finish using it. There are some very important aspects of this topic, due to the complexity that the GC has.
Some types of objects are not collected by the GC if you do not dispose of them. The list includes any object that interacts with I/O, such as files and streaming. If you do not correctly use the C# syntax to create and destroy this kind of object, you will have memory leaks, which will deteriorate your application performance.
The incorrect way of working with I/O objects is:
System.IO.StreamWriter file = new System.IO.StreamWriter(@"C:sample.txt");
file.WriteLine("Just writing a simple line");
The correct way of working with I/O objects is:
using (System.IO.StreamWriter file = new System.IO.StreamWriter(@"C:sample.txt"))
{
file.WriteLine("Just writing a simple line");
}
It might be worth noting that this correct approach also ensures the file gets written (it calls Flush). In the incorrect example, the contents might not even be written to the file. Even though the preceding practice is mandatory for I/O objects, it is totally recommended that you keep doing this in all disposable objects. Indeed, using code analyzers in your solutions with warnings as errors will prevent you from accidentally making these mistakes! This will help the GC and will keep your application running with the right amount of memory. Depending on the type of object, mistakes here can snowball, and you could end up with other bad things at scale, for instance, port/connection exhaustion.
Another important aspect that you need to know about is that the time spent by the GC to collect objects will interfere with the performance of your app. Because of this, avoid allocating large objects; otherwise, it can cause you trouble waiting for the GC to finish its task.
One of the most common performance Achilles' heels is database access. The reason why this is still a big problem is the lack of attention while writing queries or lambda expressions to get information from the database. This book will cover Entity Framework Core in Chapter 8, Interacting with Data in C# – Entity Framework Core, but it is important to know what to choose and the correct data information to read from a database. Filtering columns and lines is imperative for an application that wants to deliver on performance.
The good thing is that best practices related to caching, asynchronous programming, and object allocation fit completely into the environment of databases. It's only a matter of choosing the correct pattern to get better-performance software.
The more that technology is used in a wide variety of areas, the more difficult it is to deliver exactly what the user needs. Maybe this sentence sounds weird to you, but you must understand that developers, in general, study how to develop software, but they rarely study to deliver the needs of a specific area. Of course, it is not easy to learn how to develop software, but it is even more difficult to understand a specific need in a specific area. Software development nowadays delivers software to all possible types of industries. The question here is how can a developer, whether a software architect or not, evolve enough to deliver software in the area they are responsible for?
Gathering software requirements will help you in this tough task; writing them will make you understand and organize the architecture of the system. There are several ways to minimize the risks of implementing something different from what the user really needs:
Again, as a software architect, you will have to define how the software will be implemented. Most of the time, you are not going to be the one who programs it, but you will always be the one responsible for this. For this reason, some techniques can be useful to avoid the wrong implementation:
Remember, the implementation matching the user needs is your responsibility. Use every tool you can to meet it.
Usability is a key point for the success of a software project. The way the software is presented and how it solves a problem can help the user to decide whether they want to use it or not. As a software architect, you must keep in mind that delivering software with good usability is mandatory nowadays.
There are basic concepts of usability that this book does not intend to cover, but a good way to meet the correct user needs when it comes to usability is by understanding who is going to use the software. Design Thinking can help you a lot with that, as was discussed earlier in this chapter.
Understanding the user will help you to decide whether the software is going to run on a web page, or a cell phone, or even in the background. This understanding is very important to a software architect because the elements of a system will be better presented if you correctly map who will use them.
On the other hand, if you do not care about that, you will just deliver software that works. This can be good for a short time, but it will not exactly meet the real needs that made a person ask you to architect the software. You must keep in mind the options and understand that good software is designed to run on many platforms and devices.
You will be happy to know that .NET 5 is an incredible cross-platform option for that. So, you can develop solutions to run your apps in Linux, Windows, Android, and iOS. You can run your applications on big screens, tablets, cell phones, and even drones! You can embed apps on boards for automation or in HoloLens for mixed reality. Software architects must be open-minded to design exactly what their users need.
As we mentioned at the beginning of this chapter, the case study of this book will take you on a journey of creating the software architecture for a travel agency called World Wild Travel Club (WWTravelClub).
WWTravelClub is a travel agency that was created to change the way people make decisions about their vacations and other trips around the world. To do so, they are developing an online service where every detail of a trip experience will be assisted by a club of experts specifically selected for each destination.
The concept of this platform is that you can be both a visitor and a destination expert at the same time. The more you participate as an expert in a destination, the higher the points you will score. These points can be exchanged for tickets that people buy online using the platform.
The customer came with the following requirements for the platform. It is important to know that, in general, customers do not bring the requirements ready for development. That is why the requirements gathering process is so important:
To finish this, it is important to note that WWTravelClub intends to have more than 100 destination experts per package and will offer around 1,000 different packages all over the world.
To summarize the user needs of WWTravelClub, you can read the following user stories:
US_001
: As a common user, I want to view promotional packages on the home page, so that I can easily find my next vacationUS_002
: As a common user, I want to search for packages I cannot find on the home page so that I can explore other trip opportunitiesUS_003
: As a common user, I want to see the details of a package, so that I can decide which package to buyUS_004
: As a common user, I want to register myself, so that I can start buying the packageUS_005
: As a registered user, I want to process the payment, so that I can buy a packageUS_006
: As a registered user, I want to buy a package with an expert recommendation included, so that I can have an exclusive trip experienceUS_007
: As a registered user, I want to ask for an expert, so that I find out the best things I can do on my tripUS_008
: As a registered user, I want to comment on my experience, so that I can give feedback from my tripUS_009
: As a registered user, I want to evaluate an expert who helps me, so that I can share with others how fantastic they wereUS_010
: As a registered user, I want to register as a destination expert view, so that I can help people who travel to my cityUS_011
: As an expert user, I want to answer questions about my city, so that I can score points to be exchanged in the futureUS_012
: As an expert user, I want to exchange points for tickets, so that I can travel around the world moreUS_013
: As an administrator user, I want to manage packages, so that users can have fantastic opportunities to travelUS_014
: As an administrator user, I want to manage registered users, so that WWTravelClub can guarantee good service qualityUS_015
: As an administrator user, I want to manage expert users, so that all of the questions regarding our destinations are answeredUS_016
: As an administrator user, I want to offer more than 1,000 packages around the world, so that different countries can experience the WWTravelClub serviceUS_017
: As the CEO, I want to have more than 1,000 users simultaneously accessing the website, so that the business can scale effectivelyUS_018
: As a user, I want to access WWTravelClub in my native language, so that I can easily understand the package offeredUS_019
: As a user, I want to access WWTravelClub in the Chrome, Firefox, and Edge web browsers, so that I can use the web browser of my preferenceUS_020
: As a user, I want to know my credit card information is stored securely, so I can buy packages safelyNotice that while you start writing the stories, information related to non-functional requirements such as security, environment, performance, and scalability can be included.
However, some system requirements may be omitted when you write user stories and need to be included in the software specification. These requirements can be related to legal aspects, hardware, and software prerequisites, or even points of attention for the correct system delivery. They need to be mapped and listed as well as user stories. The WWTravelClub system requirements are presented in the following list. Notice that requirements are written in the future because the system does not exist yet:
SR_001
: The system shall use Microsoft Azure components to deliver the scalability requiredSR_002
: The system shall respect General Data Protection Regulation (GDPR) requirementsSR_003
: The system shall run on the Windows, Linux, iOS, and Android platformsSR_004
: Any web page of this system shall respond in at least 2 seconds with a 1,000-user concurrently accessThe idea of having this list of user stories and system requirements is to help you understand how complex the development of a platform might be if you think about it from an architectural perspective.
In this chapter, you learned the purpose of a software architect in a software development team. Also, this chapter covered the basics of software development process models and the requirements gathering process. You also had the opportunity to learn about how to create your Azure account, which will be used during the case study of this book, which was presented to you in the previous section. Moreover, you even learned about functional and non-functional requirements and how to create them using user stories. These techniques will help you deliver a better software project.
In the next chapter, you will have the opportunity to understand how important functional and non-functional requirements are for software architecture.
Here, you have some books and links you may consider reading to gather more information about this chapter.
For Azure information, check these out:
.NET 5 information can be found here:
Software development process model links:
18.223.0.53