Krav

Krav/Requirements er features/funktionaliteter i en applikation skal have.

Når man formulerer krav, er det vigtigt at de er:

• Klart - krav skal være konkrete og nemme at forstå.
• Entydig - krav skal være entydige (tydelige), så de ikke kan misforstås.
• Prioritet - krav skal kunne prioriteres.
• Verificerbar - krav skal kunne verificeres.

Der er derudover også forskellige typer af krav

• Business requirements er high-level mål, som fortæller hvad kunden ønsker at opnå med et projekt.
• User (stakeholder) requirements er krav, som beskriver, hvordan et projekt vil blive brugt af brugerne.
• Functional requirements er detaljeret krav af projektet funktionliteter.
• Nonfunctional requirement er udtalelser omkring kvalitet/regler af applikationen.
• Implementation requirements er midlertidige features, som er nødvendig mellem skiftning fra et gammelt system til et nyt system.

Kravindsamling

Krav kan indsamles på mange forskellige måder:

• 5W1H
• User stories
• User cases
• Moscow
• FURPS(+)
• Brainstorm (solo)
• interviews

Typiske krav for en applikation

• Screens - What screens or forms are needed?
• Menus - What menus will the screens have?
• Navigation - How will the users navigate through different parts of the system? Will they click buttons, use menus, or tap forward and backward arrows? Or some combination of those methods?
• Workflow - How does data (work orders, purchase requests, invoices, and other data) move through the system?
• Login - How is login information stored and validated? What are the password formats (such as, must require at least one letter, number, special character, and emoji) and rules (as in, passwords must be changed monthly)?
• User types - Are there different kinds of users such as order entry clerk, shipping clerk, supervisor, and admin? Do they need different privileges?
• Audit tracking and history - Does the system need to keep track of who made changes to the data? (For example, so you can see who changed a customer to premier status or gave a 99 percent discount.)
• Archiving - Does the system need to archive older data to free up space in the live database? Does it need to copy data into a data warehouse for analysis?
• Configuration - Should the application provide configuration screens that let the system administrators change the way the program works? For example, those screens might let system administrators edit product data, set shipping and handling prices, and set algorithm parameters. (If you don’t build these sorts of screens, you’ll have to make those changes for the customers later.)