Skip to content

Commit

Permalink
Update 01_introduction_and_goals.adoc
Browse files Browse the repository at this point in the history
  • Loading branch information
AlvaroGlezC authored May 11, 2024
1 parent 8c4cb3e commit b139b1b
Showing 1 changed file with 46 additions and 56 deletions.
102 changes: 46 additions & 56 deletions docs/src/01_introduction_and_goals.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -5,89 +5,79 @@ ifndef::imagesdir[:imagesdir: ../images]

[role="arc42help"]
****
Describes the relevant requirements and the driving forces that software architects and development team must consider.
These include
* underlying business goals,
* essential features,
* essential functional requirements,
* quality goals for the architecture and
* relevant stakeholders and their expectations
WIQ is an application based on the Spanish television game show "Saber Y Ganar", where each of the users will be able to test their knowledge with multiple questions of all kinds.
SYG is the name of the application, where you can interact with the game itself, as well as with different extra functionalities of the web, such as consulting your game history, rankings, etc.
It follows the SOLID principles, guaranteeing the privacy of the client's personal data.
****

=== Requirements Overview

[role="arc42help"]
****
.Contents
Short description of the functional requirements, driving forces, extract (or abstract)
of requirements. Link to (hopefully existing) requirements documents
(with version number and information where to find it).
Requirements document:
.Motivation
From the point of view of the end users a system is created or modified to
improve support of a business activity and/or improve the quality.
English: https://docs.google.com/document/d/12FImFOHdogzXX0ZMeAlaWkCwXMxGtCp6U-XYHk4aV64/edit
.Form
Short textual description, probably in tabular use-case format.
If requirements documents exist this overview should refer to these documents.
Spanish: https://docs.google.com/document/d/1pahOfYFY--Wi7_9bbxiKOGevB_9tOSyRm78blncgBKg/edit#heading=h.knuq2aw7zapd
Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
* The system will have at least a web front-end which will be available and accessible through the web.
.Further Information
* Users will be able to register to the system and obtain the historical data from their participation: number of games, questions passed and failed, times, etc.
See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation.
* Questions will be automatically generated from data available in Wikidata.
****
* Questions have to be answered before some specific time.
=== Quality Goals
* Each question will have one right answer and several incorrect ones or distractors. Both the right answer and the distractors should be automatically generated.
[role="arc42help"]
****
.Contents
The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders.
We really mean quality goals for the architecture. Don't confuse them with project goals.
They are not necessarily identical.
* The system will give access to the information about the users through an API.
* The system will give access to information about the generated questions through an API.
* The system can contain different subjects about the questions and the users can choose between one of those subjects that they will answer.
* Enable internationalization and generate questions in different languages.
Consider this overview of potential topics (based upon the ISO 25010 standard):
* Create a users ranking where they are ordered according to different metrics (percentage of passed questions, number of passed questions, number of games, etc.).
image::01_2_iso-25010-topics-EN.drawio.png["Categories of Quality Requirements"]
* Allow the user to adjust different game parameters: time to answer, number of questions, scope (e.g. European cities, Spanish cities…).
.Motivation
You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions.
Make sure to be very concrete about these qualities, avoid buzzwords.
If you as an architect do not know how the quality of your work will be judged...
* Create a system that generates the questions or the answers text in a way that is always different using.
.Form
A table with quality goals and concrete scenarios, ordered by priorities
****

=== Stakeholders
=== Quality Goals

[role="arc42help"]
****
.Contents
Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that
* should know the architecture
* have to be convinced of the architecture
* have to work with the architecture or with code
* need the documentation of the architecture for their work
* have to come up with decisions about the system or its development
.Motivation
You should know all parties involved in development of the system or affected by the system.
Otherwise, you may get nasty surprises later in the development process.
These stakeholders determine the extent and the level of detail of your work and its results.
.Form
Table with role names, person names, and their expectations with respect to the architecture and its documentation.
[options="header",cols="1,2,2"]
|===
|Priority |Quality Goal|Motivation
|1| Efficiency | Making a purchase should be easy for the user, reducing response and load times
|2| Usability | All users must be able to use it, whether they have previous knowledge about the application or not
|3| Security | The treatment of private information will be decentralized, ensuring customer privacy
|4| Modifiability | The architecture must be easy to modify, adding new features or changing existing ones
|5| Testability | Major components should be easily tested and fixed
|===
Detailed priority in epigraph 10.
****

=== Stakeholders

[role="arc42help"]
****
[options="header",cols="1,2,2"]
|===
|Role/Name|Contact|Expectations
| _<Role-1>_ | _<Contact-1>_ | _<Expectation-1>_
| _<Role-2>_ | _<Contact-2>_ | _<Expectation-2>_
| Client | They interact directly with the application. They are the players of our application, answer the questions generated for the different categories and visualise all kinds of results. | The aim is that the customer can interact with the application in an intuitive way and have a comfortable gaming experience. In addition to securing their account so that no one else can play for them.
| Development Team | They are the creators of the application. They can modify, update and improve it. | Develop a complete application that contain the requirements. Learn to work in a team efficiently and learn new technologies.
|Product managers|They are responsible for defining the vision and strategy of the application, as well as prioritising features and functionalities.| Define the strategy and vision to be followed by the development team and prioritise the most important functionalities.
|Managers and directors|Involved in strategic decision-making, resource allocation and overall project oversight.| Supervise that the project and the application meet the required requirements
|===
****

0 comments on commit b139b1b

Please sign in to comment.