Komplexa fordonssystem ger komplexa kravspecifikationer och ger upphov till många utmaningar längs vägen. Med hjälp av Realworld-projekt som grund beskriver författarna problem och lösningar för kravteknik inom fordonsområdet. n fordonsindustrin – särskilt på den avancerade marknaden – komplexiteten hos elektroniska komponenter ökar snabbt. För närvarande går ungefär en tredjedel av alla utvecklingskostnader i avancerade modeller till elektrisk och elektronisk systemutveckling, och kostnaden fortsätter att öka (se figur 1). Samtidigt utvecklas många något olika varianter på komponenter i en serie prototypfaser på olika scheman. Följaktligen överträffar komplexiteten i specifikationsaktiviteter kraven på konstruktion av merciala fordon, vi utvecklar allt fler system som kan ingripa med förarens åtgärder (exempel inkluderar det elektroniska stabilitetsprogrammet, antilåsningssystemet och drive-by-wire). I sådana system kan fel orsaka allvarliga olyckor. Därför har vi en krävande utvecklingsprocess: systemspecifikationer och systemutveckling måste vara fullständigt begripliga, reproducerbara och kontinuerliga. Projektstorlekar sträcker sig från små insatser, med två till fem utvecklare som arbetar med en kravdatabas som genererar några specifikationer dokument, till betydligt större projekt. För närvarande har vårt största projekt en kravdatabas som är cirka 3 Gbyte (och växer) och genererar mer än 20 fordonskomponentspecifikationsdokument. Projektet har cirka 160 användare som arbetar med databasen, tillsammans med 40 användare med lässkyddad åtkomst. I vårt RE-arbete har vi använt tre kravhanteringsverktyg: Dynamic Object Oriented Requirements System (Doors; se www.telelogic.com/products/doorsers/doors); RequisitePro (www.rational.com/products/reqpro), och RequisitePro (www.rational.com/products/reqpro), och Requirements Traceability and Management (RTM; se www.chipware. Hur är det fatt med detta? Alla tre stöder grundläggande databashantering för individuella krav, deras attribut och deras historia, men verktygen skiljer sig mycket åt när det gäller användargränssnitt, spårning och visningshantering, distribuerat arbete, säkerhetskoncept, extensibilitetsmekanismer och import-exportgränssnitt. Vårt RE-arbete har gett flera viktiga resultat. Först etablerade vi ett RE-team inom DaimlerChryslers forskning som stödjer företagets affärsenheter. Vi definierade sedan en generisk RE-process för att både samordna RE-teamets arbete och stödja diskussioner med affärsenheterna. Flera affärsenheter antog därefter den generiska processen och anpassade den till specifika kunders behov. Dessutom etablerade vi flera DaimlerChryslerspecifika kravhanteringsinformationsmodeller I Specificerade riktlinjer för kravhanteringsverktyg anpassade till DaimlerChrysler processer Jag utvärderade våra erfarenheter och arbetade med att länka kravhanteringsverktyg till andra DaimlerChrysler verktyg I Utvecklade forskningsprototyper och fallstudier av bästa praxis inom RE Vi stödde också många pilotprojekt som introducerade de nya processerna och verktygen. Gör så låt oss tillhandahålla tillägg till kravhanteringsverktyg som projektingenjörer begärt. I synnerhet utvecklade vi 10 specifika funktionella förlängningar till Dörrar med cirka 50 tusen rader kod. En av dessa tillägg låter oss specificera och generera dokument som integrerar data som distribueras i Doors-databasen. En annan stöder avancerad definition och automatiserad administration av Doors-projekt, medan flera andra definierar ytterligare export- och importgränssnitt. Vissa av dessa tillägg behövs för andra kravhanteringsverktyg och nonautomotive applikationer; kravhanteringsverktyg har ett sätt att gå innan de kommer att stödja tillräckligt mogen funktionalitet och lämpliga automationsnivåer. I framtiden förväntar vi oss att många av dessa förlängningar blir onödiga på grund av verktygsframsteg. Vi distribuerar uppdateringar av våra tillägg och deras dokumentation tillsammans med företagsspecifikt material om kravhanteringsmetod och process-till alla Dörranvändare inom företaget två gånger om året. Som vi beskriver här nedan var några av våra problem inriktade på teknik, medan andra var inriktade på process. Här beskriver vi upplevelser som var starkt relaterade till båda.  Textmässiga krav är bara en del av utvecklingen av spelautomotive är alltför komplext för enbart text att hantera. Detta betyder naturligtvis inte att textkrav är oviktiga. Det är dock uppenbart att hanteringen och kontrollen av enbart textkraven är otillräcklig. När det gäller komplexa system är det dessutom nästan omöjligt att kontrollera "bara textkraven". För att återspegla egenskaperna och faserna i specifikations- och utvecklingsprocesserna behöver vi ytterligare attribut, t.ex. arbetstillstånd (ursprungligt, definierat och släppt, t.ex.) för det förra, och förfallodatum (t.ex. A-prov och B-prov) för det senare. Forskare erkänner nu öppet vikten av sådana egenskaper, och det finns nyttiga samlingar. [1] [2] [3] [4] [5] [6] Tricket är att skräddarsy rätt uppsättning attribut så att arbetet med att definiera och underhålla dem balanseras av fördelarna med bättre processkontroll och återanvändning av specifikationer. Vi måste också hantera kravens historia. Förutom att registrera den lokala historien om ett enda krav manipulation, behöver ingenjörer vanligtvis en välstrukturerad global historia om hur en viss grupp av krav manipulerades i förhållande till någon tidigare baslinje. Tillsammans med attribut och historik måste vi också hantera en specifikations illustrationer, tabeller, förklaringar om designmotivation eller designbeslut, testinformation, parametrar och åtföljande bakgrundsinformation (t.ex. utdrag från standarder). Denna ytterligare information utgör ofta mer än hälften av den totala specifikationen. Ofta förvirrar komplexiteten hos dessa olika objekt, deras egenskaper och förhållandet dem emellan snabbt ingenjörerna. För att råda bot på denna situation definierade vi formellt all denna information med hjälp av en metadatamodell. En kravhanteringsinformationsmodell (RMI) är central för kravhanteringsprojekt: Den utgör grunden för diskussioner med ingenjörer om deras behov och hur de systematiskt ska hantera sina specifikationer. Att utveckla ett RMI med ingenjörer har blivit vår främsta metod för att framgångsrikt implementera kravhantering i projekt. 7 För att säkerställa konsekvens och återanvändbarhet införde vi ett företagsövergripande, modulärt RMI som nya projekt kan anpassa och skräddarsy. Ingenjörer lever i en dokumentorienterad värld, och kravhanteringsverktyg måste behålla sitt utseende och sin känsla. Systemutvecklare fokuserar vanligtvis på dokumentcentrerad RE. Detta är föga förvånande eftersom dokument är det traditionella interna och externa gränssnittet till leverantörer. I själva verket är hela utvecklingsprocessen (och särskilt ett formellt kontrakt) baserad på dokument och utbyte av dessa. Att införa databasbaserade verktyg för hantering av krav kan därför bli mest framgångsrika om de behåller ett dokuments utseende och känsla. Verktygsstöd bör behålla den grundläggande funktionen hos ett standardgränssnitt för textbehandling samtidigt som man lägger till hanterings- och spårningsfunktionalitet. Verktyg som avviker från grundläggande aspekter av standardtextbehandling kastas snabbt i verkliga projekt. Detta innebär inte att användarna inte bör veta något om den underliggande databasen; tvärtom, när de arbetar med krav filtrering eller spårning, till exempel, måste de ha en djup kunskap om de underliggande logiska databasstrukturer. Verktyg måste också brottas med icke-textuell dokumentinformation. Det är till exempel svårt att spela in bildernas historia eftersom användarna vanligtvis bara spelar in en bilds förändringshistoria på bildnivå. Bildstorleken orsakar också allvarliga problem, och verktyg måste stödja komprimerade format (vilket de vanligtvis inte). Dessutom, eftersom användare alltid kommer att ha dokument som innehåller information utanför kravhanteringsverktygsdatabasen, bör du integrera kravhanteringsverktyg med dokumenthanteringssystem. Du kan bara uppnå detta på granulariteten av hela kravhanteringsdatabaser. Du bör också göra datainmatningen så bekväm som möjligt. Till exempel bör du erbjuda grafiskt stöd för redigering av specialiserade inmatningsformulär, som i vanliga databassystem. Slutligen kommer användarna aldrig att acceptera verktyg för kravhantering om de inte tillhandahåller flexibla, enkla att anpassa och effektiva dokumentgenereringsanläggningar som uppfyller givna standarder och kombinerar och filtrerar material av alla slag. Ingenjörer måste snabbt kunna producera båda sina huvudfunktioner Att införa databasbaserade kravhanteringsverktyg kan vara mest framgångsrika om de behåller ett dokuments utseende och känsla. Specificera dokument och de olika rapporter som ledningen begär. Det finns ingen tydlig gräns mellan specifikationer för tillverkarens krav och specifikationer för leverantörssystem. På tyska finns det en tydlig skillnad mellan Lastenheft (bokstavligen "efterfrågans häfte") och Pflichtenheft ("duty booklet"). Som figur 2 visar tillhandahåller kunderna det första dokumentet, som definierar vad de vill (kundens krav), och entreprenörerna tillhandahåller det andra dokumentet, vilket förklarar hur de ska bygga systemet (entreprenören uppgifter). Vid första anblicken är de engelska motsvarigheterna till dessa dokument specifikationerna för användarkrav och specifikationerna för systemkrav. I dokumentet om användarkrav sägs det att det talar om vad problemet är, medan dokumentet om systemkrav bör beskriva lösningen. I den verkliga världen är dock saker och ting inte så enkla eftersom kundernas krav inte är begränsade till problemet utrymme. Särskilt inom fordonssektorn finns det flera goda skäl för kundbeskrivningar att gå längre än till problemområdet: I Ett system är typiskt uppdelat i delsystem och komponenter som olika leverantörer tillhandahåller. DaimlerChrysler måste se till att olika leverantörers komponenter samarbetar för att specificera delar av en helhetslösning. I När vi försöker separera programvara från hårdvara saker blir ännu svårare. Vi måste specificera en enda komponent som två interaktiva "problem" - ett hårdvaruproblem och ett programvaruproblem. I många situationer kräver DaimlerChryslers första-till-marknadsstrategi att vi definierar vissa specifikationer för dokumentfunktioner i så detalj som möjligt, vilket kan vara en konkret algoritm. Ofta måste DaimlerChrysler fastställa den framtida standarden genom att ange lösningar istället för problem. I vissa situationer kan det till och med vara en utmaning för RE-experten och domäningenjören att avgöra om ett visst krav ska ingå i kundkravsdokumentet. Redundancy orsakar bra ingenjörer att lida, och de resulterande systemen kommer förmodligen också att lida. I stora projekt, såsom utveckling av elsystem för fordon, skapar ingenjörer samtidigt flera hundra långa specifikationer och tillhörande dokument (upp till flera hundra sidor vardera) under snäva tidsfrister. Det är inte förvånande att dessa dokument normalt innehåller överflödig information. Dessutom är beroendet av sådana dokument komplicerat och förblir delvis ogenomskinligt på grund av både tidsbristen och antalet dokument och personer som berörs. Nackdelarna här är uppenbara: Denna form av uppsägning leder till inkonsekvenser och dubbelarbete. I värsta fall härrör specifikationsdokument från ogiltiga lokaler. Detta är ett besvärligt problem eftersom dokumentstrukturer ofta har utvecklats och vunnit acceptans under många år. Dessutom speglar dokumentstrukturen vanligtvis organisatoriska strukturer och till och med (i vårt fall) hela bilbranschens struktur. Det är därför svårt att ändra dokumentstrukturen för att undanröja uppsägningar, och det förekommer ofta en negativ kompromiss mellan insatser och resultat. Enligt vår erfarenhet är det ett stort steg att få en överblick över projektuppsägningar. Detta gör ingenjörerna medvetna om de delar av deras dokument som används eller utarbetas någon annanstans. De kan sedan bestämma sig för att synkronisera om det behövs. Innehållet orsakar inte lidande för bra ingenjörer, men innehållspresentation kan skapa problem. Inom fordonsområdet bygger vi vanligtvis system i steg snarare än från grunden: En ny bilserie ärver de flesta funktioner från befintliga, med olika anpassningar, förlängningar eller innovationer. Den nya vindrutetorkaren är i princip bara en annan (och ännu bättre!) Vindrutetorkare. På denna nivå finns det därför ingen formell incitamentsfas eftersom utvecklingen av en ny komponentversion vanligtvis innebär få relaterade aktiviteter. Vi har funnit att bra ingenjörer är främsta ligan experter på sina specialiserade områden och har djupa insikter i subtiliteter och fallgropar krav innehåll. För dem är innehåll och domänkunskap inget betydande problem. Dock erbjuder innehållspresentation och strukturering utmaningar. Ofta beskriver ingenjörer specifikationer på ett ostrukturerat sätt, vilket ökar kommunikationsansträngningen. En väldefinierad RMI som genomförs med hjälp av ett verktyg för kravhantering kan dock bidra till att förbättra innehållsstruktur och presentation. Till exempel kan det driva ingenjörer att bryta upp långa specifikationer punkter i atomiska krav. Återanvändning är en annan förbättringspunkt. I dag är de flesta specifikationerna återanvändning ad hoc och implicit, vilket påverkar effektivitet och kvalitet. Det största problemet med detta tillvägagångssätt är dock att en bra specifikation helt och hållet beror på en ingenjörs avancerade expertis inom området. Som ett alternativ föreslår vi systematisk återvinning av befintliga specifikationer som ett uttryckligt steg i specifikationsprocessen. [8] [9] [10] Slutligen, när du inför en databas för kravhantering, måste du migrera befintliga dokument till systemet så att de är tillgängliga för återanvändning i framtida projekt. Även om kravhanteringsverktyg stöder vissa automatiska fånga, enligt vår erfarenhet, migrationsprocessen kräver fortfarande betydande manuellt arbete. Våra processrelaterade erfarenheter inkluderade utmaningar med abstrakta specifikationer, icke-funktionella krav, förändring, anpassningsbara vyer och recensioner av specifikationen. Detaljerad specifikation omfattar normalt endast bladen på systemets sönderdelningsträd. Ingenjörerna kan inte utveckla ett komplext system, t.ex. en modern telematikenhet, enbart genom att tala om och hantera de systemkrav som utgör en lågnivåspecifik, detaljerad komponentspecifikation. Tvärtom är det oundvikligt att utveckla komplexa system uppifrån och ner i flera lager av granularitet. När det gäller RE, håller denna observation fortfarande. Tyvärr är den systematiska behandlingen och dokumentationen av krav på högre nivå och beslut om utformning i dag otillräcklig. Men om ingenjörer inte dokumenterar dessa höga krav och motiv, de bygger sina detaljerade krav på sand: Vissa kommer att utmanas regelbundet eftersom de är svåra att motivera (även om de kan vara av central betydelse); andra är helt överflödiga men fortfarande finns (som kravet någon härrör från två år sedan från en senare suspenderad lagstiftning). Sist, men inte minst, välstrukturerade krav och designbeslut på flera abstraktionsnivåer är avgörande för att förstå ett detaljerat specifikationsdokument. Det finns många beskrivningsmetoder, bland annat målträd, funktionslistor, användningsfall, diagram över meddelandesekvenser och tillståndsmodeller. Utmaningen är att definiera en domän- eller organisationsspecifik modell. I detta syfte har vår egen forskning främst fokuserat på användningsfall. [11] [12] [13] Icke-funktionella krav, acceptanskriterier och testfall Ingenjörerna klarar inte av att hantera icke-funktionella krav, acceptanskriterier och testfall. Varje ingenjör på DaimlerChrysler förstår betydelsen av acceptanskriterier, testfall och icke-funktionella krav. Tyvärr, även i projekt med lämpliga resurser, uppfyller faktiska specifikationsdokument sällan motsvarande krav eftersom det är svårt att komma fram till rimliga acceptanskriterier och lämpliga testfall för funktionskrav. När det gäller icke-funktionella krav är situationen ännu svårare. Från vår erfarenhet, skriva god acceptans kriterier är helt enkelt en fråga om praktik och personlig erfarenhet. Det bästa sättet att förbättra acceptanskriterierna är därför att välstrukturerade krav och designbeslut på flera abstraktioner är avgörande för att förstå ett detaljerat specifikationsdokument. ge konkreta exempel på funktionella krav och få ingenjörer att utnyttja och återanvända dessa exempel. I grund och botten är detta bara ytterligare ett argument för att främja systematisk återvinning av krav. När det gäller icke-funktionella krav är det svårt att styrka att postulera en kvalitet som underhållbarhet. I allmänhet är motsvarande acceptanskriterier och testfall antingen obefintliga eller alltför akademiska-"90 procent av alla underhållsjobb bör ta mindre än fem minuter," till exempel-så dessa krav är praktiskt taget meningslösa. När det är möjligt visar vår erfarenhet att du stegvis bör förfina icke-funktionella krav tills du kan implementera dem som en uppsättning funktionskrav. Förändring och diskussioner om förändring är en del av det dagliga projektlivet och det finns inget sätt att ändra på det. Alla typer av förändringar sker under projekt, inklusive sena och helt oväntade sådana. Du kanske kritiserar förändringen, men vi tycker att det är naivt. Så länge som förändringar är motiverade och tekniskt genomförbara kommer de att ske. Följaktligen måste du se till att du rimligen kan hantera sena och oväntade förändringar. Bland de möjliga ändringarna i ett projekt finns ändringar i system, tillämpning och komponentkrav; ändringar i RMI, schema, ansvar och leverantörer; och även förändringar i processer och verktygsmiljö. En viktig bakomliggande orsak till förändringsfrekvensen är den ökande komplexiteten, parallelliseringen och tidsbegränsningarna för utvecklingsprojekt. Dessa faktorer tvingar utvecklare att införa fler och fler antaganden om systemet tidigt i utvecklingen. De utmanar sedan ofta eller omarbetar dessa antaganden när systemet mognar. Vi kunde begränsa RMI-ändringarna till väsentliga ändringar genom att upprätta standard RMI:er för projekt och minimera icke-väsentliga anpassningar. Vi fann också att förändringsförslag förekommer mycket oftare än faktiska projektändringar (och de ökar vanligtvis sent i utvecklingen). Som tekniska experter måste ingenjörer snabbt formulera åsikter om förändringsförslag. Om RE baseras på en lämplig RMI, kan ingenjörer utvärdera en föreslagen ändrings potentiella effekter baserat på dokumentation av relationer mellan krav och motsvarande attribut. Tyvärr hindrar bristen på lämpliga specifikationer analysen och spridningen av lokala förändringar som infördes sent i utvecklingsprocessen på de övre nivåerna av systemets nedbrytning. Detta minskar i sin tur återanvändbarheten av specifikationer i efterföljande projekt. Användaranpassade vyer är ett kraftfullt instrument för att styra och hantera specifikationsprocessen. Inom en komplex domän är RE en komplicerad, ständigt modifierad process med många olika aktiviteter. I de flesta projekt spelar människor olika roller med komplexa beroenden, och olika människor läser, ändrar, granskar, accepterar, eller släpper olika aspekter av specifikationen vid olika tidpunkter. Genom att tillhandahålla både användar- och situationsspecifika databasvyer kan du samordna och stödja RE-processen på en grundläggande nivå. I vissa projekt hjälpte verktyget för kravhantering också till med hantering av arbetsflöden (se figur 3). Automatiskt beräknade vyer är nyckeln till att få ingenjörer att anta ett nytt verktyg. För att få detta att fungera måste dock konceptet stödja två viktiga krav. För det första måste verktyget ge ett kraftfullt stöd för att definiera individuella vyer: Det bör stödja inte bara attributval och filtrering, men också automatisk informationsgenerering och systematisk informationsvisning, eventuellt genom flera länkning steg. Synpunkter bör också stödja användares åtkomsträttigheter. För det andra bör verktygen erbjuda stöd för visningshantering. Ingenjörer bör kunna programmera komplexa roll- eller fasberoende vyer för återanvändning över projekt. Standardiserade vyer kommer därmed att bli en del av RMI. Ingenjörer bör också enkelt kunna anpassa vyer eller skapa nya enkla vyer. De kan till exempel göra detta för att argumentera för någon punkt under diskussioner med ledningen eller under översynsmöten med leverantörer. Många ingenjörer är inte vana vid att utveckla sina dokument "offentligt" - och de gillar inte idén. Tänk på detta när det gäller användaracceptans, och överväga att låta ingenjörer arbeta i en privat del av databasen (åtminstone i tidiga uppgiftsstadier). Välorganiserad specifikation recensioner är viktiga för en framgångsrik tillverkare-leverantör relation. Informella och formella granskningar sker ofta i takt med att specifikationerna ständigt utvecklas. Dessa granskningar är viktiga för att garantera både specifikationens kvalitet och delsystemets kompatibilitet och utgör ibland den enda åtgärden för att garantera systemets övergripande kompatibilitet och integritet. Fordonsdomänen är komplex och ingenjörer ansvarar vanligtvis för flera komponentversioner i olika utvecklingsfaser. I en sådan miljö är det både ambitiöst och viktigt att etablera effektiva och effektiva utvärderingar. Enligt vår erfarenhet är effektiva kravhanteringsmetoder och lämpligt verktygsstöd nyckeln till en framgångsrik specifikationsgranskning. Tillvägagångssättet med en enda källa säkerställer att varje inspektör granskar samma version av granskningsartefakten. Rollspecifika vyer och attribut säkerställer att alla vet vad de ska göra och hur de ska göra det i varje fas. Vid granskningsmöten dokumenterar vi beslut på nätet. Vi förser även projektledningen med särskilda synpunkter för att kontrollera granskningsprocessen. Sist, men inte minst, kravhanteringsverktygets historikfunktioner låter oss spåra varje beslut och ifrågasätta dem när som helst. Denna typ av lämpliga krav ledningsstöd avsevärt förbättrar och underlättar översynsprocessen. Detta var en viktig försäljningspunkt när det gällde att övertyga både ingenjörer och projektledning om nyttan av systematiska kravhanteringsmetoder och verktyg. Våra tekniska erfarenheter omfattade utmaningar relaterade till spårbarhet, verktygsintegration och behovet av mer avancerade verktyg för kravhantering. Spårbarhet är ett bra inslag, men den verkliga utmaningen är att bestämma vilka spår som ska upprätthållas. Att införa tydlig spårbarhet lovar stora besparingar, 14, 15, men för att uppnå dem krävs en noggrann avvägningsanalys. Det finns olika potentiella länkar mellan objekt. Även om det är viktigt att koppla samman krav och relaterade föremål, krävs det insatser för att upprätthålla kopplingar som bör balanseras av fördelarna med spårbarhet. I detta syfte är vårt råd att i grund och botten överlåta dessa beslut till ingenjörerna, eftersom de vet vad de vill ha och vad de kan acceptera. Generellt sett är ingenjörerna till en början angelägna om att etablera och upprätthålla alla typer av spår, men senare misslyckas de med den disciplin som krävs för att göra det. Med denna observation i åtanke rekommenderar vi att du håller antalet explicita spår liten. Tekniskt sett finns det två sätt att uttrycka objektrelationer: I Explicit länkar, representerade av länkobjekt I Implicit länkar, såsom texthänvisningar integrerade i text (såsom, "se SR-123) eller konventioner (såsom, "kapitel 12 i dokument XX motsvarar kapitel 4 i dokument YY") RMI innehåller alla beslut om vilka objekt som ska spåras och om att spåra dem implicit eller explicit, och du bör exakt definiera dessa beslut under projektstart. Riktlinjer för utformning kan hjälpa dig att bemästra spårbarhet genom att definiera regler om vilka länkar du ska upprätta, hur de ska upprättas och när du ska uppdatera dem. När det gäller verktyg för kravhantering är deras länkstöd fortfarande otillräckligt. Mainstream verktyg stöder inte länkar som första klassens medborgare när det gäller länkar historia och attribut eller distribuerat arbete på länkar, till exempel. Kopplingar mellan textspecifikation och modelleringsverktyg är omogna och sällan använda. Välorganiserade specifikationer recensioner är viktiga för en framgångsrik tillverkare leverantör relation. Även om de flesta specifikationsaktiviteter fortfarande är dokumentbaserade kräver ett växande antal specifikationer komplexa modeller, såsom körbara analysmodeller, system- och programvarudesignmodeller och HMI-modeller. Detta kräver att ingenjörer utvecklar en specifikation med hjälp av två eller flera verktyg: ett verktyg för textspecifikationer och ett eller flera verktyg för modellorienterad analys och design. På grundval av kundens efterfrågan har verktygsleverantörer utvecklat skriptbaserade kopplingar mellan kravhanteringsverktyg och modelleringsverktyg. Vi fann dock att de flesta verktygskopplingar – som vanligtvis har sitt ursprung i ett specifikt projekt och som är utformade och betalda av en specifik kund – inte är tillräckligt mogna för seriös användning av utvecklingsprojekt. Flera av våra projekt började använda sådana add-ons men senare tappade dem, även om det skulle kräva betydande manuella insatser eller betydande processproblem. Bland de brister vi fann var I Speed. I ett genomsnittligt projekt kan antalet länkade objekt enkelt växa till flera tusen, vilket resulterar i oacceptabelt långsam kopplingshastighet (t.ex. vid beräkning av ändringar). I Integrerad dokumentgenerering. Befintliga verktygskopplingar stöder inte denna funktion, vare sig dokumenten är korta statusrapporter eller långa dokumentation som uppfyller en standardiserad struktur. Även om ett fåtal verktyg är dedikerade till integrerad dokumentgenerering, finns de bara i specifika leverantörers verktygssviter och är till stor del värdelösa utanför dem. I Användargränssnitt. Verktygskopplingar skapar vanligtvis redundanta editorer för hantering av information mellan verktyg (vanligtvis en för varje verktyg som berörs). I Automation. I de flesta verktyg är automationsnivån låg, det finns inget aktivt administrativt stöd, och användarna måste initiera synkronisering. Det finns inte heller något aktivt stöd för att peka på problem. För att pragmatiskt ta itu med dessa problem kan du utöka ett modellbaserat specifikationsverktyg för att hantera textspecifikationer (inklusive formatering, attribut, vyer, historik och baslinjer). Ett mer metodologiskt tillvägagångssätt är att fastställa designriktlinjer som håller text-modellen gränssnittet luta, tillåter länkar endast mellan vissa text- och modellelement, och först då under vissa processsteg. Enligt vår mening kommer den långsiktiga lösningen att komma från två håll: Tekniskt sett kommer XML-baserade metoder att möjliggöra mer systematiska, effektiva och enhetliga verktygskopplingar, och metodiskt kommer förbättringar att komma från ytterligare standardisering av krav och systemtekniska språk. I synnerhet bör insatserna för att förena ett enhetligt modellerat språk utvidgas från programvaruteknik till system- och kontrollteknikspråk för att minska den nuvarande djurparken med överlappande och äganderättsligt skyddade beteckningar. Dessutom, inklusive kravhanteringskoncept i UML kan sätta all specifikation-och systemarkitektur-relaterad information i en enda modell med enhetliga modellering begrepp. Verktyg för hantering av krav är det främsta instrumentet för att utnyttja metoder för förnybar energi, vilket innebär att de fortfarande måste förbättras. Många av våra utmaningar har varit verktygsrelaterade. Verktyg är viktiga eftersom de bidrar till att förbättra praxis och processer. När ingenjörer ber om bättre verktygsstöd har du en stor möjlighet att förbättra processer och rutiner i farten. Den uppenbara och allvarliga nackdelen är dock att om de förkastar ett verktyg på grund av bristfälliga funktioner eller prestanda, kommer de också att förkasta motsvarande processförbättringar. Stöd för verktyg för kravhantering innebär således både en möjlighet och en risk för förbättring av processen för förnybar energi. Med detta i åtanke, vi postulerar följande ytterligare krav för lämpliga kravhanteringsverktyg stöd: I För att utnyttja processförbättring och RE praxis antagande, kravhantering verktyg bör ge grundläggande arbetsflöde stöd, såsom kraftfulla filter och visa kapacitet och sofistikerad visningshantering. I RM-verktyg måste vara lätt anpassningsbara med hjälp av standardprogrammeringsspråk så att användarna snabbt kan inkludera ny funktionalitet. Annars kommer de att släppa verktyget eftersom verktygsleverantörer i allmänhet är för långsamma för att reagera på brådskande projektbehov. J a n u a r y / F e b r u a r y 2 0 0 3 I E E E S O F T W A R E 2 3 När ingenjörer ber om bättre verktygsstöd har du en fantastisk möjlighet att förbättra processer och praxis i farten. I-användare bör kunna styra verktyg offline via lämpliga API:er (eller åtminstone kommandoradsgränssnitt), så att de snabbt kan konstruera och anpassa verktygslänkar. Förutom dessa viktiga önskemål leder detaljerna ofta till att verktyg förkastas i det dagliga arbetet. Om det t.ex. tar åtta timmar för databasen för kravhantering att generera textdokument, är det osannolikt att den ingenjör som måste distribuera dokument regelbundet ger verktyget en utmärkelse. Upplevelserna vi beskriver är baserade på verkliga utvecklingsprojekt inom olika fordonsdomäner, det är inte förvånande att vi upptäckte en enorm och till synes olikartad variation av frågor. Många frågor rör kravhantering, oavsett innehåll. Många andra är relaterade till verktygsstöd för kravhantering. Å andra sidan kan det vara något förvånande att notera att vi hittade färre och säkert mindre framträdande problem i samband med specifikationen av faktiska kravinnehåll (dvs. krav framkallande och notation expressiveness), som båda är fokus för betydande arbete i RE-gemenskapen. Detta kan bero på att utveckla funktionalitet från grunden är undantaget snarare än regeln inom fordonsområdet, där ingenjörer måste ta en produktfamilj utvecklingsstrategi. Genom att utöka den befintliga funktionaliteten på ett evolutionärt sätt suddar de ut den akademiska distinktionen mellan problem och lösningsutrymme. Följaktligen har de byggt upp betydande mänsklig expertis om de faktiska komponenterna och deras funktionalitet. Dessa experter har vanligtvis inte något akut problem med att specificera vad systemet bör göra; deras problem är att hantera den ökande komplexiteten i specifikationsaktiviteter och artefakter. Många egenskaper hos fordonsdomänen gäller även andra komplexa systemtekniska domäner, särskilt inom områden som använder eller överväger produkt-familjeutveckling. Även om forskning om förnybar energi inte är aktuell kommer många av de frågor som vi tar upp här att vara av avgörande betydelse för att förbättra förnybar energi i framtiden.  Erkännanden 4 I E E S O F T W A R E h t t p : / / c o m p u t e r. o r g / s o f t w a r e Om upphovsmännen
Två utvecklare på Daimler AG angav följande utmaningar i en insiktsrapport REF: a) presentation av krav är ett problem, b) dagliga kravdiskussioner resulterar i eventuella ändringar och manuellt uppdateringar av spårlänkar, och c) kopplingen mellan dokument- och modellbaserade verktyg saknar automatisering.
Requirements Engineering in Automotive Development: Experiences and Challenges
{'venue': 'IEEE Software', 'journal': None, 'mag_field_of_study': ['Computer Science']}