Requirements - bparlaker/cmpe-git-practice GitHub Wiki

Requirements

How to read this page

Every requirement has an ID (for example FR-3.2). Issues, use cases and user stories refer to these IDs.
Priority uses MoSCoW: Must have, Should have, Could have (only if time allows).
Main idea from class: every craft entry is entered as structured data through the fields of its craft type, not as free text. See Domain Model.

FR-1.1 A visitor can register with a username, an e-mail address and a password. (Must)
FR-1.2 A registered user can log in and log out. (Must)
FR-1.3 Each user has a profile page that lists their craft entries and the craft types they defined. (Should)

FR-2.1 The system has a category tree with 3 levels: Domain > Family > Craft Type. The admin manages levels 1 and 2. (Must)
FR-2.2 The system comes with predefined craft types (at least Kilim, Ebru, Çini and Miniature). Each has a set of attribute definitions. (Must)
FR-2.3 A registered user can define a new craft type: its name, its level 2 category and its attribute definitions. (Should)
FR-2.4 Each attribute definition has a name, a data type (measurement, single choice, multiple choice, year or period, location, yes or no), a unit for measurements, a list of allowed values for choices, and a required flag. (Must)
FR-2.5 While a user types a new craft type or attribute name, the system suggests existing names that differ by at most 2 letters (ignoring case and Turkish characters), to avoid duplicates. (Should)

FR-3.1 A logged-in user can add a craft entry by choosing a craft type and filling in that type's attributes. Required attributes must be filled. (Must)
FR-3.2 A user cannot add extra fields to an entry. Only the attributes defined by the craft type are shown; new fields can only be added by defining or editing a craft type (FR-2.3). (Must)
FR-3.3 Measurements are entered with a unit from an allowed list (for example cm or m, g or kg). The system stores a base unit and converts for display. (Must)
FR-3.4 An entry can have multiple colors (from a fixed palette) and multiple patterns (from the craft type's pattern list). (Must)
FR-3.5 Background information is structured: making technique, materials, culture or community, place of origin, production period and use are all chosen from lists or entered as measurements, years or locations. (Must)
FR-3.6 The only free text field is the personal story of the entry. (Must)
FR-3.7 An entry has one or more images. Under each image, the key attributes (size, colors, material, production place) are shown as a caption. (Should)
FR-3.8 A user can edit or delete only their own entries. (Must)
FR-3.9 Everyone can view an entry's detail page. (Must)

FR-4.1 The system has a list of predefined tags. (Must)
FR-4.2 A user can add a new tag if no existing tag fits. (Should)
FR-4.3 While typing a tag, the system suggests existing tags and offers a spelling correction ("Did you mean ...?"). (Should)

FR-5.1 A user sets the production place of an entry by placing a pin on a map or by searching a place name. (Must)
FR-5.2 Everyone can see entries on a map and open one by clicking its pin. (Should)

FR-6.1 Users can browse entries through the category tree. (Must)
FR-6.2 Users can filter entries by attribute values, for example color, pattern, material or a size range. (Should)
FR-6.3 Users can search entries by keyword in titles, craft type names and tags. (Must)

FR-7.1 A logged-in user can report an entry, a craft type or a tag as wrong or meaningless, choosing a reason from a list. (Must)
FR-7.2 Reports go only to the admin. They are not shown publicly and do not change the content automatically. (Must)
FR-7.3 The admin can review a report and then edit, hide or delete the reported content, or dismiss the report. (Must)

NFR-1 The site is deployed and can be reached from a public URL. (Must)
NFR-2 Pages work on desktop and mobile browsers. (Must)
NFR-3 Passwords are stored hashed. (Must)
NFR-4 Images must be JPG or PNG and at most 5 MB. (Should)
NFR-5 The app runs locally with Docker by following the README. (Should)
NFR-6 95% of main page loads finish in under 3 seconds, measured with the browser's network tab. (Could)
NFR-7 Core features have automated tests. (Should)
NFR-8 All entry data except the personal story is stored in structured, machine-readable form and can be exported as JSON. (Should)

Validation asks: are we writing the right thing? I checked two things:

Is every requirement linked to a use case, a user story and, if possible, a mockup?
Is every requirement clear, testable and free of contradictions?

FR-1.1 to FR-1.3 (accounts): UC-01, US-01
FR-2.1, FR-2.2 (categories, predefined types): UC-02, UC-04, US-02, US-07, mockup M1
FR-2.3 to FR-2.5 (user-defined craft types): UC-07, US-05, mockup M3
FR-3.1 to FR-3.6 (structured entry): UC-04, US-02, mockup M1
FR-3.7, FR-3.9 (entry detail and caption): UC-05, US-04, mockup M2
FR-3.8 (edit or delete own entry): UC-06, no user story yet
FR-4.1 to FR-4.3 (tags): UC-08, US-06, mockup M1
FR-5.1, FR-5.2 (location): UC-04, UC-05, US-03, US-04, mockups M1 and M2
FR-6.1 to FR-6.3 (browse and search): UC-02, UC-03, US-07, US-08
FR-7.1 to FR-7.3 (reporting): UC-09, UC-10, US-09, US-10, mockup M2
FR-8.1 (comments): no use case, no user story

FR-2.5 was vague ("similar names" by what rule?). Fixed: names that differ by at most 2 letters, ignoring case and Turkish characters.
NFR-6 was not measurable ("normal connection"). Fixed: 95% of page loads under 3 seconds, measured with the browser's network tab.
FR-2.3 and FR-3.2 looked like a contradiction (users can define fields, but cannot add fields). Fixed: new fields are added only in a craft type definition, never in an entry.
FR-3.8 has no user story. It is small and not part of the prototype, so the story will be written later.
FR-8.1 (comments) has no use case. It stays a Could; it may be out of scope this term.