Repository navigation
Requirements
bparlaker edited this page Oct 13, 2026
·
3 revisions
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)
- FR-8.1 Logged-in users can comment on an entry. (Could)
- 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.
- Domain Model: categories, craft types, attributes and the Kilim example
- Use Cases: use cases, diagrams and user stories
- Mockups: 3 screens
🎨 Term Project
📘 Git
🗂 Project workflow