Let's start talking about requirements, analysis, and design. Useful questions to ask a Cloud architect to help build the requirements are who, what, why, when, and how. The who is about determining not only the user of the system, but also the developers and stake holders. The aim is to build a full picture of who the system will affect both directly and indirectly. The what is both simple and difficult, we need to establish the main areas of functionality required, but in a clear, unambiguous manner. Why the system is needed, is a really important question. What is a problem the proposed system aims to address or solve? Without a clear understanding of the need, it is likely that extra requirements will be added. The why will also potentially help in defining KPIs, and SLOs, and SLAs. When, helps determine a realistic timeline and can help contain the scope. How, helps to determine a lot of the non-functional requirements. These could be, for instance, how many users the system needs to support concurrently? What does the average payload size of service requests? Are there latency requirements, etc? They could be that the users will be located across the world or in a particular region only. All of these requirements are vital to capture, because they impact the potential solution you as a Cloud architect will provide. In the previous design activity, you defined user roles for your application. Roles represent the goal of a user at some point and they enable the analysis of a requirement in a particular context. It is important to note that a role is not necessarily a person, it is an actor on the system and it could be another system such as a microservice client that is accessing another microservice. The role should describe the user's objective when using the system. For example, the role of a shopper on an eCommerce application clearly defines what the user wants to do. There are many ways to determine the roles for the requirement you working on. One process that works particularly well is, first brainstorm an initial set of roles. Write as many roles as you can think of, with each role being a single user. Now, organize this initial set. Here, you can identify overlapping roles and related roles, and group these together. With the set of roles now grouped, consolidate the roles, the aim here is to consolidate and condense the roles to remove duplication. Finally, refine the roles including internal and external roles, and the different usage patterns. Here, extra information can be provided, such as the user's level of expertise in the domain or the frequency of use of the proposed software. Following a simple process like this, provide structure and brings focus to the task. Identifying user roles is a useful technique that's part of the requirements getting process. An additional technique, in particular for more important roles can be to create a persona for the role. A persona is an imaginary representations of a user role. The aim of the persona is to help the architect and developers think about the characteristics of users by personalizing them. Often, a role has multiple personas. Consider the example of requirements for a banking application. We can think in terms of users of the system and many requirements can be gathered this way. Using personas can provide further insights. For example, Jocelyn is a person who's a busy working mom. Jocelyn wants to save time and money as well as perform these standard banking operations online and receive benefits such as cashback. Using a persona helps build a fuller picture of the requirements. For instance, Jocelyn's wanting to save time indicates that the task to be performed should possibly be automated, which affects latency hence service design. In this example, when a question rises from the architect or maybe a developer, they can often better answer that question by thinking, what would Jocelyn want here? Now, user stories describe one thing a user wants the system to do, they are written in a structured way typically using the form as a, type of user, I want to do something so that I can get some benefit. Another commonly used form is given some context, when I do something, then this should happen. So when writing stories, give each story a title that describes its purpose as a starting point, follow this with a concise, one-sentence description of the story that follows one of the forms just described. This form describes the user role, what they want to do and why they want to do it. As an example, consider a banking system and a story to determine the available balance of a bank account. The title of the story could be balance inquiry. Then following the template we described the story as an account holder, I want to check my available balance at any time of day, so I am sure not to overdraw my account. This explains the role, what they want to do and why they want to do it. User stories provide a clear and simple way of agreeing to requirements with a customer/end-user. The invest criteria can be used to evaluate good user stories. Let me go through each letter of these criteria. Independent, a story should be independent to prevent problems with prioritization and planning. Negotiable, they are not written contracts, but are used to stimulate discussion between customer and developers until there is a clear agreement, they add collaboration. Valuable, story should provide value to users. Think about outcomes and impact, not outputs and deliverables. Estimatable, the story must be estimatable. If it is not, it often indicates missing details or the story is too large. Small, good stories should be small, this helps keep scope small and therefore less ambiguous and supports fast feedback from users. Testable, stories must be testable so that developers can verify that the story has been implemented correctly and validate when requirement has been met slash/is done.
