TSE2451Software Requirements EngineeringTest 1 Revision NoteTable of ContentsDescription PageLecture 01An Introduction to Requirements Engineering1Tutorial 01 8Lecture 0Requirements Engineering Processes!Tutorial 0 18Lecture 0"Requirements Elicitation and Anal#sis0Tutorial 0" "0Past $ear E%amination &uestions "TSE2451 Software Requirements Engineering Test 1 Revision NoteLecture 01: An Introuction to Requirements Engineering!"#ectives To introduce t'e notion of s#stem requirements and t'e requirements engineering process( To e%plain 'o) requirements engineering fits into a broader s#stem engineering process To e%plain t'e importance of t'e requirements document1( *#stem requirements Define )'at t'e s#stem is required to do and t'e constraints under )'ic' it is required to operateT'e s#stem s'all maintain records of all librar# materials including boo+s, serials, ne)spapers and maga-ines, .ideo and audio tapes, reports, collections of transparencies, computer dis+s and CD/R01s(T'e s#stem s'all allo) users to searc' for an item b# title, aut'or, or b# I*23(T'e s#stem4s user interface s'all be implemented using a 5orld/5ide/5eb bro)ser(T'e s#stem s'all support at least 0 transactions per second( T'e s#stem facilities )'ic' are a.ailable to public users s'all be demonstrable in 10 minutes or less(( T#pes of requirements 6er# general requirements )'ic' set out in broad terms )'at t'e s#stem s'ould do( 7unctional requirements )'ic' define part of t'e s#stem4s functionalit#( Implementation requirements )'ic' state 'o) t'e s#stem must be implemented( Performance requirements )'ic' specif# a minimum acceptable performance for t'e s#stem( 8sabilit# requirements )'ic' specif# t'e ma%imum acceptable time to demonstrate t'e use of t'e s#stem("( Requirements problems T'e requirements don4t reflect t'e real needs of t'e customer for t'e s#stem( Requirements are inconsistent and9or incomplete( It is e%pensi.e to ma+e c'anges to requirements after t'e# 'a.e been agreed( T'ere are misunderstandings bet)een customers, t'ose de.eloping t'e s#stem requirements and soft)are engineers de.eloping or maintaining t'e s#stem(Lecture 01 An Introduction to Requirements Engineering 1TSE2451 Software Requirements Engineering Test 1 Revision Note:( 7requentl# As+ed &uestions about requirements;i< 5'at are requirements=A statement of a s#stem ser.ice or constraint;ii< 5'at is requirements engineering=T'e processes in.ol.ed in de.eloping s#stem requirements;iii< >o) muc' does requirements engineering cost=About 1?@ of s#stem de.elopment costs;i.ard)are interface specification*oft)are components )'ic' must be reused in t'e s#stem implementationData structure specificationData/flo) models of t'e soft)are s#stemDetailed obEect models of t'e soft)are s#stem Inde%1?( 5riting requirements Requirements are usuall# )ritten as paragrap's of natural language te%t supplemented b# diagrams and equations Problems )it' requirements8se of comple% conditional clauses )'ic' are confusing*lopp# and inconsistent terminolog#5riters assume readers 'a.e domain +no)ledge1C( 5riting essentials Requirements are read more often t'an t'e# are )ritten( $ou s'ould in.est time to )rite readable and understandable requirements Do not assume t'at all readers of t'e requirements 'a.e t'e same bac+ground and use t'e same terminolog# as #ou Allo) time for re.ie), re.ision and re/drafting of t'e requirements document1D( 5riting guidelines Define standard templates for describing requirements 8se language simpl# consistentl# and concisel# 8se diagrams appropriatel# *upplement natural language )it' ot'er description of requirements! An Introduction to Requirements EngineeringLecture 01TSE2451 Software Requirements Engineering Test 1 Revision Note *pecif# requirements quantitati.el#$e% &oints1( Requirements define )'at t'e s#stem s'ould pro.ide and define s#stem constraints( Requirements problems lead to late deli.er# and c'ange requests after t'e s#stem is in use"( Requirements engineering is concerned )it' eliciting, anal#sing, and documenting t'e s#stem requirements:( *#stems engineering is concerned )it' s#stems as a )'ole including 'ard)are, soft)are and operational processes?( T'e requirements document is t'e definiti.e specification of requirements for customers, engineers and managers(C( T'e requirements document s'ould include a s#stem o.er.ie), glossar#, statement of t'e functional requirements and t'e operational constraintsLecture 01 An Introduction to Requirements Engineering "TSE2451 Software Requirements Engineering Test 1 Revision NoteTutoria' 01: An Introuction to Requirements Engineering1( List t'e possible sta+e'olders for a librar# cataloguing s#stem( Librar# 8sers Cataloging *taff Librar# 1anagement >elpdes+ 2oo+ Publis'ers ;indirect< *#stems De.elopers 1anagers of ot'er librar# automation s#stems( *uggest t'e uses )'ic' eac' of t'e sta+e'olders )'ic' #ou 'a.e identified in question 1 mig't ma+e of a requirements document for a librar# s#stem( Librar# 8sers A 3ot used directl# but used to produce user documentation( Librar# *taff A Responsible for cataloguing A 8sed to assess if t'e facilities specified are t'ose required to support t'e cataloguing process( Librar# 1anagement A 8sed to asses if t'e s#stem supports t'e o.erall goals of t'e librar#( Librar# *taff responsible for pro.iding user assistance A 8sed to assess )'et'er or not t'e retrie.al facilities are t'ose commonl# used b# end/users( 2oo+ Publis'ers ;indirect< A 3o direct use of document( 1anagers of ot'er librar# automation s#stem A 8sed to c'ec+ interactions )it' t'ese s#stems("( *uggest 'o) t'e follo)ing requirements mig't be re)ritten in a quantitati.e )a#( $ou ma# use an# metrics #ou li+e to e%press t'e requirements( T'e librar# s#stem s'all be eas#/to/use(It s'ould be possible to train end/users of t'e s#stem to use all retrie.al facilities in a single 1? minute training session( T'e librar# s#stem s'all pro.ide reliable ser.ice to all classes of user(T'e rate of occurrence of failures in t'e retrie.al facilities of t'e s#stem s'all be to less t'an 1 in 1000 queries(T'e rate of occurrence of failure for t'e cataloging facilities of t'e s#stem s'all be less t'an 1 in ?00 cataloging operations( T'e librar# s#stem s'all pro.ide a rapid response to all user requests for boo+ information(T'e a.erage s#stem response time for user requests s'all be less t'at : seconds(# An Introduction to Requirements Engineering Tutoria$ 01TSE2451 Software Requirements Engineering Test 1 Revision NoteLecture 02: Requirements Engineering &rocesses!"#ectives To introduce t'e notion of processes and process models for requirements engineering To e%plain t'e critical role of people in requirements engineering processes To e%plain )'# process impro.ements is important and to suggest a process impro.ement model for requirements engineering1( Processes A process is an organi-ed set of acti.ities )'ic' transforms inputs to outputs Process descriptions encapsulate +no)ledge and allo) it to be reused E%amples of process descriptionsInstruction manual for a dis')as'erCoo+er# boo+Procedures manual for a ban+&ualit# manual for soft)are de.elopment( Design processes Processes )'ic' in.ol.e creati.it#, interactions bet)een a )ide range of different people,engineering Eudgment and bac+ground +no)ledge and e%perience E%amples of design processes5riting a boo+0rgani-ing a conferenceDesigning a processor c'ipRequirements engineering"( Requirements Engineering process A Inputs and 0utputsLecture 02 Requirements Engineering %rocesses &TSE2451 Software Requirements Engineering Test 1 Revision Note:( Input 9 0utput DescriptionIn(ut or !ut(ut T%(e )escri(tionE%isting s#stem informationInput Information about t'e functionalit# of s#stems to be replaced or ot'er s#stems )'ic' interact )it' t'e s#stem being specified*ta+e'older needs Input Descriptions of )'at s#stem sta+e'olders need from t'e s#stem to support t'eir )or+0rgani-ational standardsInput *tandards used in an organi-ation regarding s#stem de.elopment practice, qualit# management, etc( Regulations Input E%ternal regulations suc' as 'ealt' and safet# regulations )'ic' appl# to t'e s#stem( Domain informationInput Feneral information about t'e application domain of t'e s#stemAgreed requirements0utput A description of t'e s#stem requirements )'ic' is understandable b# sta+e'olders and )'ic' 'as been agreed b# t'em*#stem specification0utput T'is is a more detailed specification of t'e s#stem functionalit# )'ic' ma# be produced in some cases*#stem models 0utput A set of models suc' as a data/flo) model, an obEect model, a process model, etc( )'ic' describes t'e s#stem from different perspecti.es( ?( Requirements Engineering process .ariabilit# Requirements Engineering processes .ar# radicall# from one organi-ation to anot'er 7actors contributing to t'is .ariabilit# includeTec'nical maturit#Disciplinar# in.ol.ement0rgani-ational cultureApplication domain T'ere is t'erefore no Iideal4 requirements engineering processC( Process models A process model is a simplified description of a process presented from a particular perspecti.e T#pes of process model includeBCoarse/grain acti.it# models7ine/grain acti.it# modelsRole/action modelsEntit#/relation models10 Requirements Engineering %rocesses Lecture 02TSE2451 Software Requirements Engineering Test 1 Revision NoteD( Coarse/grain acti.it# model of Requirements Engineering8( Requirements Engineering process acti.ities Requirements elicitationRequirements disco.ered t'roug' consultation )it' sta+e'olders Requirements anal#sis and negotiationRequirements are anal#-ed and conflicts resol.ed t'roug' negotiation Requirements documentationA requirements document is produced Requirements .alidationT'e requirements document is c'ec+ed for consistenc# and completeness!( 5aterfall model of t'e soft)are process10( Conte%t of t'e Requirements Engineering processLecture 02 Requirements Engineering %rocesses 11TSE2451 Software Requirements Engineering Test 1 Revision Note11( *piral model of t'e Requirements Engineering process1( Actors in t'e Requirements Engineering process Actors in a process are t'e people in.ol.ed in t'e e%ecution of t'at process Actors are normall# identified b# t'eir roles rat'er t'an indi.iduall# Requirements engineering in.ol.es actors )'o are primaril# interested in t'e problem to be sol.ed ;end/users, etc(< as )ell actors interested in t'e solution ;s#stem designers, etc(< Role/action diagrams document )'ic' actors are in.ol.ed in different acti.ities1"( Rapid Application De.elopment ;RAD< for soft)are protot#ping1:( Role descriptionsRole DescriptionDomain e%pert Responsible for pro.iding information about t'e application domain and t'e specific problem in t'at domain )'ic' is to be sol.ed*#stem end/user Responsible for using t'e s#stem after deli.er#Requirements engineer Responsible for eliciting and specif#ing t'e s#stem requirements*oft)are engineer Responsible for de.eloping t'e protot#pe soft)are s#stemProEect manager Responsible for planning and estimating t'e protot#ping proEect12 Requirements Engineering %rocesses Lecture 02TSE2451 Software Requirements Engineering Test 1 Revision Note1?( >uman and social factors Requirements engineering processes are dominated b# 'uman, social and organisational factors because t'e# al)a#s in.ol.e a range of sta+e'olders from different bac+grounds and )it' different indi.idual and organi-ational goals( *#stem sta+e'olders ma# come from a range of tec'nical and non/tec'nical bac+ground and from different disciplines1C( T#pes of sta+e'older *oft)are engineers responsible for s#stem de.elopment *#stem end/users )'o )ill use t'e s#stem after it 'as been deli.ered 1anagers of s#stem end/users )'o are responsible for t'eir )or+ E%ternal regulators )'o c'ec+ t'at t'e s#stem meets its legal requirements Domain e%perts )'o gi.e essential bac+ground information about t'e s#stem application domain1D( 7actors influencing requirements Personalit# and status of sta+e'olders T'e personal goals of indi.iduals )it'in an organi-ation T'e degree of political influence of sta+e'olders )it'in an organi-ation18( Process support CA*E tools pro.ide automated support for soft)are engineering processes T'e most mature CA*E tools support )ell/understood acti.ities suc' as programming and testing and t'e use of structured met'ods *upport for requirements engineering is still limited because of t'e informalit# and t'e .ariabilit# of t'e process1!( CA*E tools for Requirements Engineering 1odeling and .alidation tools support t'e de.elopment of s#stem models )'ic' can be used to specif# t'e s#stem and t'e c'ec+ing of t'ese models for completeness and consistenc#( T'e tool pac+age )'ic' supports t'is boo+ includes t'is t#pe of tool( 1anagement tools 'elp manage a database of requirements and support t'e management of c'anges to t'ese requirements(Lecture 02 Requirements Engineering %rocesses 1TSE2451 Software Requirements Engineering Test 1 Revision Note0( A Requirements 1anagement *#stem1( Requirements 1anagement Tools Requirements bro)ser Requirements quer# s#stem Traceabilit# support s#stem Report generator Requirements con.erter and )ord processor lin+er C'ange control s#stem( Process impro.ement Process impro.ement is concerned )it' modif#ing processes in order to meet some impro.ement obEecti.es Impro.ement obEecti.es&ualit# impro.ement*c'edule reductionResource reduction"( Planning process impro.ement 5'at are t'e problems )it' current processes= 5'at are t'e impro.ement goals= >o) can process impro.ement be introduced to ac'ie.e t'ese goals= >o) s'ould process impro.ements be controlled and managed=:( Requirements Engineering process problems Lac+ of sta+e'older in.ol.ement 2usiness needs not considered Lac+ of requirements management14 Requirements Engineering %rocesses Lecture 02TSE2451 Software Requirements Engineering Test 1 Revision Note Lac+ of defined responsibilities *ta+e'older communication problems 0.er/long sc'edules and poor qualit# requirements documents?( Process maturit# Process maturit# can be t'oug't of as t'e e%tent t'at an organi-ation 'as defined its processes, acti.el# controls t'ese processes and pro.ides s#stematic 'uman and computer/based support for t'em( T'e *oft)are Engineering Institute4s ;*EI< Capabilit# 1aturit# 1odel is a frame)or+ forassessing soft)are process maturit# in de.elopment organi-ationsC( Capabilit# maturit# modelD( 1aturit# le.els Initial le.el 0rgani-ations 'a.e an undisciplined process and it is left to indi.iduals 'o) to manage t'e process and )'ic' de.elopment tec'niques to use( Repeatable le.el 0rgani-ations 'a.e basic cost and sc'edule management procedures in place( T'e# are li+el# to be able to ma+e consistent budget and sc'edule predictions for proEects in t'e same application area( Defined le.el T'e soft)are process for bot' management and engineering acti.ities is documented, standardi-ed and integrated into a standard soft)are process for t'e organi-ation( 1anaged le.el Detailed measurements of bot' process and product qualit# are collected and used to control t'e process( 0ptimi-ing le.el T'e organi-ation 'as a continuous process impro.ement strateg#, based on obEecti.e measurements, in place(Lecture 02 Requirements Engineering %rocesses 15TSE2451 Software Requirements Engineering Test 1 Revision Note8( Requirements Engineering process maturit# model!( Requirements Engineering process maturit# le.els Initial le.el3o defined Requirements Engineering process( *uffer from requirements problems suc' as requirements .olatilit#, unsatisfied sta+e'olders and 'ig' re)or+ costs( Dependent on indi.idual s+ills and e%perience( Repeatable le.elDefined standards for requirements documents and policies and procedures for requirements management( Defined le.elDefined Requirements Engineering process based on good practices and tec'niques( Acti.e process impro.ement process in place("0( Food practice for Requirements Engineering process impro.ement Requirements Engineering processes can be impro.ed b# t'e s#stematic introduction of good requirements engineering practice Eac' impro.ement c#cle identifies good practice guidelines and )or+s to introduce t'em in an organi-ation E%amples of good practice guidelinesDefine a standard document structure8niquel# identif# eac' requirementDefine policies for requirements management8se c'ec+lists for requirements anal#sis8se scenarios to elicit requirements*pecif# requirements quantitati.el#8se protot#ping to animate requirementsReuse requirements1! Requirements Engineering %rocesses Lecture 02TSE2451 Software Requirements Engineering Test 1 Revision Note$e% &oints1( T'e requirements engineering process is a structured set of acti.ities )'ic' lead to t'e production of a requirements document(( Inputs to t'e requirements engineering process are information about e%isting s#stems, sta+e'older needs, organi-ational standards, regulations and domain information("( Requirements engineering processes .ar# radicall# from one organi-ation to anot'er( 1ost processes include requirements elicitation, requirements anal#sis and negotiation and requirements .alidation(:( Requirements engineering process models are simplified process description )'ic' are presented from a particular perspecti.e( ?( >uman, social and organi-ational factors are important influences on requirements engineering processes( C( Requirements engineering process impro.ement is difficult and is best tac+led in an incremental )a#( D( Requirements engineering processes can be classified according to t'eir degree of maturit#(Lecture 02 Requirements Engineering %rocesses 1"Ta'e (oo' to counter S)ow I* to $i(rarianLi(rarian va$idates (oo' and I* Li(rarian issues recei+t wit) due date Ta'e (oo' and $eaveList t)e ste+s,-nd reci+e and ingredients needed%re+are t)e ingredients,too$s and draft t)e e.+ectation of t)e ome$ette /taste0 $oo'0 s)a+e0 etc1Tr2 t)e taste of t)e ome$ette3o$$ow t)e $isted ste+s or reci+e4me$ette -nis)TSE2451 Software Requirements Engineering Test 1 Revision NoteTutoria' 02: Requirements Engineering &rocesses1( E%plain )'# t'ere is a great deal of .ariabilit# in t'e requirements engineering processes used in different organi-ations(T'ere is a great deal of .ariabilit# in t'e requirements engineering processes used in differentorgani-ations because different organi-ations 'a.e different requirements engineering processes as t'e# are affected b# t'e tec'nical maturit#, disciplinar# in.ol.ement, organi-ation culture and application domain of t'e organi-ation itself(( Define an acti.it# model of t'e processes of c'ec+ing a boo+ out of a librar#, ma+ing an omelette and installing some ne) soft)are on #our computer ;t'is can be .er# c'allengingJasma' Digital Librar# librar# s#stem at 1ultimedia 8ni.ersit#(;" mar+s