SRS überarbeiten

--- tags: SRS --- # SRS überarbeiten __Syntax__ W1: Nicht so wichtig W2: Mittelwichtig W3: Wichtig --- Existing Systems: Are there Similar systems, does the client already have something to build on. Overview? ``` W2 __TODO:__ Jason ``` Requirements: Check the requirements for completeness, consistency of wording, if the terms are clear and that it is clear what the requirements describe. Ensure that requirements are self-contained (that it is clear what each term means/refers to by only reading that specific requirement), or that it is clear by the grouping to what they refer. If you group the requirements using a numbering scheme, target only the same topic in one group, e.g. one group for login, one group for user selection, … e.g.: • For “/FR-1-6-8/ The user can access a searchable list of people (display name and display picture)” this can be improved to add “ it can be clarified that this is to search companions. ``` W2 TODO:Niko ``` Use-Cases: Ensure that you have consistent namings in the Diagram, Use-Cases and Tests. E.g. you are using both “Signing out” and “logout” Ensure that the Use-Cases match the Tests. You should especially take a close look at your Admin Use-Cases your e.g. describe a Login Test, but you don’t have a Login use-case for the Admin, which is part of “Downloading recorded data and consent forms via web interface” and should be split and an entry condition to log in, but again no login process. In general, try to organize your use cases by sub-system (app/website/ server) and according to the normal flow of the use. In the case of the app, the user would first sign-in, accept the consent form, fill questionnaires, etc. This order makes it easier for other readers to understand your work and makes the specification document clearer. The verbs chosen for the use case should match the participating actor(s). Nuance is important when writing a specification document. Example: Collect mood = when reading this use case name, you would imagine that the system collects the mood Input mood = when reading this use case name, you would imagine that the user inputs the mood In general, try to go in detail with the flow of events ``` W2 TODO:Felix ``` Class Diagram: Check if the Class diagram might miss parts like e.g. UI. ``` W2 TODO:Ela ``` UI-Prototype: You should check if the prototypes of your UI are complete like e.g. inviting. And also add prototypes related to the UI of the Admin (web). ``` W1 TODO:Noah ``` Test-Cases: Ensure that there is no conflicting information in the Test: e.g. 6.4.1.3 and 6.4.1.4 what is the difference between “Email and hashed and salted password stored locally.” and “The system will save the email, hashed and salted password” For 6.4.3.2 exit conditions would be “Password not changed”. Check if you are missing any entry or exit conditions and if they are correct. ``` W2 TODO:Jason ``` Make sure that each requirement or use case is covered by a Test-Case. ``` W2 TODO:Tilman ```