Krav för modellanvändare

Visual Studio hjälper dig att förstå, diskutera och kommunicera användarnas behov genom att rita diagram över deras aktiviteter och vilken roll systemet spelar för att hjälpa dem att uppnå sina mål. En kravmodell är en uppsättning av dessa diagram, som var och en fokuserar på en annan aspekt av användarnas behov.

Information om vilka versioner av Visual Studio som stöder varje typ av modell finns i Versionsstöd för arkitektur- och modelleringsverktyg.

En kravmodell hjälper dig:

• Fokusera på systemets externa beteende, separat från dess interna design.

• Beskriv användarnas och intressenternas behov med mycket mindre tvetydighet än vad du kan på naturligt språk.

• Definiera en konsekvent ordlista med termer som kan användas av användare, utvecklare och testare.

• Minska luckor och inkonsekvenser i kraven.

• Minska det arbete som krävs för att svara på kravändringar.

• Planera i vilken ordning funktionerna ska utvecklas.

• Använd modellerna som grund för systemtester, vilket gör en tydlig relation mellan testerna och kraven. När kraven ändras hjälper den här relationen dig att uppdatera testerna korrekt. Detta säkerställer att systemet uppfyller de nya kraven.

En kravmodell ger störst nytta om du använder den för att fokusera diskussioner med användarna eller deras representanter och gå tillbaka till den i början av varje iteration. Du behöver inte slutföra det i detalj innan du skriver kod. Ett delvis fungerande program, även om det är mycket förenklat, utgör i allmänhet den mest stimulerande grunden för att diskutera kraven med användarna. Modellen är ett effektivt sätt att sammanfatta resultatet av dessa diskussioner. Mer information finns i Använda modeller i din utvecklingsprocess.

Anmärkning

I de här ämnena betyder "system" det system eller det program som du utvecklar. Det kan vara en stor samling av många programvaru- och maskinvarukomponenter. eller ett enda program; eller en programvarukomponent i ett större system. I varje fall beskriver kravmodellen det beteende som är synligt utanför systemet, oavsett om det är via ett användargränssnitt eller API.

Vanliga uppgifter

Du kan skapa flera olika vyer av användarnas krav. Varje vy innehåller en viss typ av information. När du skapar dessa vyer är det bäst att ofta växla mellan dem. Du kan börja från valfri vy.

Diagram eller dokument	Vad den beskriver i en kravmodell	Section
Konceptuellt klassdiagram	Ordlista över typer som används för att beskriva kraven. de typer som visas i systemets gränssnitt.
Ytterligare dokument eller arbetsobjekt	Kriterier för prestanda, säkerhet, användbarhet och tillförlitlighet.	Beskriva tjänstkravens kvalitet
Ytterligare dokument eller arbetsobjekt	Begränsningar och regler som inte är specifika för ett visst användningsfall	Visa affärsregler

Observera att de flesta diagramtyperna kan användas i andra syften. En översikt över diagramtyper finns i Skapa modeller för din app.

Visa affärsregler

En affärsregel är ett krav som inte är associerat med ett visst användningsfall och som bör observeras i hela systemet.

Många affärsregler är begränsningar för relationerna mellan de konceptuella klasserna. Du kan skriva dessa statiska affärsregler som kommentarer som är associerade med relevanta klasser i ett konceptuellt klassdiagram. Till exempel:

Dynamiska affärsregler begränsar de tillåtna sekvenserna av händelser. Du kan till exempel använda ett sekvens- eller aktivitetsdiagram för att visa att en användare måste logga in innan andra åtgärder utförs i systemet.

Många dynamiska regler kan dock anges mer effektivt och allmänt genom att ersätta dem med statiska regler. Du kan till exempel lägga till ett booleskt attribut "Loggat in" till en klass i den konceptuella klassmodellen. Du skulle lägga till 'Inloggad' som eftervillkor för inloggningsanvändningsfallet och lägga till det som ett inloggningsvillkor för de flesta andra användningsfall. Med den här metoden kan du undvika att definiera alla möjliga kombinationer av händelsesekvenser. Det är också mer flexibelt när du behöver lägga till nya användningsfall i modellen.

Observera att valet här handlar om hur du definierar kraven och att detta är oberoende av hur du implementerar kraven i programkoden.

Följande avsnitt innehåller mer information:

För att lära dig mer om	Läs
Så här utvecklar du kod som följer affärsregler	Modellera appens arkitektur

Beskriva tjänstkvalitetskrav

Det finns flera kategorier av krav på tjänstkvalitet. De innehåller följande:

• Performance

• Security

• Usability

• Reliability

• Robusthet

Du kan inkludera några av dessa krav i beskrivningarna av specifika användningsfall. Andra krav är inte specifika för användningsfall och skrivs mest effektivt i ett separat dokument. När du kan är det bra att följa ordförrådet som definieras av kravmodellen. Observera i följande exempel att de viktigaste orden som används i kravet är rubrikerna för aktörer, användningsfall och klasser i föregående illustrationer:

Om en restaurang tar bort ett menyalternativ medan en kund beställer en måltid visas alla orderobjekt som refererar till menyalternativet i rött.

Se Modellera appens arkitektur för att lära dig hur du utvecklar kod som följer tjänstkravens kvalitet.

Relaterat innehåll

• Använda modeller i utvecklingsprocessen
• Modellera appens arkitektur