Hvorfor skal du forstå softwarekrav som softwareingeniør

I denne artikel lærer du alt om softwarekrav. Du får en oversigt over emneområdet, processen og vigtigst af alt, hvad dit ansvar er på dette område som softwareingeniør.

Du bør få et indblik i din rolle og aktiviteter med softwarekrav. Hvis noget, har du noget at diskutere med kolleger efter din næste stand-up?

Denne artikel låner stærkt fra den tome, der er IEEE SWEBOK-guiden. Den forsøger at destillere noget af denne viden og omdirigere den mere kortfattet. Hvis du undrer dig, er SWEBOK et akronym for Software Engineering Body of Knowledge, som vedligeholdes af IEEE Computer Society.

På forhånd, hvorfor er dette vigtigt?

Der er en misforståelse fra dem, der ikke er inden for softwareteknik, at softwareteknikerens rolle er at bare "skrive kode."

Ja, vi er teknologer, der generelt elsker at lære programmering. I virkeligheden er dette et forenklet synspunkt, der undervurderer, hvad en professionel softwareingeniør faktisk gør i deres daglige job og karriere. Det fokuserer kun på et stykke af deres samlede ansvar.

En softwareingeniørs rolle er at opbygge forretningsløsninger i virksomhedsskala. Dette inkluderer et stort antal ansvarsområder, der ikke er relateret til den kode, de opretter.

Et ansvarsområde, du har som professionel softwareingeniør, er området med softwarekrav.

Hvad er softwarekrav?

Softwarekrav på overfladen lyder simpelt. Softwaren skal gøre X for Y, så Z. Tænk over det længe nok på ethvert problem, som software kan løse (eller om eksisterende software, der allerede løser et problem), og du kan sandsynligvis brainstorme et stort antal krav. Let, ikke?

Nå nej, faktisk for de fleste enterprise-software.

Hvordan samler du dine krav? Overvejer du interessenternes behov og prioriteter? Er dette virkelig et krav for brugere af softwaren? Er der tekniske begrænsninger af overvejelser? Hvordan ved du, hvornår det er gjort? Opfylder kravimplementeringen et bestemt kriterium? Og så videre...

Når du begynder at bore i ideen om softwarekrav, finder du ud af, at de skjuler et stort og dybere vidensområde.

Hvor dybt og stort et vidensområde? SWEBOK definerer området med softwarekrav som " beskæftiget med fremkaldelse, analyse, specifikation og validering af softwarekrav samt styring af krav i hele softwareproduktets livscyklus. "

Størrelsen af ​​dette område, såsom antallet af aktiviteter, og hvor involveret hver enkelt kan være, gav tilstrækkelig troværdighed til at afsætte en gren af ​​teknik kendt som " kravsteknik " udelukkende med fokus på kravsprocessen.

Visse organisationer kan ansætte specifikt til rollen som kravsingeniør. Du kan muligvis se dette oftere i virkelig store organisationer, der leverer løsninger på systemniveau, for eksempel, hvor deres foreslåede løsninger på kundeproblemer omfatter en samlet løsning, hvor softwaren kun er en enkelt komponent.

Mere typisk har organisationer en tendens til at dele kravsteknisk ansvar gennem aktiviteter, der er tildelt blandt de forskellige andre projektroller, som designere, forretningsanalytikere, produktejere, tilbud eller klientadministration, tekniske forfattere, softwarearkitekter / ingeniører osv.

Generelt er det vanskeligt at implementere kravsprocessen i en lineær proces i praksis, som en vandfaldsmetode. Dette ville kræve, at softwarekrav blev fremskaffet fra interessenterne, klassificeret, allokeret og til sidst afleveret til implementering af softwareudviklingsteamet. Dette er ofte ikke muligt for langsigtede succesrige løsninger i stor skala.

Krav til disse store softwareprojekter er aldrig helt forstået eller perfekt specificeret. I stedet gentager de normalt lige nok niveau af kvalitet og detaljer, der gør det muligt at tage beslutninger om design og indkøb.

Kravsteknik adskiller sig fra softwareteknik i den type arbejde, du fokuserer på.

Det er vigtigt, at du forstår din forbindelse til kravprocessen, da du sandsynligvis generelt vil være involveret i nogle kravaktiviteter på et eller andet tidspunkt.

Hvad er der involveret i softwarekrav til softwareingeniøren?

Afhængigt af din organisations kravsproces og / eller de kravaktiviteter, som softwareteknikeren er ansvarlig for, kan du blive involveret i ethvert eller alle faser. Dette kan være fra at indsamle krav lige til at kontrollere deres implementering.

Områder, hvor du kan være involveret:

  • Elicitation - indsamling af krav til softwaren
  • Klassificering - kategorisering af kravet
  • Validering - bekræfter kravet med interessenter
  • Udvikling og implementering - bygning af softwaren til at opfylde kravet
  • Forhandling - håndtering af interessekonflikter mellem interessenter
  • Verifikation - evaluering af softwarefunktionen opfylder kravet

Det er værd at bemærke, at dette ikke er en kopi af kravene engineering processen. De kræver et dybere niveau af engagement og typer af aktiviteter på bestemte områder, såsom styring og dokumentation af krav.

Administration og dokumentation af krav er normalt ikke dit ansvar. Det vil sandsynligvis være en af ​​de andre roller, der deler krav om ansvar.

Det er vigtigt, at du ved, hvordan du får adgang til og bruger kravsystemets ledelsessystem til at vurdere kravændringer og konsekvensanalyse.

Der er ikke et styringssystem med krav ...

I nogle tilfælde er registrering og styring af krav muligvis ikke i et specialiseret system. De kunne optages i andre typer optagelsessystemer, såsom software til udgivelsessporing, projektstyringsværktøjer eller måske endda versionskontrolsystemet.

I andre tilfælde udvikler organisationer eller projektteam ikke et middel til at dokumentere og styre krav. De kan i stedet stole på visionen om lederskab (en person eller et team med det almindelige eksempel er virksomhedens grundlægger) og / eller har begrænsede ressourcer. De kan modargumentere, at registrering eller styring af krav ikke er nødvendig.

Ikke registrering og styring af krav kan potentielt udgøre en alvorlig risiko for en organisation og softwareløsningen.

For eksempel bliver din organisation, der udvikler løsninger til kundebehov, nødt til at opfylde visse juridiske forpligtelser. De angiver, at din softwarekomponent er bygget til at give visse funktioner og er i stand til at give et bestemt serviceniveau (SLA'er).

Men hvis der skulle opstå en konflikt (juridisk eller på anden måde), måske et manglende stykke funktionalitet, fungerede et ikke-funktionelt krav ikke som forventet, eller endda tid / budget brugt på uønskede funktioner, hvordan viser du, hvad der blev implementeret, var hvad blev aftalt af interessenterne efter behov og nødvendigt?

Din organisation skal være i stand til at demonstrere kortlægningen mellem kravene på højt niveau (hvad kunden har brug for som en løsning) til de validerede softwarekrav (hvad interessenterne var enige om at imødekomme løsningens funktionelle behov, ikke nødvendigvis 1-til- 1) igennem til implementering af dokumentation og registrering af accept- eller serviceniveau-tests, der demonstrerer den leverede funktionalitet.

Et andet mere almindeligt (og mindre konstrueret) eksempel er at vurdere virkningen. Når din organisation eller dit projektteam vokser og udvikler sig, gør også den software, du opretter, også. Medmindre softwaren er beregnet til at være dispensabel, skal den overvejes at fungere over en periode, og det vil derfor være underlagt opgraderinger, nye funktioner og vedligeholdelse.

Dette nye arbejde kan negere, påvirke eller ændre eksisterende funktionalitet designet til at imødekomme et historisk krav på forskellige måder (såsom ændring af softwarearkitektur eller design af en komponent).

I så fald bliver du nødt til at revidere gamle krav for bedre at forstå de motivationer, der ligger til grund for det. For eksempel, hvorfor blev det implementeret på en sådan måde? Er det aktuelle arbejde nødvendigt at ændre sig? Er det gamle krav stadig relevant? etc.

Udnyttelse af softwarekrav

Kravsløsning henviser til den aktivitet, der beskriver, hvordan kravene samles eller indsamles. Ikke alle krav er "samlet" fra en kunde og kan stamme fra det system eller domæne, som softwaren fungerer inden for (såsom betjening og pålidelighed for kritiske systemer).

Fra et projektledelsesperspektiv er fremkaldelse afgørende for at udlede projektomfanget og de leverancer, der er vigtige for klientens eller brugernes behov, og prioriterer først de vigtigste behov.

Hvad er involveret i at fremkalde softwarekrav?

Afhængigt af hvilken rolle din rolle er involveret i kravsprocessen, skal du muligvis tage krav fra kilden.

Kravsløsning hjælper med at informere designet og arkitekturen for den samlede løsning. Det er vigtigt, at du forstår, hvor kravene kommer fra, og hvilke teknikker der anvendes.

Hvor kommer softwarekravene fra?

Der er mange kilder til krav, såsom:

  • Mål (også kendt som forretningsmæssig bekymring, kritisk succesfaktor osv.)
  • Domæne viden
  • Interessenter
  • Forretningsregler
  • Driftsmiljø

Hvis du er involveret i fremkaldelsen fra kilder, skal du:

  • Vær særlig opmærksom på målene.
    • Disse er ofte generelt vage, som "Softwaren skal implementeres ved hjælp af bedste praksis" eller "Softwaren skal være brugervenlig"
    • Vurder den relative værdi i forhold til prioriteten for løsningen. Undersøg relativt billige måder at opnå.
  • Erhverve eller have tilgængelig viden om applikationsdomænet
    • Dette giver dig baggrundsinformation, der giver forståelse for årsagerne til kravene.
    • Udvikling af modeller af det virkelige problem, såsom enhedsforholdsmodeller, er nøglen til god softwarekravsanalyse. Prøv at tænke ved hjælp af en ontologisk tilgang.
  • Identificere, repræsentere og styre synspunkter for mange forskellige typer interessenter
    • Krav kan være modstridende, overlappende eller kræve forskellige motiver i dele fra forskellige interessenters behov.
    • Det er vigtigt, at du genkender de forskellige behov, især i planlægningen af ​​implementeringen, hvor behovene er indarbejdet i designet.
  • Vis følsomhed over for løsningens driftsmiljø
    • Driftsmiljøet vil være underlagt en organisations struktur, kultur og interne politik.
    • Et generelt princip, som din software skal stræbe efter, er ikke at indføre uplanlagte eller tvungne ændringer i organisationens forretningsproces.

Hvordan får jeg softwarekravene?

Nogle hovedteknikker, du måske er involveret i (leverer teknisk ekspertise) kan være:

  • gennemførelse af interessentinterviews
  • skitserer scenarier
  • bygning prototyper
  • observation i problemområdet
  • brugerhistorier

Ved opbygning af prototyper er et generelt princip, du bør prøve at følge, at bruge hyppigere prototypetyper oftere i disse tidligere faser.

Disse foretrækkes for at undgå interessentfiksering på mindre eller tilfældige karakteristika. En prototype af højere kvalitet kan begrænse designfleksibilitet på utilsigtede måder.

Klassificering af softwarekrav

Når softwarekrav er fremkaldt, kan de derefter klassificeres på tværs af en række kategorier af projektteamet.

Dette hjælper på en række forskellige måder, såsom at estimere projektindsats, identificere komponenter til løsningsdesignet eller endda enkle implementeringsovervejelser.

Klassificeringstyper kan omfatte:

  • Funktionel / ikke-funktionel
    • Funktionelle krav beskriver de funktioner, som softwaren skal udføre. For eksempel at levere en kommunikationskanal til en bruger eller overføre data fra et format til et andet. De kan også være kendt som produkts funktioner eller funktioner.
    • Ikke-funktionelle krav fungerer for at håndhæve visse begrænsninger for løsningen, ofte med hensyn til kvalitet. Disse kan yderligere klassificeres i de mange typer " funktioner " såsom tilgængelighed, pålidelighed, genopretningsevne, vedligeholdelsesevne, skalerbarhed, ydeevne, sikkerhed osv.
  • Afledt / pålagt / Emergent
    • Stammer kravet fra andre krav?
    • Pålægges kravet eksplicit af en interessent?
    • Er kravet en fremvoksende ejendom? Med andre ord kan det ikke adresseres af en enkelt komponent, men afhænger af, hvordan alle softwarekomponenter fungerer.
  • Proces / produkt
    • Er kravet produktrelateret? (et eksempel, " Softwaren skal verificere en persons berettigelse ")
    • Er kravsprocessen relateret? (et eksempel: " Softwaren skal udvikles trinvist og bruge kontinuerlige integrations- og implementeringsarbejdsprocesser )
  • Prioritet
    • At balancere omkostningerne ved udvikling og implementering versus behovet for levering.
    • Kan bruge en fast mærket skala som obligatorisk, meget ønskelig, ønskelig og valgfri.
  • Anvendelsesområde
    • Bruges til at overveje indvirkningen på softwarearkitekturen og komponentdesignet.
    • Ikke-funktionelle har ofte et globalt anvendelsesområde.
  • Volatilitet / stabilitet
    • Potentialet for kravet vil ændre sig i softwarens livscyklus.
    • Dette hjælper med at implementere design, der er tolerante over for ændringer

Validering af softwarekrav

Når softwarekravene er fremkaldt og klassificeret, skal de valideres med interessenterne for nøjagtighed, og om de faktisk opfylder deres behov eller ej. Krav, der ikke kan valideres, er egentlig bare "ønsker" fra interessenterne.

Hvis du følger en iterativ udviklingsmetode, kan valideringen af ​​kravene udføres regelmæssigt, adskilt af omfanget omkring specifikke løsningsområder eller foretaget i klumper eller en anden form for adskillelse, der giver logisk mening.

Kravsvalidering indebærer normalt, at løsningsteamet afspiller deres forståelse af kravet tilbage til interessenter. Det kan også involvere et indledende design (forretning eller teknisk eller begge dele), der viser, hvordan hvert af interessenternes behov vil blive implementeret.

Disse forståelser skabes iterativt gennem planlægningsfasen og består normalt af synspunkter fra et tværfunktionelt team (designere, forretningsanalytikere, tekniske eksperter).

I nogle tilfælde kan designet muligvis have brug for noget præimplementeringsarbejde for bedre at demonstrere holdets forståelse, normalt i form af en funktionel prototype.

Under validering er dit team muligvis ikke i stand til fuldt ud at tilfredsstille kravene fra enhver interessent. Det er dit ansvar som teknisk ekspert at demonstrere og forhandle de kompromiser, der passer til begrænsningerne. Det skal være acceptabelt for de vigtigste interessenter, men også inden for budgetmæssige, tekniske, lovgivningsmæssige og andre foranstaltninger.

Brug af funktionelle prototyper

Funktionelle prototyper er nyttige, da de giver mulighed for:

  • validering af, at kravene er forstået
  • lettere fortolkning af ingeniørens antagelser
  • feedback, der kan give nye krav

Du skal overveje, at interessenter kan blive distraheret af kosmetiske problemer eller kvalitetsproblemer. Du kan afbøde dette ved konsekvent at kommunikere den reelle betydning af demonstrationen - den centrale underliggende funktionalitet.

Hvordan prototypen er bygget bestemmes af dit projektteam. Nogle advokater foretrækker prototyper, der helt undgår software (svarer til dem, der er bygget, når de fremkalder krav). Andre foretrækker en form for softwarevisning gennem designværktøjssæt eller en hurtigt bygget kladde iteration af softwaren bag en funktionskontrol.

Uanset hvilket valg dit team beslutter, skal overveje hastigheden på at opbygge prototypen versus effektiviteten ved at demonstrere kernefunktionaliteten.

Udvikling og implementering af softwarekrav

Når kravet er valideret med interessenter, kan du begynde at udvikle / implementere kravet.

I mange tilfælde vil du fungere som softwarearkitekt, fordi processen med at analysere og udarbejde kravene kræver, at de arkitektur / designkomponenter, der er ansvarlige for at opfylde kravene, identificeres.

En vigtig interesse for din organisation er at drage fordel af softwareløsningen. Det er dit ansvar at prøve at bruge metoder, der reducerer omkostningerne ved udvikling og vedligeholdelse.

Du kan gøre dette for eksempel gennem genbrug af komponenter (internt eller fra andre produkter) ved hjælp af veldefinerede mønstre og arbejde med veldefinerede og veldokumenterede værktøjer / rammer.

Specifikke krav, især begrænsninger, kan have enorm indflydelse på omkostningerne ved software. For eksempel, hvis dine færdigheder, der er sat i implementeringen, er dårlige, eller måske er kravet modvirket eller ikke passer med den nuværende arkitektur. Vigtige kompromiser mellem sådanne krav bør identificeres for projektteamet.

Gennem kravsprocessen er et vigtigt punkt, du skal forstå, forventningen om, at en betydelig del af kravene vil ændre sig. Anerk uundgåelighed med ændringer, og prøv at tage skridt i dit design for at give mulighed for det.

Brugerhistorien

En softwareingeniør arbejder ofte inden for rammerne af en brugerhistorie, der kan leveres. Brugerhistorien er en naturlig ordrepræsentation af en bestemt brugertypes interaktion med softwaren og den funktionalitet, den skal give dem. Det følger normalt formatet af:

Som en vil jeg, så det

Et eksempel:

Som kursusadministrator vil jeg se antallet af personer, der er tilmeldt et kursus, så jeg kan se den aktuelle kursuskapacitet

I nogle tilfælde kommer brugerhistorien med et design eller en prototype, hvis disse var påkrævet i valideringsfasen.

Det er muligt, at brugerhistorien ikke er brugercentreret og i stedet stammer fra en ny ejendom eller et ikke-funktionelt krav. I disse tilfælde modtager du muligvis kravet i en anden sammenhæng, der kan leveres (f.eks. En specifikation eller et scenarie-sæt).

En brugerhistorie er beregnet til at indeholde lige nok information, så dit teknikerteam kan producere et rimeligt skøn over indsatsen for at gennemføre den. Hvis dit team ikke er i stand til at producere et rimeligt skøn, kan det være et tegn på en dårlig match i viden / færdigheder, individuelle tillidsniveauer, tilpasnings- eller afhængighedsbegrænsninger eller afgørende, at brugerhistorien mangler kvalitet.

Softwareingeniører er (nødvendigvis) begrænset af projektstyringsplaner, så du skal prøve at tage skridt til at kontrollere, at kvaliteten af ​​kravene er så høj som muligt i betragtning af de tilgængelige ressourcer.

Før en brugerhistorie implementeres, skal du kontrollere:

  • for et passende acceptkriterium, skrevet eller aftalt med interessenterne, der bestemmer, hvordan målene i brugerhistorien kan opfyldes med implementeringen.
    • Dette vil danne grundlaget for acceptstestene af funktionen (med andre ord de tests, der viser kravet, er opfyldt).
    • Dette kan også være en del af teamdefinitionen af ​​"færdig" eller komplet.
  • prototype-designet (hvis det er lavet) er muligt og kan passe inden for den nuværende arkitektur, tekniske færdigheder og værktøjer, der er godkendt til brug i projektet.
  • eventuelle antagelser, der understøtter kravet.
    • Dette kan fremhæve huller i viden, potentielle problemer eller andre scenarier / kanttilfælde, der ikke overvejes, og som kræver yderligere afklaring fra interessenterne.

Forhandling af softwarekrav

Ved gennemførelsen af ​​et krav er det muligt, at ikke alle interessenters interesser er opfyldt perfekt. Dette kan f.eks. Ske mellem funktionelle og ikke-funktionelle krav, eller hvor et kravsimplementering påvirker en anden interessents interesse.

I de fleste tilfælde er det uklogt for dig at træffe en ensidig beslutning.

I stedet er din ansvarlige for at vurdere problemet, kommunikere enkelt og forhandle afvejninger, der er acceptable for de vigtigste interessenter, mens de forbliver inden for budgetmæssige, tekniske, lovgivningsmæssige og andre begrænsninger.

Verifikation af softwarekrav

Alle softwarekrav kræver behovet for at kunne verificeres, som en funktion eller et funktionskrav eller på globalt niveau som et ikke-funktionelt krav. Krav skal verificeres i forhold til det færdige produkt.

En vigtig opgave for dig er at planlægge, hvordan du verificerer hvert krav.

En softwareingeniør verificerer et krav ved hjælp af en acceptstest. Acceptstesten demonstrerer, hvordan kravet er gennemført (opfylder acceptkriterierne) ved at vise slutbrugeradfærd, der driver forretning med softwaren som defineret i kravet.

I krav, hvor det er sværere at demonstrere verifikationen, såsom ikke-funktionelle krav, kan en konstrueret simulering være påkrævet. For eksempel, for at teste ydelsesbelastningen for software, der implementerer en introduktionsproces, kan der oprettes testsoftware til at simulere hundreder eller tusinder af applikationer til systemet i en sort boks accept test.

Da software udvikler sig over tid, kan implementeringen af ​​et nyt krav utilsigtet påvirke opfyldelsen af ​​et tidligere implementeret krav. Denne regression kan beskyttes mod ved at automatisere acceptstestene. Du kan finde mange værktøjer og biblioteker, der er tilgængelige til programmeringssprog til almindelig brug af virksomheder, der muliggør automatisering af accepttest.

Forveks ikke accepttesten som dit eneste testansvar. Forsøg tilstrækkeligt at dække implementeringen med andre tests udover accept, såsom enheds- eller integrationstests.

Acceptstest varierer i kompleksitetsniveau afhængigt af acceptkriterierne. Forskellige organisationer kan også bruge forskellige terminologier og fremgangsmåder, hvilket betyder, at det kan forveksles med andre typer test eller der henvises til ved forskellige navne, såsom end-to-end test, funktionel test eller scenarie test. Din organisation kan også have strenge kriterier eller formater, hvor acceptstest demonstreres med.

Husk, at kernen i enhver acceptstest simpelthen er en formel verifikation af, at en implementeret løsning opfylder softwarekravet ved at replikere brugeradfærd ved kørende applikation mod slutproduktet.

Det er det i en nøddeskal

Du har klaret det. Kudos til dig!

Jeg håber, at denne artikel gav nogle fordele ved at anerkende din rolle som softwareingeniør med softwarekrav.

Du kan læse flere af mine artikler på min blog.

Denne artikel deles frit, og forfatteren modtog ikke noget bidrag eller fortjeneste som påkrævet af SWEBOK copyright og genudskrivningstilladelser. Eventuelle synspunkter eller meninger, der udtrykkes, afspejler ikke synspunkter fra IEEE eller nogen organ / organisation, som jeg er tilknyttet, er ikke godkendt af IEEE og repræsenterer kun min egen opfattelse og mening.