Vaatimusmäärittely- ja hallinta TJTA330 Ohjelmistotuotanto 27.3. Peruskäsitteet Vaatimusten yhteydessä puhutaan yleensä erikseen vaatimusmäärittelystä ja vaatimusten hallinnasta Vaatimusmäärittely on vaatimusten luomista ja dokumentointia Vaatimusten hallinta on kontrolloitua vaatimusmuutosten hallintaa ja liittyy siten läheisesti projektinhallintaan 2 Syyt aikataulun ja budjetin ylitykseen Chaos report 1994, www.standishgroup.com 3 1
Vaatimusmuutosten hinta 40-1000X Virheen korjaamisen suhteellinen kustannus 1 3-6X 10X 15-40X 30-70X (82X IBM keskiarvo) Vaatimusmäärittely Suunnittelu Koodaus Kehitys- Testaus Hyväksymis- Käyttöönotto, Testaus Ylläpito Boehm 1981. Software Engineering Economics. 4 Vaatimukset ja CMMI Level5 Level4 Organizational Innovation and Deployment Causal Analysis and Resolution Organizational Process Performance Quantitative Project Management Level3 Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management Risk Management Integrated Teaming Integrated Supplier Management Decision Analysis and Resolution Organizational Environment for Integration Level2 Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management Level1 5 Vaatimusmäärittelyn vaiheet Sommerville 2001. 6 2
Vaatimusmäärittelyn vaiheet 7 Eritasoinen spesifikaatio User requirements Client managers System end-users Client engineers Contractor managers System architects System requirements System end-users Client engineers System architects Software developers Software design specification Sommerville 2001. Client engineers System architects Software developers 8 Baseline Käyttäjävaatimukset Vaatimusspesifikaatio Suunnitteluspesifikaatio baseline Toteutus Testaus 9 3
Gilb. T. 2005. Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. 10 Vaatimustyypit Toiminnalliset vaatimukset Ei-toiminnalliset vaatimukset Suorituskyky, luotettavuus, turvallisuus yms. Rajoitteet: Hinta, aikataulu, standardit, laki yms. Koskinen ym. 2001, 56. 11 Vaatimusmäärittelyn käytänteitä (CMMI) tunnistetaan eri osapuolten tarpeet, odotukset Luodaan asiakasvaatimukset Laaditaan tuotevaatimukset Suunnitelmien vaatima tarkkuustaso Suunnitteluratkaisut -> vaatimukset Vaatimusten väliset yhteydet -> konfiguraationhallinta 12 4
Vaatimusten lähteitä Asiakas Käyttäjä Rajapinnat muihin järjestelmiin Valmiskomponentti Osajärjestelmä Standardit: asiakkaan ympäristö, oma tuotelinja yms., alan yleiset standardit Markkinat Laki 13 Vaatimusten tuottaminen Technology demonstrations Interface control working groups Technical control working groups Interim project reviews Questionnaires, interviews, and operational scenarios obtained from end users Operational walkthroughs and end-user task analysis Prototypes and models Brainstorming Quality Function Deployment Market surveys Beta testing Extraction from sources such as documents, standards, or specifications Observation of existing products, environments, and workflow patterns Use cases Business case analysis Reverse engineering (for legacy products) 14 Vaatimusmäärittelyn käytänteitä (CMMI) Kohdennetaan vaatimukset toiminnoiksi komponenteiksi Rajoitukset eri komponenteille Tunnistetaan vaatimukset rajapinnoille Testijärjestelmä, tuotantotilat, yms. Analysoidaan ja validoidaan vaatimukset 15 5
Vaatimusdokumentin rakenne 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3. Specific requirements Appendixes Index IEEE Std. 830-1998 16... 3. Specific requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces IEEE Std. 830-1998 17... 3. Specific requirements 3.2 Functional requirements 3.2.1 User class 1 3.2.1.1 Functional requirement 1.1. 3.2.1.n Functional requirement 1.n 3.2.m User class m 3.2.m.1 Functional requirement m.1. 3.2.m.n Functional requirement m.n IEEE Std. 830-1998 18 6
... 3. Specific requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements IEEE Std. 830-1998 19 Validointikriteerit mukaan Osaksi vaatimusmäärittelyä Kuinka tunnistetaan onnistunut toteutus? Minkälaisia testejä tarvitaan? Pressman 2000, 287. 20 Vaatimusten validointi Kuinka validi vaatimus on Tarvitaanko todella? Onko fiksumpaa vaatia jotain muuta? Yhdenmukaisuus Täydellisyys Realismi Verifioitavuus Sommerville 2001, 137. 21 7
Validointitapoja Katselmoinnit Asiakas, käyttäjä, kehitystiimi Prototyypit Testitapausten luonti Automatisoitu yhdenmukaisuuden tarkistaminen Sommerville 2001, 138. 22 Vaatimusmäärittelyn ongelmia Ohjelmisto on aina uusi -> ei ole valmista täydellistä mallia vaatimusmäärittelylle Käyttäjien tarpeet hyvin vaihtelevia Asiakas on usein eri kuin käyttäjä Asiakas ei osaa määritellä tarpeitaan tarpeeksi yksityiskohtaisesti ja teknisesti (tai omalla kielellä) Asiakas on liian urautunut vanhaan toimintamalliin Tuottaja ei tunne sovellusaluetta tarpeeksi Asiakas kiinnittää liiaksi toteutusta Tuottaja pyrkii vaikuttamaan liiaksi vaatimuksiin Koskinen ym. 2001, 58-59. 23 Vältä näitä 1. Hämmennys vaatimuksista: Vaatimuksilla sanana viitataan useaan eri asiaan. -> eri sidosryhmien tunnistaminen 2. Riittämätön asiakkaan osallistuminen: luotetaan telepatiaan vaatimusten välittämisessä käyttäjältä kehittäjille. -> käyttäjäluokkien tunnistaminen 24 8
Vältä näitä 3. Epäselvät ja moniselitteiset vaatimukset: jokainen tulkitsee ne omalla tavallaan ja olettaa loput. -> moniselitteiset sanat, katselmoinnit, testitapaukset 4. Priorisoimattomat vaatimukset: kaikki vaatimukset ovat kriittisiä. -> Priorisointi: odotettu käytön määrä, tärkeimät käyttäjäluokat, ydinprosessit 25 Vältä näitä 5. Rakennetaan toimintoja, joita kukaan ei käytä -> jäljitetään vaatimuksen alkuperä 6. Analysis paralysis -> hyäksytään epätäydellisyydet, mutta suunnitellaan niiden tulevaisuus 26 Vältä näitä 7. Laajuuden venyminen: Vaatimuksia tulee lisää -> puskuri muutoksille, huolellinen määrittely, muutoksenhallintaprosessi 8. Riittämätön tai olematon muutoshallintaprosessi -> tarpeen mukainen prosessi 27 9
Vältä näitä 9. Riittämätön muutoksen vaikutusten analysointi -> analyysi päätöksenteon tueksi 10. Riittämätön versionhallinta -> kommunikaatio, työkalu 28 Vaatimusmuutosten lähteitä Kaikkia asiakasvaatimuksia ei ymmärretä oikein projektin alkuvaiheessa Asiakasvaatimuksia voi jäädä huomaamatta Toimintaympäristössä voi tapahtua muutoksia (organisaatio, tekniikka, ohjelmistot) Jokin määritelty ominaisuus voi osoittautua käyttökelvottomaksi Haikala & Märijärvi (2002, 100-101) 29 Vaatimusmuutosten lähteitä Aikataulupaineet -> jotain voi jäädä toteuttamatta Markkinatilanne -> kilpailija julkistaa uuden tuotteen Teknologiavalinnat osoittautuvat epäonnistuneiksi (standardit) Haikala & Märijärvi (2002, 100-101) 30 10
Vaatimusten hallinta - CMMI Ymmärretään vaatimukset Kriteerit vaatimusten hyväksyntää varten, analysoidaan vaatimukset, yhteinen ymmärrys vaatimuksista Sitoumukset vaatimuksiin Hallitaan vaatimusmuutoksia Ylläpidä muutoshistoria -> perustelut Muutosten vaikutus Muutos näkyväksi projektille 31 Vaatimusten hallinta - CMMI Ylläpidetään jäljitettävyyttä molempiin suuntiin Tunnistetaan epäjohdonmukaisuudet ja poikkeamat vaatimuksiin nähden Projektin alussa + seuranta 32 Muutosten hallinta Muutosprosessin määrittely Vaatimusten priorisointi Vaikutusten huolellinen analysointi Kustannukset, vaikutukset muihin vaatimuksiin tai tekniseen toteutukseen Jäljitettävyys Muutosten dokumentointi Muutosten verifiointi 33 11