Boken Requirements Engineering Fundamentals
Jag läste just den trevliga och ganska korta Boken Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam: Foundation Level av Klaus Pohl och Chris Rupp från Rockynook Computing. Den ligger på 196 kr på adlibris (se [1]) och 34$ på amazon (se [2]). ISBN: 9781933952819.
Lite bakgrund
2006 skapades IREB (International Requirements Engineering Board - se wikipedia [3]) som vill vara för requirements engineering det ISTQB är för software testing. Precis som ISTQB kan certifiera mjukvarutestare kan IREB certifiera kravingenjörer i något de kallar CPRE (Certified Professional for Requirements Engineering).
Som referens inför examinationen till att bli CPRE på basnivå skrev Klaus Pohl och Chris Rupp den här boken.
Det finns även en konkurrerande certifiering med liknande namn: Reqb Certified Professional For Requirements Engineering
Överblick
Boken Requirements Engineering Fundamentals är en kort bok - 163 sidor plus 18 sidor förord. Det är dessutom en ganska ny bok i sin första upplaga.
När jag skriver denna text har boken bara två reviews på Amazon. Båda ger boken full poäng men är inte så nyanserade. Jag kan hålla med om att det är mycket bra med boken - men jag har också hittat en del negativa saker.
The Bad
Boken är skriven av två tyskar som är experter på krav och ibland luktar det tysk grå ingenjör om boken. Ibland refererar den till begrepp på tyska när det är lite för svårt att förklara på engelska - till exempel är det bra att ha Sprachgefül (språkkänsla) när man skriver krav. En annan egenskap som känns väldigt tysk är att boken är hårt organiserad i kapitel, under-kapitel och under-under-kapitel. Jag roade mig med ätt räkna antalet totala antalet kapitel, under-kapitel och under-under-kapitel och det är nästan 160 stycken indelningar. Detta i en bok på strax över 180 sidor - ni förstår kanske att jag tycker att indelningen är lite överorganiserad.
Jämfört med Boken Software Testing Foundations (också från förlaget Rocky Nook Computing) som också utger sig för att vara en studieguide inför en certifiering (som jag tyckte var lite för tunn för det) så är denna bok en ännu klenare hjälp inför examinationen. Den saknar helt en begrepps- och ordlista, och har inte heller instuderingsfrågor. Boken Software Testing Foundations har en utmärkt ordlista och en lång rad frågor.
Vidare så är del bilder inte toksnygga - det luktar ibland lite MS Paint. Jag saknar även konkreta tips på bra verktyg som stöd till requirements engineering i kapitlet om verktyg - det man fick var dock en länk till en sida som ska lista verktyg.
The Good: fyra saker jag tar med mig
Boken är som sagt lagom lång, den ger ett bra svep över disciplinen requirements engineering utan att gå in för djupt på något område. Vill man fördjupa sig får man hitta ett par böcker till.
Det är speciellt fyra saker jag kommer ta med mig. Det handlar om en insikt i hur man kan indela krav i olika typer, en aha-upplevelse om kreativitetsövningar, olika nivåer på spårbarhet och att det är svårt att få ur vettiga krav ur folk:
- Boken visar att det oftast finns tre typer av krav (som kan hanteras på olika sätt): functional requirements, quality requirements (eller ibland non-functional requirements) och constraints.
- functional requirements: till exempel att systemet skall kunna göra X.
- quality requirements: till exempel att systemet skall stödja N samtidiga användare, eller systemet skall i 95% av fallen ha en svarstid på under 1 sekund, men aldrig en svarstid på över 4 sekunder.
- constraints: till exempel att systemet skall implementeras som webbservice i Fortran, eller att systemet skall vara implementerat och klart inom N månader.
- En del brainstorming kan vara dålig, och man kan ibland försöka brainstorma om sådant som absolut inte får hända istället för att försöka brainstorma om det systemet skall klara.
- Det är svårt att få ur krav ur folk. Till exempel kan en del saker vara så självklara att man glömmer kravställa det. För att visa att man inte bara kan samla in krav så används begreppet requirements elicitation (se också wikipedia [4]). Ordet elicitation var nytt för mig så jag slog upp det och Wiktionary (se [5]) definierar verbet elicit som:
- To evoke, educe [...] to generate, obtain, or provoke as a response or answer.
- To draw out, bring out, bring forth (something latent); to obtain information from someone or something. [...]
- To use logic to arrive at truth; to derive by reason; deduce; construe.
- Spårbarhet finns i flera nivåer och inte bara, som jag är van vid, från ett krav till ett test. Exempel som används i boken (i till exempel figur 8-6) är:
- Från stakeholders till krav
- Från dokument (standarder, policys etc) till krav
- Från ett krav till ett annat krav
- Från krav till designdokument
- Från krav till implementation
- Från krav till test
Innehåll
Boken är föredömligt indelad i åtta kapitel (plus introduktion, förord, index och referenser) som täcker det jag själv sett av kravhantering tidigare samt lärde mig en hel del nyttigheter. Kapitlen handlar om:
- Introduction and Foundations
- Introduction
- Fundamentals of Communication Theory
- Characteristics of a Requirements Engineer
- Requirement Types
- Importance and Categorization of Quality Requirements
- System and Context Boundaries
- System Context
- Defining System and Context Boundaries
- Documenting the System Context
- Summary
- Eliciting Requirements
- Requirements Sources
- Requirements Categorization According to the Kano Model
- Elicitation Techniques
- Documenting Requirements
- Document Design
- Types of Documentation
- Document Structures
- Using Requirements Documents
- Quality Criteria for Requirements Documents
- Quality Criteria for Requirements
- Glossary
- Documenting Requirements in Natural Language
- Effects of Natural Language
- Requirement Construction using Templates
- Model-Based Requirements Documentation
- The Term Model
- Goal Models
- Use Cases
- Three Perspectives on the Requirements
- Requirements Modeling in the Data Perspective
- Requirements Modeling in the Functional Perspective
- Requirements Modeling in the Behavioral Perspective
- Requirements Validation and Negotiation
- Fundamentals of Requirements Validation
- Fundamentals of Requirements Negotiation
- Quality Aspects of Requirements
- Principles of Requirements Validation
- Requirements Validation Techniques
- Requirements Negotiation
- Requirements Management
- Assigning Attributes to Requirements
- Views on Requirements
- Prioritizing Requirements
- Traceability of Requirements
- Versioning of Requirements
- Management of Requirements Changes
- Tool Support
- General Tool Support
- Modeling Tools
- Requirements Management Tools
- Introducing Tools
- Evaluating Tools
Sammanfattning
Jag tycker att Boken Requirements Engineering Fundamentals av Klaus Pohl och Chris Rupp ska läsas av alla som jobbar i projekt - vare sig det är projekt som jobbar agilt, mer RUP, med V-modellen eller mer åt vattenfalls-hållet. Detta för att krav är svårt. Det är svårt att ställa krav, det är svårare att ställa rätt krav, och det är ännu svårare att implementera ett system utifrån bortglömda krav. Det är dessutom dyrt med krav: jämfört med att tidigt få in ett korrekt krav så kan ett bortglömt eller felaktigt krav kosta upp till 100 gånger så mycket. Det är en sanslöst stor skillnad.
Varför ska man då läsa just den här boken om krav och inte någon annan? Det kan jag tyvärr inte ge ett entydigt svar på - jag tycker denna bok är komplett och kort, men den har vissa brister. Andra böcker kanske passar din smak bättre - men välj då en som minst täcker det den här boken täcker.
Se också Boken Requirements Engineering som ämnar täcka i princip samma målgrupp
Se också Boken Software Testing Foundations
Se också Boken Agile Testing
Se också Systems Modeling Language
Se också Kravhantering Övningsuppgifter
Se också Reqb Certified Professional For Requirements Engineering
Denna sida tillhör Kategori Mjukvara
Denna sida tillhör Kategori Test (typ)
Tillhör Kategori Boktips