Binnen het vakgebied van requirements engineering wordt onderscheid gemaakt tussen functionele requirements en niet-functionele requirements:

1. Functionele requirements: requirements die de vereiste werking beschrijven van een systeem; het door een systeemfunctie uit te voeren gedrag.

2. Niet-functionele requirements: requirements die de manier beschrijven waarop het systeem deze werking moet aanbieden.

Volgens Cannegieter, De Swart en Zandhuis gaan functionele requirements gaan over het gewenste gedrag van het systeem. Ze definiëren functionaliteit als de mogelijkheden die het systeem moet bieden zoals gesteld in de functionele requirements. Een rammelende definitie omdat een systeem blijkbaar alleen functionaliteit kan bieden zodra er een functionele requirement aan ten grondslag ligt. Lijkt een kip-ei-discussie, maar functionaliteit is m.i. niets anders dan een de 'werkzaamheid' van een systeem: het systeem is, wat het systeem doet!

Cannegieter, De Swart en Zandhuis definiëren niet-functionele requirements als de kwaliteitseisen of beperkingen voor een systeem: hoe moet het beoogde systeem haar functionaliteit aanbieden. Een kwaliteitseis betreft een kwaliteitseigenschap die niet door de functionele requirements wordt afgedekt. Een beperking gaat over de oplossingsruimte in aanvulling op de functionele en kwaliteitsrequirements. Beperkingen kun je - in tegenstelling tot functionele requirements en kwaliteitseisen niet implementeren. Ze beperken alleen de oplossingsruimte (en daarmee het ontwikkelproces) en verkleinen daarmee de bewegingsvrijheid van de ontwikkelaars. Een voorbeeld van een beperking is bijvoorbeeld dat het systeem gebruik moet maken van een Oracle-database.

Volgens Agterbosch, Raemakers, Tijdink e.a. is het ontbreken van nadrukkelijke aandacht voor niet-functionele requirements een vaak voorkomend punt van zorg bij opdrachtgevers, "met name als ze de consequenties ervan ondervinden. Juist de niet-functionele requirements kunnen doorslaggevend zijn voor de keuze van de uiteindelijke oplossingsrichting.

De bekendste classificering van kwaliteitsrequirements is die van ISO/IEC 25010. De belangrijkste aandachtspunten bij het opstellen van de kwaliteitsrequirements zijn: beveiiligbaarheid, functionele correctheid, betrouwbaarheid (bedrijfszekerheid, fouttolerantie en herstelbaarheid), bruikbaarheid, efficiënte werking van het systeem (snelheid, middelenbeslag), de onderhoudbaarheid (analyseerbaarheid, aanpasbaarheid en testbaarheid van de software), en de overdraagbaarheid van het systeem (aanpasbaarheid, installeerbaarheid, vervangbaarheid.

Bron:

• Succes met opdrachtgeverschap! Tips voor ICT opdrachtgeverschap en regievoering, Olaf Agterbosch, Wouter Raemaekers, Ton Tijdink, e.a.
• Grip op requirements - IREB foundation examenstof uitgelegd en praktisch gemaakt, Jan Jaap Cannegieter, Nicole de Swart, Johan Zandhuis

Linda Westfall beschrijft aan de hand van vijf basale vragen de essentie van requirements (engineering).

1. Wat, verschillende niveaus en soorten requirements.

2. Waarom, voordelen van goede requirements.

3. Wie , belanghebbenden bij requirements.

4. Wanneer, momenten waarop verschillende activiiteiten rond requirements plaatsvinden

5. Hoe, technieken voor het eliciteren, analyseren, specificeren en valideren van requirements

Schematisch kunnen de door Westfall onderkende niveaus en soorten requirements (afgeleid van Karl E. Wiegers) als volgt worden weergegeven:

Westfall definieert bedrijfsregels (business rules) als specifiek beleid, standaarden, prakijken, regels en richtlijnen die vastleggen hoe gebruikers moeten werken (do business) en positioneert ze (dus) op hetzelfde niveaus als de user requirements. Het systeem moet zich houden aan deze regels om goed te functioneren binnen het gebruikersdomein.

Westfall onderscheidt kwaliteitsatributen op twee niveaus: gebruikers en product. Op het niveau van gebruikers zijn de kwaliteitsattributen de niet-functionele kenmerken die de productkwaliteit van het systeem definiëren, zoals betrouwbaarheid, beschikbaarheid. Een kwaliteitsattribuut op gebruikersniveau kan zich op productniveau vertalen naar zowel een functioneel requirement (functionaliteit nodig om te voldoen aan het niet-functionele kwaliteitsattribuut) als een niet-functioneel requirement (eigenschappen nodig die het systeem moet hebben).  Ze noemt hierbij de volgende voorbeelden: "an ease of learning requirement might translate into the functional requirement of having the system display pop-up help when the user hovers the cursor over an icon" en "an ease-of-use requirement might translate into nonfunctional requirements for response time to user commands or report requests."

Het is mogelijk dat een kwaliteitsattribuut op gebruikersniveau vertaald moet worden naar functionele requirements op productniveau: er is specifieke functionaliteit nodig om te voldoen aan de niet-functionele kwaliteitsattributen.

Met de externe interface requirements kunnen de eisen worden vastgelegd voor het uitwisselen van informatie met gedeelde interfaces die buiten de grenzen vallen van het te ontwikkelen systeem.

De constraints definiëren welke beperkingen er zijn bij het maken van keuzes voor wat betreft het ontwerp en de ontwikkeling van het systeem.

Er kunnen ook zgn. data requirements van toepassing zijn voor specifieke gegevensvelden of -structuren.

Bron: Software Requirements Engineering: What, Why, Who, When and How (Linda Westfall)

In het artikel Veel gebruikte requirementsprocessen geeft Nicole de Swart een overzicht van een aantal verschillende processen voor requirements. Bovenstaande schema is de workflow voor het opstellen van requirements binnen RUP (Rational Unified Process) wordt bovenstaan

Bron: Veel gebruikte requirementsprocessen, Nicole de Swart

Bron: Veel gebruikte requirementsprocessen, Nicole de Swart

In de Checklist requirements engineering beschrijft - Tmap-goeroe - Erik Van Veenendaalde requirements engineering als combinatie van de processen requirementengineering en requirementsmanagement. Requirementsontwikkeling definieert hij als het proces dat gericht is op het afleiden en analyseren van de behoeften van de belanghebbenden en het vertalen van deze behoeften naar gespecificeerde producteisen. Dit proces bestaat - in hoofdlijnen - uit vier stappen:

1. Requirementselicitatie: het communiceren met klanten en gebruikers om te bepalen wat hun behoeften en vereisten zijn, en dit vertalen in requirements.

2. Requirementsanalyse: bepalen in welke mate de opgestelde requirements onduidelijk, incompleet, onbepaald of tegenstrijdig zijn, en deze onvolkomenheden corrigeren.

3. Requirementsspecificatie: formeel documenteren van de requirements in ene requirementsspecificatie..

4. Requirementsvalidatie: samen met de klanten en gebruikers evalueren of de set van requirements juist en volledig is in relatie tot hun behoeften en vereisten.

Requirementsmanagement gaat over het beheersen en beheren van de overeengekomen set requirements, het voorkomen van ongewenste scope-uitbreidingen en misverstanden over de inhoud van requirements gedurende het project.

Bron: Checklist requirements engineering, Erik van Veenendaal

"Een Story Map is een tweedimensionale weergave van een (deel van de) Product Backlog. Het is een visueel hulpmiddel om de requirements (User Stories) op de Product Backlog logisch op te knippen, te groeperen en te ordenen. Het is als het ware een kaart van de relaties tussen alle requirements.

Op de x-as staan diverse ketenonderdelen, dit kunnen processtappen, processen of functionele onderdelen zijn. Op de y-as worden de diverse Feature Sets geplaatst, ook wel slices genoemd. Dit zijn als het ware de lagen waaruit het totale product is opgebouwd. Elke laag is een verfraaiing van de daarboven gelegen lagen. De eerste laag wordt 'wandelend skelet' genoemd: het loopt wel, maar ziet er nog armzalig uit."

Bron: Agile - Pocketguide voor wendbare organisaties, Jeroen Venneman, Rik de Groot & Theo Gerrits

Bron: Deltaisis