Programvarukrav

Programvarukraven är en beskrivning av målsystemets egenskaper och funktioner. Kraven förmedlar användarnas förväntningar på programvaruprodukten. Kraven kan vara uppenbara eller dolda, kända eller okända, förväntade eller oväntade ur kundens synvinkel.

Kravutformning

Processen för att samla in programvarukraven från kunden, analysera och dokumentera dem kallas kravutformning.

Målet med kravutformningen är att utveckla och underhålla ett sofistikerat och beskrivande ”Systemkravsspecifikationsdokument”.

Processen för kravutformning

Det är en process i fyra steg, som omfattar –

• Möjlighetsstudie
• Kravinsamling
• Specifikation av programvarukrav
• Validering av programvarukrav

Låt oss se processen kortfattat –

Möjlighetsstudie

När kunden vänder sig till organisationen för att få den önskade produkten utvecklad, kommer den med en grov idé om vilka alla funktioner som programvaran måste utföra och vilka alla funktioner som förväntas av programvaran.

Med hänvisning till denna information gör analytikerna en detaljerad studie om huruvida det önskade systemet och dess funktionalitet är genomförbart att utveckla.

Denna genomförbarhetsstudie är inriktad på organisationens mål. I studien analyseras om mjukvaruprodukten kan förverkligas i praktiken när det gäller genomförande, projektets bidrag till organisationen, kostnadsbegränsningar och i enlighet med organisationens värderingar och mål. Den utforskar tekniska aspekter av projektet och produkten såsom användbarhet, underhållbarhet, produktivitet och integrationsförmåga.

Resultatet av denna fas bör vara en rapport om genomförbarhetsstudien som bör innehålla adekvata kommentarer och rekommendationer till ledningen om huruvida projektet bör genomföras eller inte.

Inhämtning av krav

Om genomförbarhetsrapporten är positiv till att genomföra projektet, börjar nästa fas med att samla in krav från användaren. Analytiker och ingenjörer kommunicerar med kunden och slutanvändarna för att få veta deras idéer om vad programvaran ska tillhandahålla och vilka funktioner de vill att programvaran ska innehålla.

Mjukvarukravsspecifikation

SRS är ett dokument som skapas av systemanalytiker efter att kraven samlats in från olika intressenter.

SRS definierar hur den tänkta programvaran kommer att interagera med hårdvara, externa gränssnitt, driftshastighet, systemets svarstid, programvarans portabilitet på olika plattformar, underhållbarhet, återhämtningshastighet efter krasch, säkerhet, kvalitet, begränsningar osv.

De krav som tas emot från kunden är skrivna på naturligt språk. Det är systemanalytikerns ansvar att dokumentera kraven på ett tekniskt språk så att de kan förstås och vara användbara för programvaruutvecklingsgruppen.

SRS bör komma med följande funktioner:

• Användarkrav uttrycks på naturligt språk.
• Tekniska krav uttrycks på ett strukturerat språk som används inom organisationen.
• Designbeskrivning bör skrivas i pseudokod.
• 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:

• Kravinsamling – Utvecklarna diskuterar med kunden och slutanvändarna och känner till deras förväntningar på programvaran.
• Organisering av krav – Utvecklarna prioriterar och ordnar kraven efter betydelse, brådska och bekvämlighet.

• Förhandling & diskussion – Om kraven är tvetydiga eller om det finns vissa konflikter i olika intressenters krav, om så är fallet förhandlas och diskuteras det sedan med intressenterna. Kraven kan då prioriteras och rimligen kompromissas.

  Kraven kommer från olika intressenter. För att undanröja tvetydigheter och konflikter diskuteras de för att få klarhet och korrekthet. Orealistiska krav kompromissas rimligen.

• Dokumentation – Alla formella & informella, funktionella och icke-funktionella krav dokumenteras och görs tillgängliga för behandling i nästa fas.

Tekniker för kravinsamling

Kravinsamling är processen för att ta reda på kraven för ett tänkt mjukvarusystem genom att kommunicera med klient, slutanvändare, systemanvändare och andra som har ett intresse av mjukvarusystemets utveckling.

Det finns olika sätt att ta reda på krav

Intervjuer

Intervjuer är ett starkt medium för att samla in krav. Organisationen kan genomföra flera olika typer av intervjuer som t.ex:

• Strukturerade (slutna) intervjuer, där varje enskild information som ska samlas in är bestämd i förväg, de följer mönster och diskussionsämne bestämt.
• Också ostrukturerade (öppna) intervjuer, där informationen som ska samlas in inte är bestämd i förväg, mer flexibla och mindre partiska.
• Orala intervjuer
• Skrivna intervjuer
• En-till-en-intervjuer som hålls mellan två personer över bordet
• Gruppintervjuer som hålls mellan grupper av deltagare. De hjälper till att avslöja eventuella saknade krav eftersom många personer är inblandade.

Undersökningar

Organisationen kan genomföra undersökningar bland olika intressenter genom att fråga om deras förväntningar och krav på det kommande systemet.

Frågeformulär

Ett dokument med en fördefinierad uppsättning objektiva frågor och respektive alternativ överlämnas till alla intressenter att besvara, vilka samlas in och sammanställs.

En brist med denna teknik är att om ett alternativ för en viss fråga inte nämns i frågeformuläret kan frågan lämnas obevakad.

Uppgiftsanalys

Ett team av ingenjörer och utvecklare kan analysera den verksamhet för vilken det nya systemet behövs. Om kunden redan har en programvara för att utföra en viss operation studeras den och kraven på det föreslagna systemet samlas in.

Domänanalys

Alla programvaror faller inom någon domänkategori. Experterna inom domänen kan vara till stor hjälp för att analysera allmänna och specifika krav.

Brainstorming

En informell debatt hålls mellan olika intressenter och alla deras bidrag registreras för vidare analys av kraven.

Prototypning

Prototypning innebär att man bygger ett användargränssnitt utan att lägga till detaljfunktionalitet för att användaren ska kunna tolka funktionerna i den avsedda mjukvaruprodukten. Det bidrar till att ge en bättre uppfattning om kraven. Om det inte finns någon programvara installerad hos kunden som utvecklaren kan använda som referens och om kunden inte är medveten om sina egna krav, skapar utvecklaren en prototyp baserad på de krav som nämndes inledningsvis. Prototypen visas för kunden och återkopplingen noteras. Klientens återkoppling fungerar som ett underlag för kravinsamling.

Observation

Expertteamet besöker kundens organisation eller arbetsplats. De observerar hur de befintliga installerade systemen fungerar. De observerar arbetsflödet hos kunden och hur problem med utförandet hanteras. 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.

Bredvid bör mjukvarukraven kategoriseras i två kategorier:

Funktionella krav

Krav, som är relaterade till den funktionella aspekten av mjukvaran faller in i denna kategori.

De definierar funktioner och funktionalitet inom och från mjukvarusystemet.

Exempel –

• Sökmöjlighet som ges till användaren för att söka från olika fakturor.
• Användaren ska kunna maila vilken rapport som helst till ledningen.
• Användare kan delas in i grupper och grupper kan ges separata rättigheter.
• Ska följa affärsregler och administrativa funktioner.
• Mjukvaran utvecklas med intakt nedåtgående kompatibilitet.

Non-funktionella krav

Krav, som inte är relaterade till den funktionella aspekten av mjukvaran, faller inom denna kategori. De är implicita eller förväntade egenskaper hos programvaran som användarna antar.

Icke-funktionella krav är bland annat följande.

• 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.
• Förmedla hjälpinformation
• Användarcentrerat tillvägagångssätt
• Gruppbaserade visningsinställningar.

Mjukvarusystemanalytiker

Systemanalytiker i en IT-organisation är en person, som analyserar kravet på föreslaget system och ser till att kraven utformas och dokumenteras & på rätt sätt. Analytikerns roll börjar under programvaruanalysfasen i SDLC. Det är analytikerns ansvar att se till att den utvecklade programvaran uppfyller kundens krav.

Systemanalytiker har följande ansvarsområden:

• Analysera och förstå kraven på den avsedda programvaran
• Förstå hur projektet kommer att bidra till organisationens mål
• Identifiera kravkällor
• Validering av krav
• Utarbeta och implementera en kravhanteringsplan
• Dokumentation av affärsmässiga, tekniska, process- och produktkrav
• Samordning med kunder för att prioritera krav och avlägsna och tvetydigheter
• Finansiering av acceptanskriterier med kunden och andra intressenter

Mätetal och åtgärder för programvara

Mätetal för programvara kan förstås som en process för att kvantifiera och symbolisera olika attribut och aspekter av programvara.

Mätetal för programvara ger mått för olika aspekter av programvaruprocessen och programvaruprodukten.

Mätetal för programvara är ett grundläggande krav för programvaruteknik. De hjälper inte bara till att kontrollera mjukvaruutvecklingsprocessen utan också till att hålla kvaliteten på den slutliga produkten utmärkt.

Enligt Tom DeMarco, en (mjukvaruingenjör), ”Du kan inte kontrollera det du inte kan mäta”. Med hans ord är det mycket tydligt hur viktiga programvarumätningar är.

Låt oss se några programvarumätningar:

• Storleksmätningar – LOC (Lines of Code), oftast beräknat i tusentals levererade källkodslinjer, betecknat som KLOC.

  Function Point Count är ett mått på den funktionalitet som tillhandahålls av programvaran. Funktionspunktsräkning definierar storleken på den funktionella aspekten av programvaran.

• Komplexitetsmått – McCabes cyklomatiska komplexitet kvantifierar den övre gränsen för antalet oberoende vägar i ett program, vilket uppfattas som komplexiteten hos programmet eller dess moduler. Den representeras i termer av grafteoretiska begrepp med hjälp av kontrollflödesdiagram.

• Kvalitetsmått – defekter, deras typer och orsaker, konsekvenser, allvarlighetsgrad och deras följder definierar produktens kvalitet.

  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.