generated from Arquisoft/wiq_0
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
First release
- Loading branch information
Showing
6 changed files
with
366 additions
and
194 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,95 +1,148 @@ | ||
| ifndef::imagesdir[:imagesdir: ../images] | ||
|
|
||
| [[section-introduction-and-goals]] | ||
| == Introduction and Goals | ||
|
|
||
| [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 | ||
| **** | ||
|
|
||
| === 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). | ||
| .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. | ||
| .Form | ||
| Short textual description, probably in tabular use-case format. | ||
| If requirements documents exist this overview should refer to these documents. | ||
| Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents. | ||
| .Further Information | ||
| See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation. | ||
| **** | ||
|
|
||
| === Quality Goals | ||
|
|
||
| [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. | ||
| Consider this overview of potential topics (based upon the ISO 25010 standard): | ||
| image::01_2_iso-25010-topics-EN.drawio.png["Categories of Quality Requirements"] | ||
| .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... | ||
| .Form | ||
| A table with quality goals and concrete scenarios, ordered by priorities | ||
| **** | ||
|
|
||
| === Stakeholders | ||
|
|
||
| [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"] | ||
| |=== | ||
| |Role/Name|Contact|Expectations | ||
| | *Students* | Andrés Cadenas Blanco, Christian Fernandez Noriega , Adrián González Guadalupe and Luis Salvador Ferrero | Are the ones in charge of web development. They will work together to make the application. | ||
| | *Teachers* | Pablo González | In charge of supervising the student's teamwork, ensuring the work accomplishes the goals in the best way possible and helping in the development and solving doubts. | ||
| | *Bussineses* | RTve has hired software development company HappySw | Emphasis the SOLID part of the web and have a high understanding of this area | ||
| | *Users* | Anyone that wants to use the web | They should be able to understand how to use and move around the web with ease | ||
| |=== | ||
|
|
||
| ifndef::imagesdir[:imagesdir: ../images] | ||
|
|
||
| [[section-introduction-and-goals]] | ||
| == Introduction and Goals | ||
|
|
||
| [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 | ||
| **** | ||
| In these points, the main goals and functional requirements will be explained. In order to give context on how the webapp will be developed. | ||
|
|
||
| === 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). | ||
| .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. | ||
| .Form | ||
| Short textual description, probably in tabular use-case format. | ||
| If requirements documents exist this overview should refer to these documents. | ||
| Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents. | ||
| .Further Information | ||
| See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation. | ||
| **** | ||
| The functional requirements have been grouped into the different microservices the web application will have. | ||
| ==== User and Authorization Services | ||
| [decimal] | ||
| . The User service allows the user to | ||
| [arabic] | ||
| .. Register. | ||
| .. Delete the account. | ||
| .. Update the account. | ||
| .. Recover the password. | ||
| . The authorization service allows the user to | ||
| [arabic] | ||
| .. Log in. | ||
| .. Log out. | ||
| . A user can retrieve the following information from the User service | ||
| [arabic] | ||
| .. Name. | ||
| .. Email. | ||
| .. Profile picture. | ||
| .. Questions answered. | ||
| . The system must be able to manage the user's access to the system. | ||
|
|
||
| ==== Question Service | ||
| [decimal, start=5] | ||
| . The Question service retrieves questions generated from wikidata. | ||
| . A user can retrieve the following information from the Question service | ||
| [arabic] | ||
| .. Select a category. | ||
| .. Select a difficulty. | ||
| .. Select a question. | ||
| .. Select an answer. | ||
| . Questions must be stored in a database. | ||
| . The database used is MongoDB. | ||
| . Questions are classified by | ||
| [arabic] | ||
| .. Category. | ||
| .. Difficulty. | ||
| . The questions should be selected randomly. | ||
| === Quality Goals | ||
|
|
||
| [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. | ||
| Consider this overview of potential topics (based upon the ISO 25010 standard): | ||
| image::01_2_iso-25010-topics-EN.drawio.png["Categories of Quality Requirements"] | ||
| .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... | ||
| .Form | ||
| A table with quality goals and concrete scenarios, ordered by priorities | ||
| **** | ||
| [options="header", cols="1,1"] | ||
| |=== | ||
| | Goal | Description | ||
| | Testability |Test will be developed, so the application has a good quality. | ||
|
|
||
| | Usability | The application has to be intuitive for its users. | ||
|
|
||
| | Portability | The application works in different devices and browsers. With different screen sizes. | ||
|
|
||
| | Performance | The application can handle a big number of users and give good response times. | ||
|
|
||
|
|
||
|
|
||
| |=== | ||
|
|
||
| === Stakeholders | ||
|
|
||
| [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"] | ||
| |=== | ||
| |Role/Name|Contact|Expectations | ||
| | *Students* | Andrés Cadenas Blanco, Christian Fernandez Noriega , Adrián González Guadalupe and Luis Salvador Ferrero | Are the ones in charge of web development. They will work together to make the application. | ||
| | *Teachers* | Pablo González | In charge of supervising the student's teamwork, ensuring the work accomplishes the goals in the best way possible and helping in the development and solving doubts. | ||
| | *Bussineses* | RTve has hired software development company HappySw | Emphasis the SOLID part of the web and have a high understanding of this area | ||
| | *Users* | Anyone that wants to use the web | They should be able to understand how to use and move around the web with ease | ||
| |=== | ||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.