In this lesson, we will discuss how the software requirements and the desired quality can be met by creating a good software architecture. To be able to validate if the desired quality was met, we need to define what we mean by the term quality in this context of software architecture. There are many definitions of quality, but during this class, we will define it as value as perceived by the user or customer. So in order to meet a desired quality, you need to understand the user's or customer's vision on the project, but also how they will measure it.. By making the requirements measurable and testable, it is clear for everyone whether the requirements are met or not. Defining requirements in a measurable and testable way that is clear for everyone is a not a simple task. You cannot simply say it needs to be fast because fast can mean something different for you than for me. We will need some sort of common language to document the different requirements and their measures. Each of the different types of requirements will be written down in the most suitable way. Since documenting functional requirements is very common in software projects, we will assume that you know how to do this and only give a short recap on the topic. Functional requirements are best described with use cases or scenarios in which you describe the functionality as seen from a user's perspective. We make a distinction between use cases, which contain a summary of features and specific scenarios which define one specific set of actions in a certain order. A use case for an e-commerce system could be a user needs to be able to pay. And the scenario can describe the specific steps a user needs to take to pay with his credit card. Use cases can be described textually with user stories. User stories are short and simple descriptions written from the point of view of the person who requests the new capability. It usually follows the template where you define the type of user this user story is applicable to, the functionality that this user would like to have or a task that he wants to be able to accomplish, and the reason he wants this functionality to be available. An example in an Internet of Things context could be as a homeowner I want my thermostat to be linked to my GPS system so that my house is warm when I arrive at home. There can be multiple user stories for a single use case. A use case diagram shows the relationships between different use cases and the actors which are the roles of the users. On this example of an online auction site, you see three actors, the buyer, the seller and a generic user who can have one of the roles or both. Each use case is linked to the role for which it applies. Use cases can be linked to each other as well. A use case diagram is a specific UML type diagram. In this course, we will use UML version 2.0. Different versions of UML have different syntaxes, and it is important that you do not combine syntaxes of different versions in one diagram, since this causes a lot of confusion. You can easily make UML diagrams with tools like Microsoft Visio, Visual Paradigm, or the Google Drive plug-in, draw.io. Scenarios are described as a textual step by step explanation of the main success scenario, after which exceptions for specific situations or errors are described. Mock-ups or screenshots can be used as visual support for the textual description. Nonfunctionals are often written down in plain text as an extension to a specific scenario or use case, like don't forget the security, or it has to be scalable. These are vague and ambiguous terms, which are of no use when you want to evaluate whether these requirements are met. We prefer to use quality attributes and quality attribute scenarios. Quality attributes are measurable and testable properties of the system that are used to indicate how well the system satisfies the needs of the stakeholders. Several examples are modifiability to make sure the system is easily adaptable to the changing needs of the user, or performance to make sure your website can return the results to the user within two seconds. Quality attribute scenarios are a generic structure to write these requirements down in a measurable and testable way. A good quality attribute scenario is measurable, and a post-field test can be created for it. A quality attribute scenario for modifiability can be the following. A developer wishes to change the user interface at design time. The changes are made to the code and this code is unit tested within three hours. Business requirements and constraints have no specific structure and are mostly written down in plain text or bullet points. In this class, we are mainly going to focus on the quality attributes although other requirements will be used during the process as well. Together with the other requirements, they are used as input for the attribute driven design process which will help us to generate a software architecture that meets these requirements. This process uses patterns and tactics which are generic ways to solve common software design problems. In this lesson, we focus on documenting the requirements to achieve a qualitative piece of software, but quality cannot be achieved by architecture alone. It needs to be taken into account in the entire software life-cycle, which means from design, over implementation, to deployment and maintenance. However, the architecture of the software is critical to support this process and to ensure that the requirements can be met in the later phases. A well-thought architecture can prevent problems like unforeseen networking delays which can occur when data needs to be passed to several servers in order to be processed
