Lecture 1: Sign-up, Introduction

Welcome to ETS170 Requirements Engineering (Kravhantering) http://cs.lth.se/ets170/ Lecture 1: Sign-up, Introduction Björn Regnell Course head Lectures Examination Elizabeth Bjarnason Course coordinator, Exercises, Project, Lab Examination Johan Linåker Project, Lab Lena Ohlsson Course secretary Room E:2179 09:30-11:30 12:45-13:30

Recent cs.th.se doctoral theses in Requirements Engineering supervised by Professor Björn Regnell Elizabeth Bjarnason Integrated Requirements Engineering Understanding and Bridging Gaps within Software Development Doctoral Dissertation, 2013, ISBN 978-91-7473-732-5 Krzysztof Wnuk Visualizing, Analyzing and Managing the Scope of Software Releases in Large-Scale Requirements Engineering Doctoral Dissertation, 2012, ISBN 978-91-976939-7-4 Richard Berntsson Svensson Supporting Release Planning of Quality Requirements: The Quality Performance Model Doctoral Dissertation, 2011, ISBN 978-91-976939-4-3

Requirements Engineering (RE) RE means to...... dig up, understand, write down, check, prioritize, decide, follow up Kravhantering innebär att gräva fram, förstå, skriva ner, kolla, prioritera, besluta om, följa upp... the features of (software) products... (mjukvaru-) produkters egenskaper

You will soon be working as an engineer

- I took the requirements engineering course at LTH in 2004, and it was so interesting that I have focused my entire career on requirements and project management. Lessons from the course text book and my experiences from the course project are still with me every day :) Hannes Lindbeck Requirements specialist, Project Manager, Outsourcing specialist at Sogeti

Economic consequences of requirements engineering problems Cost of correcting a problem Req Design Coding System Testing Acceptance Testing Operation [Davis, 1992]

Course contents 7,5 credit points 8 lectures (W1 Mon+Thu, W2 Mon+Thu, W3, W4, W5, W7) Give overview and structure (not all theory is covered) Scala crash course + reqt scripting L4 in W2 Guest lecturer: Hampus Jacobsson L5 in W3 Mandatory project examination L8 in W7 5 exercises (W1-5 Tue or Wed, sign-up list today) How to use the theory in the project, prepare for the written exam Sign up for one exercise time slot ideally with your project team! Computer Lab sessions (W3, W5, sign-up list later) Focus on computer tools, preparations mandatory Project (3 credit points ~ 80 h per person, 6-8 persons, sign-up list today) Purpose: to apply theory in practical work You act as both customers AND developers Written exam on all literature (4,5 credit points) Literature: Lauesen + compendium Compendium is sold at the CS expedition by Lena Ohlsson 12:45 60 SEK please bring even money Bonus points for the exam, based on 2 optional hand-ins. Max 10 bonus points on first exam if you hand in good exam problems proposals Hand in survey after the break Hand-outs: course program + introduction survey

Examination Project grade (Fail,3,4,5); groups based grade Labs (Fail, Pass); graded in pairs based on preparations and examination at the lab Written exam; individual grade. Total 100p; 50p is required for pass 2 optional hand-ins of exam problem proposals, in groups, can bring max 10 bonus points to the written exam if good Final grade (Fail,3,4,5); mapped from exam points with limits based on project grade...

Final grade

100 90 80 70 60 50 40 30 20 10 0 ETS170 HT2014 Tenta 1 3 5 7 9 1113151719212325272931333537394143454749515355575961 Tenta Bonus 5 43% UK 8% 3 10% 4 39%

http://reqt.org A scalable requirements modeling tool Turns requirements models into structured code Especially developed for this course Implements important concepts from the literature Produces documents for hand-ins via auto-generated html, latex, pdf Integrates with Google docs, Excel, Word etc via txt, html and csv Integrates with version mgmt. cloud services, e.g GitHub, Bitbucket Implemented in the Scala language enabling powerful scripting reqt&scala tutorial Th W2 @10-12 in MA:05 Used at labs: (1) Reqts Modelling, (2) Reqts Prio+Release Planning Discuss in your project if/how you want to use reqt

Inlärningsmål: Kunskapsmål English version in course program 1. definiera grundläggande begrepp och principer inom kravhantering 2. redogöra för ett flertal olika typer av krav 3. redogöra för och värdera ett flertal olika metoder och tekniker för kravhantering 4. beskriva och relatera olika delprocesser inom kravhantering 5. beskriva kravhanteringsprocessens relation till övriga processer i produktlivscykeln 6. redogöra för kravhanteringens relation till marknadsorienterad produktledning 7. diskutera några forskningsresultat inom kravhanteringsområdet

Inlärningsmål: Färdighetsmål English version in course program 1. kunna välja lämplig kravhanteringsteknik för sammanhanget kunna använda flera olika tekniker för att... 2. elicitera (identifiera) 3. specificera 4. validera 5. prioritera... krav

Inlärningsmål: Attitydmål English version in course program 1. medvetet kunna välja arbetssätt efter hur kravbilden ser ut 2. visa prov på ett systematiskt och långsiktigt arbetssätt 3. medvetet kunna problematisera över kravkvalitetens påverkan på slutproduktens kvalitet 4. på ett adekvat sätt kunna involvera användare i kravprocessen 5. medvetet kunna problematisera över kravhanteringens relation till ekonomiska aspekter i produktutveckling

Kursinnehåll English version in course program 1. Krav på olika abstraktionsnivåer och i olika sammanhang 2. Kravhanteringens delprocesser och deras relation 3. Specificering av datakrav, t ex med virtuella fönster och datamodeller 4. Specificering av funktionella krav, t ex med egenskapskrav och uppgiftsbeskrivningar 5. Specificering av olika typer av kvalitetskrav (icke-funktionella krav), t ex användbarhet, prestanda, och tillförlitlighet 6. Olika tekniker för elicitering, t ex fokusgrupper, prototyper 7. Olika tekniker för validering, t ex granskningar 8. Olika tekniker för prioritering, t ex parvisa jämförelser 9. Marknadsorienterad kravhantering, produktledning och prioritering

Project organization Another team is your customer Project Mission System Requirements Your team Work as customer 20% Work as developer 80% Project Mission Another team is your developer System Requirements Project Supervisor

Project 6-8 persons per project Sign-up list for project teams during the break Mandatory project exam L7, Mon W7, starting 10:05 sharp This week W1 you shall create a Project Mission to be delivered latest this Friday at 09.00 via email To: elizabeth@cs.lth.se ; johan.linaker@cs.lth.se ; bjorn.regnell@cs.lth.se ; Subject: [ETS170] Team X: PM v1 The Project Mission shall fit on one A4 page an be in.pdf-format It shall contain a project title and name + email of all group members Check out examples from previous years at the course web site All subsequent project hand-ins are sent to your project supervisor assigned to your group by Monday W2 Next Monday at lecture L3 you will choose Project Mission. The choice order is randomized. You cannot choose your own PM.

What is a good Project Mission? You have a deep knowledge of the domain You have a genuine interest in the system You can evaluate detailed requirements on the system The mission has a large scope of interesting possibilities As customer you act as: Key Customer Your are one of many potential customer. The development team owns the product and decides on priorities and product content, while your team gives input and provides feedback.

Project deadlines Iteration 1 Iteration 2 Iteration 3 Project Mission v1 PM v2 R1 R2 R3 W1 Fri W2 W3 Mon Meeting w supervisor W4 Mon Meeting w supervisor W6 Mon Meeting w supervisor W7 Fri

Project Roles P3RM Project, Process, Prioritization, and Release Manager (1) SCCVM Stakeholder, Customer Communication and Validation Manager (1) TDEVM Tools, Documents, Experiences and Version Manager (1-2) EPM Elicitation and Prototyping Manager (1-2) QRM Quality Requirements Manager (1) DRM Data Requirements Manager (1)

Discussion to activate prior knowledge What was realistic or unrealistic with the requirements engineering you did in previous project courses? What different types of requirements did you encounter? Vad var realistiskt eller orealistiskt med den kravhantering ni varit med om i tidigare projekt (tex i PUSS-kursen)? Vilka olika sorters krav stötte ni på?

Actions during the brake 1. Sign up on a project team 2. Sign up on exercises (whole team!) 3. Fill in the introductory survey and hand it in after the break

Intro to the theory part of the course Motivation The role of Requirements Engineering (RE) Basic concepts Different types of RE Different types of requirements (reqs) Reqs at different abstraction levels Motivering Kravhanteringens roll Grundläggande begrepp Olika sorters kravhantering Olika sorters krav Krav på olika abstraktionsnivå Lau 2014 Compendium

READ THE READ THE TEXT BOOK LITERATURE!!!

GO TO READ THE TEXT BOOK EXERCISES!!!

Basic terminology Lausen: A requirement specification is a document that describes what the system should do. What is what and what is how? Always a document? What is the system? How much about the domain?

Definition enl. IEEE [1990] A requirement is: (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. (3) A documented representation of a condition or capability as in (1) or (2).

What are requirements? Requirements are similar to shopping lists You can't always get what you want... You often want things you don't need...

What is a req? Önskemål Wish Måste Must Begränsning Constraint Idé Idea Kvalitet Quality Behov Need? Produktegenskap Feature Funktion Function Dokumenterad representation Documented representation Beslut Decision

Requirements Entities Examples from the reqt metamodel Product, Interface, Stakeholder, Idea, Goal, Feature, Data, Function, State, Event, Quality, Design, Scenario, Story, UseCase, Risk, Release, Issue, Test, Variant, Req

Requirements Engineering Important sub-processes: Elicitation to identify the requirements Specification to document the requirements Validation to check the requirements Prioritization to select the best requirements These processes are interdependent and are best done iteratively, in parallel and continuously. When are we ready?

The Requirements Engineering process is also a... Learning process... Intelligence process... Decision process... Innovation process

Example: MOBILE VENDOR X Where do requirements come from? Who are the stakeholders?

External stakeholders Customers Direct customers Operators Global customers Regional customers Other key customers Retailers Indirect customers Consumers Market segments Service providers Content providers Product providers Direct Competitors Mobile phone developers Indirect Competitors Cameras Mobile music players consumer wallet competition Platform providers Operating Systems Technical Platforms Network system providers Standardization bodies Legislation and authorities National International Manufacturing sub-contractors Component providers find the right person to talk to get the deep domain knowledge Internal stakeholders Marketing Long term branding Customer relations Product management Product planning Roadmapping and portfolios Product development Hardware design Electronics Analog Digital Mechanics Software design User interface Service logic Network access Codecs Platform development Mother, daughters, cluster Global functions Sub-contracting management Technical platforms Operating systems Original Design Manufacturing Technology forecasting Market research Customer Services Support Repair Legal Sourcing Accessories

SW Value chains are getting more and more complex...

Software Ecosystems

Orders of magnitude in Requirements Engineering Abrev. Level Order of magnitude Managing a complete set of interdependencies SSRE MSRE LSRE VLSRE Small-Scale Requirements Engineering Medium-Scale Requirements Engineering Large-Scale Requirements Engineering Very Large-Scale Requirements Engineering ~10 reqs requires small effort. ~ 100 reqs is feasible but requires large effort. ~1000 reqs is practically unfeasible, but feasible among small bundles of requirements. ~10000 reqs among small bundles of requirements is unfeasible in practice.

Dealing with very large sets of requirements Requirements Database Too much Profitable? Strategic? Ambiguous? Related? Group? Complete? Split? Reject? Expensive?

Different contexts and project types In-house Internutveckling för egna behov Product Development Produktutveckling för öppen marknad, t.ex. inbyggda system, generella appar för en marknad (COTS), etc. Time & Materials Utveckling på löpande räkning, rörligt pris Commercial Off-The-Shelf software (COTS) purchase Inköp av generisk (hyll-) programvara Customization Kundspecifik anpassning av generisk programvara Tender Anbudsförfrågan Customer specific: för upphandling av kundspecifik utveckling Generic (COTS): för upphandling av generisk programvara Contract development Kontraktsbaserad utveckling med fast/rörligt pris Sub-contracting Underleverantörskontrakt med fast/rörligt pris Unknown, pre-study Okänd, förstudie för att utreda lämplig projekttyp Hybrid kombinationer av ovanstående...? The context is critical to the requirements engineering!

Fig 1.2 Project types Project types Customer Supplier In-house User dept. IT dept. Prod. devel. Marketing SW dept. Time & materials Company SW house COTS purchase Company (Vendor) Tender Company Supplier Contract devel. Company SW house Sub-contracting Supplier SW house Unknown Inhouse? COTS? Internutveckling för egna behov (In-house) Produktutveckling för öppen marknad (Product Dev.) Utveckling på löpande räkning (Time&Materials) Inköp av generisk (hyll-)programvara (COTS purchase) Kundspecifik anpassning av generisk programvara Anbudsförfrågan (Tender) för upphandling av kundspecifik utveckling för upphandling av generisk programvara Kontraktsbaserad utveckling med fast/rörligt pris Underleverantörskontrakt med fast/rörligt pris Okänd förstudie för att utreda lämplig projekttyp Hybrider kombinationer av ovanstående Sammanhanget är avgörande för kravhanteringen! From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

Mutual relationship customer - supplier Who has the power? Who has the knowledge? Who takes the biggest risk? Wo takes the biggest profit? In the short term? In the long run? Mutual benefit?

Fig 1.1 The role of requirements Stakeholders Demands Elicitation Tacit demands & reqs Analysis Reqspec Contract Tracing: Forwards... Backwards... Req. management: Changing reqs From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 Design Program Test Op & maint

Fig 1.3 Contents of ReqSpec User groups Interfaces System Platform: HW, OS, DB Spreadsheet Data requirements: System state: Database, comm. states Input/output formats Ext. products: Sensors, dev. Special SW Functional requirements, each interface: Record, compute, transform, transmit Theory: F(input, state) -> (output, state) Function list, pseudocode, activity diagram Screen prototype, support tasks xx to yy From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 Quality reqs: Performance Usability Maintainability... Other deliverables: Documentation Install, convert, train... Managerial reqs: Delivery time Legal Development process... Helping the reader: Business goals Definitions Diagrams...

Requirements versus design Product Architecture REQ REQ A B REQ REQ C D REQ GUI L1 L2 Cost? DB Value? Long-term versus short term? Different types of requirements?

Fig 1.5A Domain and product level Business domain Domain Actors? Platform Clients Product User activities Control computers Domain I/O Product I/O Elevators Domain-level req: The product shall support the following user activities:... Product-level reqs: The product shall accept the following input:... From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002

Fig 1.5B Redefined limits Business domain Clients User activities Domain Product From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 Control computers Beware: the word domain is used in many ways Beroende på hur situationen ser ut kan ett nytt system innebära att domängränserna ritas om. Kanske sker en upphandling där styrsystemet ingår i produkten och då blir hissarna aktörer som kommunicerar direkt med systemet. Mycket av affärsutveckling handlar om att skaka om I domängränserna och tex låta användaren göra mer själv. Exempel: COOP Forums shop express. SAS web check-in.

Fig 1.6A The goal-design scale R1. Our pre-calculations shall hit within 5% R2. Product shall support cost recording and quotation with experience data R3. Product shall have recording and retrieval functions for experience data R4. System shall have screen pictures as shown in app. xx Goal-level requirement Domain-level requirement Product-level requirement Design-level requirement Mål-nivå bakomliggande syfte, affärsmål, användarnytta, effekt, vinst Domän-nivå sammanhang, omgivning, hur användarna och produkten samverkar för att ge nytta Produkt-nivå externt observerbara funktioner och egenskaper Design-nivå specifik utformning av produktens innehåll Which requirement to choose? From: Soren Lauesen: Software Requirements Pearson / Addison-Wesley 2002 If the supplier is A vendor of business applications? A software house - programmers? PriceWaterhouseCoopers?

Evolving mix of levels of detail & quality in continuous requirements engineering Level of detail, specification quality

The goal-design scale in reqt Model( Goal("accuracy") has Spec("Our pre-calculations shall hit within 5%"), Feature("quotation") has Spec("Product shall support cost recording and quotation with experience data"), Function("experienceData") has Spec("Product shall have recording and retrieval functions for experience data"), Design("screenX") has Spec("System shall have screen pictures as shown in Fig. X"))

Product("reqT") has Feature("toHtml")

Product("reqT") has Feature("toTable")

Product("reqT") has Feature("toGraph") Model( Feature("f1") has ( Spec("The system shall..."), Status(IMPLEMENTED)), Story("s1") has ( Gist("As a user I want..."), Status(ELICITED)), Story("s1") requires Feature("f1") ) Metamodel: Entity Relation Attribute

To do Hand in the introduction survey if not done it already Get the book (e.g. AdLibris) and the compendium (12:45 at the dep. SEK60) Read Lauesen Chapter 1 a very important chapter of the book Exercise 1. Bring Lauesen s book!!! Read about the project in course program (also on course web) Meet with your project group and get going as soon as possible Assign project management roles Extra first-week Lecture 2: Thursday 10-12 in E:B on Elicitation & Specification Project Mission before Friday 09:00 (see prev. instructions on email&subject) See mission examples for inspiration from previous years on the course web You get the week-end to study all Project Missions Arrive at a consensus in your group about a priority order of all missions You get to choose in random order per project on Monday You will be assigned a project supervisor by Monday Book meeting time with your project supervisor for W2, W4, W6