Group Presentation - Architecture Review Board

Introduction

In this assignment, you will report to an Architecture Review Board (ARB) on your requirements engineering findings. An architecture review board is a governance body that ensures that projects align with company objectives and overall architecture framework.

As a team, you will roleplay the mind of a software architect. You will demonstrate your communication skills with the “other stakeholders”. In Part 1, your TA will roleplay all relevant “other stakeholders”. In Part 2, your TA will act as the architecture reviewer.

Part 0: Read the project overview

Get familiar with the project you are working on. For this assignment, we can assume that all functional requirements are listed and we do not need to discover new functional requirements with the client.

Your TA will be sending you a link to the project overview in your Slack channel. Please do not share this with anyone outside of your team.

Part 1: Requirements Engineering (10%)

Due Date: Meeting must be done by October 11th

To determine the necessary non-functional requirements and come to a place to make informed decisions about associated tradeoffs, you must perform requirement engineering.

In this part, you must schedule a 15-minute meeting with your TA to ask questions about the scenario. The goal of this meeting is to obtain enough information so that you can make informed decisions without any assumptions.

Although you may be inclined to assume certain things about the scenario, it is important to know that we should lean on our team to make business decisions while we make important technical decisions.

Each person must have an equal speaking opportunity.

Part 2: Architecture Review Board (10%)

Due Date: Meeting must be done by October 18th

After collecting the information you need in Part 1 and making decisions as a team, you must schedule a 15-minute ARB meeting with your TA.

At the minimum, you must cover the following (10 minutes):

• Load Estimation
• Availability timeframe & technique to measure availability
• Consistency vs Availability vs Partition Tolerance
• Trade-offs you’ve made in your architecture
• Method for handling server failures
• Strategy in rolling out the next release
• Any additional NFR considerations

Hint 1: None of your content must be based on your assumptions. It must be backed by what you do in Part 1. How you do in Part 1 will significantly affect your mark in Part 2.

Hint 2: Think of the personas involved for each of the questions above. For example, in load estimation, would 2 personas have different access patterns?

Each person must have an equal speaking opportunity.

TAs will be asking questions if clarification is required (5 minutes).

Individual Grading

Although this is a group presentation, each team member will receive an individual grade. Please introduce yourself before starting.

For moderation purposes, both parts will be recorded.