Chapter 4 Requirements Engineering Letizia Jaccheri Professor Institutt for Datateknikk (IDI) Office 106, tel. (735)93469, letizia@idi.ntnu.no www.letiziajaccheri.org Course home page http://www.idi.ntnu.no/emner/tdt4140/ Slides made by Sommerville adapted by Letizia Jaccheri, all chapter is part of the syllabus This lecture will NOT be filmed Chapter 4 Requirements engineering 1
Topics covered structure Requirements User and System Functional and nonfunctional The software requirements document Requirements engineering processes Elicitation and analysis Validation Management Questions to Expert Software specification Software development Software validation Software evolution Chapter 4 Requirements engineering 2
Krav: Hva? beskriver Systemtjenester (Funksjoner) Begrensninger av hvordan systemet brukes og utvikles (ikke funksjonelle) abstraksjonsnivå høyt nivå detaljert matematisk -- grunnlag for et bud på en kontrakt - må derfor være åpen for tolkning; grunnlag for selve kontrakten - derfor må defineres i detalj Chapter 4 Requirements engineering 3
Hvem Figure 4.6 Customer specify & propose changes Manager plan a bid and process System (software) engineer understand what to develop Test engineer define and run tests Maintenance engineer understand the sytstem to implement changes User ++ Chapter 4 Requirements engineering 4
Types of requirement Requirements Statements in natural language plus diagrams User of the services the system provides and its operational constraints. System detailed descriptions of the system s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. Chapter 4 Requirements engineering 5
Non-functional requirements definerer systemegenskaper og begrensninger f.eks pålitelighet, responstid og lagringsbehov. Prosesskrav kan også spesifiseres, f.e. IDE, programmeringsspråk eller utviklingsmetode. Ikke-funksjonelle krav kan være mer kritisk enn funksjonelle krav. Hvis disse ikke er oppfylt, kan systemet bli ubrukelig. Chapter 4 Requirements engineering 6
Types of nonfunctional requirement Chapter 4 Requirements engineering 7
Metrics for specifying nonfunctional requirements Figure 4.5 Property Speed Size Ease of use Reliability Robustness Portability Measure Processed transactions/second User/event response time Screen refresh time Mbytes Number of ROM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems Chapter 4 Requirements engineering 8
Requirement Process Elicitation and Analysis Requirements discovery Interacting with stakeholders to discover their requirements and domain requirements. Requirements classification and coherent organisation Prioritisation and negotiation (conflicts resolution) Requirements specification (documentation) Validation Management Eksam: list 3 techniques for requirements discovery Chapter 4 Requirements engineering 9
Interviewing TDT4180 Menneske-maskin interaksjon elicitation Formal or informal interviews Types of interview Closed interviews based on pre-determined list of questions Open interviews where various issues are explored with stakeholders. Effective interviewing Be open-minded, avoid pre-conceived ideas about the requirements and are willing to listen to stakeholders. Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system. Chapter 4 Requirements engineering 10
Scenarios Scenarios are real-life examples of how a system can be used. They should include start tilstand/situasjon; den normale flyt av hendelser; hva som kan gå galt; informasjon om andre samtidige aktiviteter; stopp tilstand (når scenariet er ferdig)
Ethnography Social science method: observing and analysing how people actually work. Advantages: People do not have to explain or articulate their work. Social and organisational factors of importance may be observed. Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models. Ethnography is effective for understanding existing processes Disadvantages: cannot identify new features that should be added to a system. Time consuming ethnography + prototyping Prototype development results in unanswered questions which focus the ethnographic analysis. Chapter 4 Requirements engineering 12
Requirements Validation 1. Validity. Gir systemet funksjonene som best støtter kundens behov? 2. Consistency. Konflikter mellom forskjellige krav? 3. Completeness. Er alle funksjoner som kreves av kunden inkludert? 4. Realism. Kan kravene bli implementert gitt tilgjengelig budsjett og teknologi 5. Verifiability. Kan kravene bli sjekket? Chapter 4 Requirements engineering 13
Review Teknikker Systematic manual analysis of the requirements. Prototyping Test-case generation questions Q1: Is the req. realistically testable? Q2: Is the req. properly understood? Q3: Is the origin of the req. clearly stated (Traceability)? Q4: Can the req. be changed without a large impact on other requirements (Adaptability)? Eksamen spørsmål: Din gruppe har 1 dag for å fullføre validering av krav. Hvordan foreslår du at arbeidet blir gjennomført? Chapter 4 Requirements engineering 14
Requirements management administrere endring av krav under spesifikasjon og utvikling. Nye krav fremstå mens system er under utvikling, og etter det har gått i bruk. opprettholde forbindelser mellom avhengige krav Roller Software engineering de som betaler for et system (kunder) brukere av dette systemet Human Computer Interaction Software (Systemarbeid og menneske-maskin interaksjon) Chapter 4 Requirements engineering 15
Conclusions and questions to industry Bruker-og systemkrav Hvordan ser kravdokument ut? Tekst eller diagrammer? Standarder f.eks IEEE-standarden? Prosess elicitation og analyse validering (prototyping, test generasjon, gjennomgang)? Endringsledelse change management Er dette en funksjonell krav? «Hver medarbeider bruker systemet skal være entydig identifisert av hans eller hennes 8-sifret ansattnummer» Chapter 4 Requirements engineering 16