Software Requirements

De software requirements zijn een beschrijving van kenmerken en functionaliteiten van het doelsysteem. Eisen geven de verwachtingen van gebruikers van het softwareproduct weer. De eisen kunnen duidelijk of verborgen zijn, bekend of onbekend, verwacht of onverwacht vanuit het gezichtspunt van de klant.

Requirement Engineering

Het proces om de software-eisen van de klant te verzamelen, te analyseren en te documenteren staat bekend als requirement engineering.

Het doel van requirement engineering is het ontwikkelen en onderhouden van een verfijnd en beschrijvend ‘System Requirements Specification’ document.

Requirement Engineering Proces

Het is een proces in vier stappen, dat bestaat uit –

• Feasibility Study
• Requirement Gathering
• Software Requirement Specification
• Software Requirement Validation

Laten we het proces eens in het kort bekijken –

Feasibility study

Wanneer de klant de organisatie benadert om het gewenste product te laten ontwikkelen, komt hij met een ruw idee over welke functies de software moet vervullen en welke functies er allemaal van de software worden verwacht.

Aan de hand van deze informatie gaan de analisten in detail na of het gewenste systeem en de functionaliteit ervan haalbaar zijn om te ontwikkelen.

Deze haalbaarheidsstudie is gericht op het doel van de organisatie. Deze studie analyseert of het software produkt praktisch uitvoerbaar is in termen van implementatie, bijdrage van het project aan de organisatie, kostenbeperkingen en in overeenstemming met de waarden en doelstellingen van de organisatie. Het onderzoekt de technische aspecten van het project en het product, zoals bruikbaarheid, onderhoudbaarheid, productiviteit en integratie mogelijkheden.

Het resultaat van deze fase moet een haalbaarheidsstudie rapport zijn dat adequate opmerkingen en aanbevelingen voor het management moet bevatten over het al dan niet uitvoeren van het project.

Requirement Gathering

Als het haalbaarheidsrapport positief is over het uitvoeren van het project, begint de volgende fase met het verzamelen van eisen van de gebruiker. Analisten en ingenieurs communiceren met de klant en de eindgebruikers om hun ideeën over wat de software moet bieden en welke functies ze willen dat de software bevat te leren kennen.

Software Requirement Specification

SRS is een document dat door de systeemanalist wordt opgesteld nadat de vereisten van de verschillende belanghebbenden zijn verzameld.

SRS definieert hoe de beoogde software zal interageren met hardware, externe interfaces, snelheid van de werking, responstijd van het systeem, draagbaarheid van de software op verschillende platforms, onderhoudbaarheid, snelheid van herstel na crashen, beveiliging, kwaliteit, beperkingen enz.

De vereisten die van de klant worden ontvangen zijn in natuurlijke taal geschreven. Het is de verantwoordelijkheid van de systeemanalist om de eisen in technische taal te documenteren, zodat ze begrijpelijk en bruikbaar zijn voor het software-ontwikkelingsteam.

SRS moet met de volgende kenmerken komen:

• User Requirements worden uitgedrukt in natuurlijke taal.
• Technische requirements worden uitgedrukt in gestructureerde taal, die wordt gebruikt binnen de organisatie.
• Design beschrijving moet worden geschreven in Pseudo code.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions –

• If they can be practically implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

• Requirements gathering – De ontwikkelaars bespreken met de klant en eindgebruikers en kennen hun verwachtingen van de software.
• Organizing Requirements – De ontwikkelaars prioriteren en rangschikken de requirements in volgorde van belangrijkheid, urgentie en gemak.

• Onderhandeling & discussie – Als requirements dubbelzinnig zijn of als er conflicten zijn in requirements van verschillende stakeholders, dan wordt daarover onderhandeld en gediscussieerd met stakeholders. Eisen kunnen dan worden geprioriteerd en redelijk gecompromitteerd.

  De eisen komen van verschillende belanghebbenden. Om de dubbelzinnigheid en conflicten te verwijderen, worden ze besproken voor de duidelijkheid en juistheid. Onrealistische eisen worden redelijkerwijs gecompromitteerd.

• Documentatie – Alle formele & informele, functionele en niet-functionele eisen worden gedocumenteerd en beschikbaar gesteld voor verwerking in de volgende fase.

Requirement Elicitation Techniques

Requirements Elicitation is het proces om de requirements voor een beoogd softwaresysteem te achterhalen door te communiceren met opdrachtgever, eindgebruikers, systeemgebruikers en anderen die belang hebben bij de ontwikkeling van het softwaresysteem.

Er zijn verschillende manieren om requirements te achterhalen

Interviews

Interviews zijn een sterk medium om requirements te verzamelen. Organisaties kunnen verschillende soorten interviews houden, zoals:

• Gestructureerde (gesloten) interviews, waarbij elke te verzamelen informatie van tevoren is vastgesteld, ze volgen stramien en onderwerp van gesprek stevig.
• Niet-gestructureerde (open) interviews, waarbij te verzamelen informatie niet van tevoren is vastgesteld, meer flexibel en minder bevooroordeeld.
• Orale interviews
• Geschreven interviews
• Een-op-een interviews die worden gehouden tussen twee personen aan de andere kant van de tafel.
• Groepsinterviews die worden gehouden tussen groepen van deelnemers. Ze helpen bij het blootleggen van een ontbrekende eis als tal van mensen betrokken zijn.

Enquêtes

Organisatie kan enquêtes houden onder verschillende belanghebbenden door te vragen over hun verwachtingen en eisen van het komende systeem.

Vragenlijsten

Een document met een voorgedefinieerde set van objectieve vragen en de bijbehorende opties wordt overhandigd aan alle belanghebbenden om te beantwoorden, die worden verzameld en gecompileerd.

Een tekortkoming van deze techniek is, dat als een optie voor een bepaalde kwestie niet in de vragenlijst wordt genoemd, de kwestie onbehandeld kan blijven.

Taakanalyse

Team van ingenieurs en ontwikkelaars kan de operatie analyseren waarvoor het nieuwe systeem is vereist. Als de klant al over software beschikt om een bepaalde bewerking uit te voeren, wordt deze bestudeerd en worden de vereisten voor het voorgestelde systeem verzameld.

Domeinanalyse

Elke software valt in een of andere domeincategorie. De deskundige mensen in het domein kunnen een grote hulp zijn bij het analyseren van algemene en specifieke eisen.

Brainstorming

Een informeel debat wordt gehouden tussen verschillende belanghebbenden en al hun input wordt vastgelegd voor verdere requirements analyse.

Prototyping

Prototyping is het bouwen van een gebruikersinterface zonder detail functionaliteit toe te voegen voor de gebruiker om de functies van het beoogde software product te interpreteren. Het helpt om een beter idee te krijgen van de eisen. Als er geen software is geïnstalleerd bij de klant als referentie voor de ontwikkelaar en de klant is niet op de hoogte van zijn eigen eisen, maakt de ontwikkelaar een prototype op basis van de initieel genoemde eisen. Het prototype wordt aan de klant getoond en de feedback wordt genoteerd. De feedback van de klant dient als input voor het verzamelen van eisen.

Observatie

Team van experts bezoekt de organisatie of werkplek van de klant. Zij observeren de daadwerkelijke werking van de bestaande geïnstalleerde systemen. Zij observeren de workflow bij de klant en hoe uitvoeringsproblemen worden aangepakt. The team itself draws some conclusions which aid to form requirements expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase and what kinds of requirements are expected from the software system.

In het algemeen moeten software-eisen in twee categorieën worden ingedeeld:

Functionele eisen

Eisen, die betrekking hebben op het functionele aspect van software vallen in deze categorie.

Zij definiëren functies en functionaliteit binnen en van het softwaresysteem.

Voorbeelden –

• Zoekoptie gegeven aan gebruiker om te zoeken uit verschillende facturen.
• Gebruiker moet elk rapport kunnen mailen naar het management.
• Gebruikers kunnen worden onderverdeeld in groepen en groepen kunnen aparte rechten krijgen.
• Gebruikers moeten voldoen aan bedrijfsregels en administratieve functies.
• Software wordt ontwikkeld met behoud van neerwaartse compatibiliteit.

Niet-functionele eisen

Eisen, die niet gerelateerd zijn aan het functionele aspect van software, vallen in deze categorie. Het zijn impliciete of verwachte eigenschappen van software, waarvan gebruikers uitgaan.

Niet-functionele eisen zijn onder meer -.

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility

Requirements are categorized logically as

• Must Have : Software cannot be said operational without them.
• Should have : Enhancing the functionality of software.
• Could have : Software can still properly function with these requirements.
• Wish list : These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.

User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is –

• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below –

• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of color and texture.
• Zorg voor helpinformatie
• Gebruikersgerichte benadering
• Groepsgebaseerde weergave-instellingen.

Software Systeemanalist

Systeemanalist in een IT-organisatie is een persoon, die de vereisten van het voorgestelde systeem analyseert en ervoor zorgt dat de vereisten op de juiste wijze worden opgevat en gedocumenteerd & correct. De rol van een analist begint tijdens de Software Analyse fase van SDLC. Het is de verantwoordelijkheid van de analist om ervoor te zorgen dat de ontwikkelde software voldoet aan de eisen van de klant.

Systeemanalisten hebben de volgende verantwoordelijkheden:

• Analyseren en begrijpen van requirements van beoogde software
• Inzicht in hoe het project zal bijdragen in de organisatiedoelstellingen
• Identificeren van bronnen van requirement
• Validatie van requirement
• Ontwikkelen en implementeren van requirement management plan
• Documentatie van business, technische, proces- en producteisen
• Afstemming met klanten om eisen te prioriteren en onduidelijkheden weg te nemen
• Afronding acceptatiecriteria met klant en andere belanghebbenden

Software Metrieken en Maatstaven

Software Maatstaven kan worden opgevat als een proces van kwantificeren en symboliseren van verschillende attributen en aspecten van software.

Software Metrics bieden maatstaven voor verschillende aspecten van het software proces en software product.

Software maatregelen zijn fundamentele eisen van software engineering. Ze helpen niet alleen om het software-ontwikkelingsproces te beheersen, maar ook om de kwaliteit van het uiteindelijke product uitstekend te houden.

Volgens Tom DeMarco, een (Software Engineer), “Je kunt niet controleren wat je niet kunt meten.” Door zijn uitspraak, is het heel duidelijk hoe belangrijk software metingen zijn.

Laten we eens kijken naar een aantal software metrics:

• Size Metrics – LOC (Lines of Code), meestal berekend in duizenden geleverde broncode lijnen, aangeduid als KLOC.

  Function Point Count is maat voor de functionaliteit die door de software wordt geleverd. Function Point Count definieert de omvang van het functionele aspect van software.

• Complexity Metrics – McCabe’s Cyclomatic complexity kwantificeert de bovengrens van het aantal onafhankelijke paden in een programma, wat wordt gezien als complexiteit van het programma of de modules. Het wordt voorgesteld in termen van grafiektheoretische concepten door gebruik te maken van control flow graph.

• Quality Metrics – Defecten, hun soorten en oorzaken, gevolgen, intensiteit van de ernst en hun implicaties bepalen de kwaliteit van het product.

  The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

• Process Metrics – In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
• Resource Metrics – Effort, time and various resources used, represents metrics for resource measurement.