Definiranje projektnog zahtjeva

Proces razvoja informacionih sistema -definisanje korisničkih zahteva

2/17/2003

1

Definisanje korisničkih zahteva

17.2.2003 Proces razvoja informacionih sistema -definisanje korisničkih zahteva

2

Sadržaj

• Karakteristike zahteva• Proces definisanja zahteva• Modeliranje radnog procesa korisnika• Tehnike definisanja zahteva• Zahtevi vezani za korisnički interfejs• Alati za definisanje zahteva


3

Karakteristike zahteva

• Zahtevizahtevi su opisi problema, a ne sistema koji treba da rešava problemformalna specifikacija zahteva -povezuje problem sa sistemom


4

• Zahteviopisuju šta sistem treba da radi, a ne kako on to treba da radinajčešće su nekompletnievoluiraju tokom vremena, kroz niz iteracija



5

• Zahtevizahtevi i dizajn sistema su međusobno zavisnifunkcionalni (ponašanje sistema) i nefunkcionalni zahtevi (npr. kvalitet sistema)zahtevi zavise od konteksta u kome sistem treba da radi



6

Proces definisanja zahteva

• Definisanje zahteva je procesučešće korisnikakreiranje adekvatne dokumentacijeprovera kompletnosti i konzistentnosti zahtevaprototipski razvoj sistema


2/17/2003

2


7

• Definisanje zahteva je processimulacija i simulacioni paketiposebni jezici za definisanje zahtevamodeliranje problemazahtevi u skladu sa potrebama tržišta

Proces definisanja zahteva


8

Modeliranje radnog procesa

One zahteve koji će neposredno uticati na to da budući softverski proizvod verno odslikava proces rada korisnikatreba učiniti eksplicitnim !!!


9

• Poznati pristupi u modeliranju radnog procesa korisnika

višestruki dijagramimetafore



10

• Višestruki dijagrami

Koristite dijagrame da biste shvatili radni proces svog korisnika. Vizuelni pregled je razumljiviji i za razvojni tim i za korisnika !!!



11

• Višestruki dijagramikontekstni dijagramifizički dijagramikomunikacioni dijagramivremenski dijagrami



12

• Višestruki dijagramiu više iteracija zajedno sa korisnicimadefinisanje terminologije procesa radaapstraktni model radnog procesa, kao osnova za dizajn sistema



2/17/2003

3


13

• Višestruki dijagrami - kontekstni dijagram

Sekretarica

Dokumenti

Direktor

Posao sapapirima

Priprema

Deoobaveza

Overa

Podsećanje



14

• Višestruki dijagrami - vremenski dijagramOdluka o pripremi dokumenata

Dobijanje materijala

Izbor prioritetnih dokumenata

Izbor jednog dokumenta

Odluka o akciji

Priprema Traženjeobjašnjenja

Arhiviranje

Odlaganje



15

• Metaforemetafora kancelarijemetafora agencijemetafora bibliotekemetafora radio/TV stanice



16

• Metafore

Najvažnije je dobro razumeti korisničke zahteve, kako bi se odabrala prava metafora od već postojećih, ili u interakciji sa korisnikom definisala nova.



17

• Metafore - način izborana bazi nekih drugih metafora koje korisnici već koristefizička struktura po mogućstvu (npr. metafora kancelarije)jasno razumljivo bukvalno značenje (npr., metafora biblioteke)



18

• Metaforestimulišu ideje korisnikapomažu da se korisnici i razvojni tim bolje razumejupomažu da korisnici razumeju dizajn sistema



2/17/2003

4


19

• Zajednički imenitelj svih tehnikaevolutivna, inkrementalna i iterativna priroda procesaobavezno uključivanje korisnika

Tehnike definisanja zahteva


20

• Najpoznatije tehnikeintervjuanaliza scenarijakonceptualno modeliranjeAEE tehnika (Achieving Engineering Excellence)pravljenje i korišćenje video zapisa



21

• Intervjuformalni i neformalni pristupfleksibilna i slobodna tehnika



22

• Intervju

Nemojte nikada verovati da ste saznali sve o radnom procesu korisnika ili o njegovim potrebama !!!



23

• Intervju

Tumačite korisnikove zahteve zajedno sa njim.



24

• Intervju

Pravilno koristite svoje korisnike. Dozvolite da ih njihov "domaći teren"učini sigurnijim.



2/17/2003

5


25

• Intervju

Prekinite korisnika u njegovom poslui pitajte ga: "Šta to upravo radite? Čemu to služi? Da li ste upravo to očekivali?"



26

• Intervju

Neka predstavnik korisnika bude prisutankad glavni projektanti donose važne odluke.



27

• Intervju

Veoma pogodan medijum za izradu dokumenta o zahtevima je hipertekst.



28

• Analiza scenarijascenario -opis neke tipične sekvence aktivnostiscenariji opisuju potencijalno ponašanje sistema gledano iz ugla korisnikascenariji zahtevaju stalno uključivanje korisnika



29

• Analiza scenarijascenariji daju smernice za sintezu prototipa sistemascenariji pomažu u usaglašavanju specifikacije zahteva sa korisnicimascenariji sugerišu kriterijume za testiranje softvera



30

• Analiza scenarijakoraci

• kreiranje skupa mogućih scenarija za opis jedne radne situacije

• konstruisanje grafa (stabla) scenarija koji opisuju datu situaciju



2/17/2003

6


31

• Analiza scenarijakoraci

• kreiranje nekog formalnog modela scenarija

• generisanje prototipske funkcije sistema (i pružanje na uvid korisniku u cilju validacije)

može i više iteracija



32

• Konceptualno modeliranjerazdvojiti direktne zahteve od formalnih specifikacijaizraziti zahteve kao formalne specifikacije

• one moraju da potiču od neformalnih zahteva, a ne od karakteristika budućeg softverskog sistema

• one se mogu obrađivati i interpretirati korišćenjem odgovarajućih softverskih alata, a direktne ne



33

• Konceptualno modeliranjedefinisati zahteve tako da budu realno ostvarljivieliminisati redundantnosti korišćenjem nekog formalizma

• primer -zahtevi: A ∧ B, A ∧ C (A je redundantno)



34

• AEE tehnika (Achieving Engineering Excellence)

razumevanje potreba korisnikaprikupljanje informacija o radnom procesuprečišćavanje prikupljenih informacijaformalizacija sakupljenih informacija



35


generisanje predloga više mogućih rešenja budućeg sistema (!!!)klasifikovanje zahteva po podsistemima("stablo zahteva")fiksiranje zahteva (!!!)



36


analiza posledica potencijalnih promena (!!!)ažuriranje specifikacije zahteva



2/17/2003

7


37

• Pravljenje i korišćenje video zapisasmanjivanje režijskih troškova komunikacije sa korisnicimavideo zapisi se mogu pokazati i ostalim članovima tima (i to više puta!)video zapisi otkrivaju nove detalje iz procesa rada



38

• Osnovne preporukepaziti da korisnički interfejs mora uvek da bude

• modeliran u skladu sa kognitivnim sposobnostima i (ne)svesnim očekivanjima krajnjeg korisnika

• usklađen sa korisnikovim prirodnim procesom razmišljanja pri obavljanju posla

ne preterivati sa grafikom

Zahtevi vezani za korisnički interfejs


39

• Osnovne preporukekorišćenje metafora

• proces rada mora da bude "vidljiv" na ekranu

• metafora mora da deluje prirodno na ekranu



40

• Osnovne preporuke

Specifični zahtevi vezani za korisnički interfejs moraju da budu definisani tek nakon definisanja zahteva vezanih za sistem kao celinu.



41

• Važno upozorenje

Alati za definisanje zahteva

Automatizacija procesa definisanja zahteva nije jednostavan posao. Alati za definisanje zahteva obično zahtevaju poznavanje formalizama na kojima se zasnivaju i odgovarajuću obuku.


42

• Alati omogućuju:memorisanje formalizovanih zahteva u bazilako strukturiranje i pretraživanje bazeidentifikaciju i vizualizaciju zahtevaproveru konzistentnosti i kompletnosti zahtevapraćenje istorijata pojedinačnih zahteva i grupa zahteva



2/17/2003

8


43

• Princip rada alata za definisanje zahteva

Korisnik Softverskiinženjer Dokument o

zahtevima

BazazahtevaProgram za

definisanjezahteva

Računar

Komande

Interaktivniizlaz



44

Umesto zaključka

Iterate with your customers. Iterate, iterate, iterate.

Karen Holtzblatt, InContext Enterprises, Inc.


45

• L.J. Bannon, "The Politics of Design - Representing Work", Communications of The ACM, Vol.38, No.9, September 1995, pp. 66-68.

• H.R. Beyer, K. Holtzblatt, "Apprenticing with the Customer", Communications of The ACM, Vol.38, No.5, May 1995, pp. 45-52.

• B. Boehm, H. In, "Identifying Quality-Requirement Conflicts", IEEE Software, March 1996, pp. 25-36.

• A.M. Davis, P. Hsia, "Giving Voice to Requirements Engineering", IEEE Software, March 1994, pp. 12-17.

• K. Holtzblatt, H. Beyer, "Making Customer-Centered Design Work for Teams", Communications of The ACM, Vol.36, No.10, October 1993, pp. 92-104.

• P. Hsia, J. Samuel, J. Gao, D. Kung, Y. Toyoshima, C. Chen, C.: "Formal Approach to Scenario Analysis", IEEE Software, March 1994, pp. 33-41.

• A.F. Hutchings, S.T. Knox, "Creating Products Customers Demand",Communications of The ACM, Vol.38, No.5, May 1995, pp. 72-80.

Literatura


46

• I. Jacobson, G. Booch, J. Rumbaugh, "The Unified Software Development Process", Addison-Wesley, Reading, MA, 1999.

• M. Keil, E. Carmel, E.: "Customer-Developer Links in Software Development", Communications of The ACM, Vol.38, No.5, May 1995, pp. 33-44.

• M. Kyng, "Making Representations Work", Communications of The ACM, Vol.38, No.9, September 1995, pp. 46-55.

• K.H. Madsen, "A Guide to Metaphorical Design", Communications of The ACM, Vol.37, No.12, December 1994, pp. 57-62.

• H. Nissen, M. Jeusfeld, M. Jarke, G. Zemanek, H. Huber, "Managing Multiple Requirements Perspectives with Metamodels", IEEE Software, March 1996, pp. 37-51.

• F. Pinheiro, J. Goguen, "An Object-Oriented Tool for Tracing Requirements", IEEE Software, March 1996, pp. 52-65.

• C. Potts, K. Takahashi, A.I. Anton, "Inquiry-Based Requirements Analysis", IEEE Software, March 1994, pp. 21-32.

Literatura


47

• C. Rich, R.C. Waters, "Knowledge Intensive Software Engineering Tools", IEEE Transactions on Knowledge and Data Engineering, Vol.4, No.5, October 1992, pp. 424-430.

• J. Siddiqi, "Challenging Universal Truths of Requirements Engineering", IEEE Software, March 1994, pp. 18-20.

• J. Siddiqi, M.C. Shekaran, "Requirements Engineering: The Emerging Wisdom", IEEE Software, March 1996, pp. 15-19.

• L. Suchman, "Making Work Visible", Communications of The ACM, Vol.38, No.9, September 1995, pp. 56-61.

Literatura

Documents

Definiranje projektnog zahtjeva