Software Engineering Fundamentals and Methodologies
CH1
SW prods: 1.Generic: The spec.
Of wht the SW shud do is owned by the SW dever & decisions on SW chnge r made by the dever. 2. Cus2mized: The spec. Of wht the SW shud do is owned by the cstmr
4 the SW & they make decisions on SW chnges that r reqd. SW: Computer progs & associated docmn.. SW prods may b deved 4 a particular cstmr or may b deved 4 a general market. Attributes of good SW: deliver the reqd funcnality & per4mance, maintainable, dependable & usable.SE: engi. Discipline that is concerned with all aspects of SW prodion. Fundamental SW engi. Activities: spec., devel, valid. & evol..Diff b/w se & cs: CS focuses on theory & fundamentals; SE is concerned with the practicalities of deving & delivering useful SW. Diff b/w sof e & syst eng: Syst eng is concerned with all aspects of compr-based syss devel including hardwr, SW & prcss engi.. SE is part of this more general prcss. Key challenges facing SE: Coping with increasing diversity, dem&s 4 reduced deli. Times & deving trustworthy SW. Costs of SE: 60% dev & 40% tsting. Bst se techn & methods: While all SW projs have 2 b prof.Ly managed & deved, different techniques r appropriate 4 different types of sys. 4 example, games shud always b deved using a series of pro2types whras safety critical control syss req a complete & analyzable spec. 2 b deved. You can’t, there4e, say that one method is btter than anther. Web & se: The web has led 2 the availability of SW services & the possibility of deving highly distributed service-based syss. Web-based syss devel has led 2 important adv.S in prog languages & SW reuse. Se app types: batch prcssing, entertainment, sys 4 modlling & simulation, data collection, sys of sys, st& alone, interactive transaction based, embdded control.Se fundamental principles: devel. Using a managed & undrstd dev. Prcss. Dependability &per4mance r important. Undrstnding & managing the sw spec. & req r important. U shud reuse SW that has already bn deved rather than write new. Issues of prof. Resp: confidentiality, competence, intellectual prop rights, comp misuse. 8 princ of acm: public, client & employer, prod, judgement, mngmnet, profession, colleagues, self.
CH2:
SW PRCSS: abstract representation of a prcss. It presents a desc. Of a prcss from sm particular perspective. It involves spec., devel & impl., valid., evol.. Prcss desc include: prods, roles, pre & post cond. Plan driven: activities r planned in adv. & progress is measured against this plan. Agile: planning is incre & it is easier 2 chnge the prcss 2 reflect chngng cstmr req.. WATERFALL MODL: Req analysis & definition, Syst & sw design, Implem & unit tsting, Integration & sys tsting, Oper. & maint..Disadv: difficulty of accommodating chnge aftr the prcss is underway. Prob.S: Inflexible partitioning of the proj in2 distinct stages makes it difficult 2 respond 2 chngng cstmr req.(only app when the req r well-undrstd & chnges will b fairly limited during the design prcss).Used 4 large sys eng projs whr a sys is dev at several sites.(plan-driven nature helps coordinate the wrk)
.INCRE DEVEL: idea of devel an initial impl., exposing this 2 user comm. & evolving it through sev. Vrsns until an adequate sys has bn devel. Bnefits: cost of accomm. Chngng cstmr req is reduced.(amt. Of analysis & docum. That has 2 b redone is much less than is reqd with the waterfall modl)
.It is easier 2 get cstmr feedback on the dev wrk that has bn done. (cstmrs can cmnt on demons of the sw & see how much has bn impl..) more rapid deli. & deployment of useful sw 2 the cstmer is possible.( cstmrs r able 2 use , gain value from the swearlier than is possible with a waterfall prcss).Prob.S: The prcss is nt visible.(Managers need regular deliv. 2 measure progress. If syss r deved quickly, it is nt cost-effective 2 produce docum that reflect every vrsn of the sys.) Sys struc. Tends 2 degrade as new incr.S r added.(Unless time & money is spent on refac2ring 2 improve the SW, regular chnge tends 2 corrupt its struc.). REUSE-ORIENTED SE: Based on sysatic reuse whr sys r integrated from existing compo.S or COTS (Commercial-off-the-shelf) syst. Stages: Compo. Analysis, Req modification, sys design with reuse, devel & integration. SW SPEC.: prcss of est.Ing wht services r req & the constraints on the sys’s oper. & dev.Main activities: Feasibility study(Is it technically & finan. Feasible 2 build the sys? )Req elicitation & analysis(Wht do the sys stakeholders req or expect from the sys? )Req spec.(Defining the req in detail)Req valid.(Checking the validity of the req). SW DESIGN & IMP: prcss of conv the sys spec. In2 an executable sys.SW design: Design a sw struc. That realises the spec.;Impl.: Translate struc. In2 an executable prog.Design prcss: Architectural design- identify the overall struc. Of the sys, the principal compo.S, their relationships & how they r distributed. Interface design – define the interfaces b/w sys compo.S. Compo. Design – take each sys compo. & design how it will operate. Database design – design the sys data struc.S & how these r 2 b represented in a db. SW VALIDA2N: show that a sys con4ms 2 its spec. & meets the req of the sys cstmr. Involves checking & review prcsses & sys tsting. Sys tsting involves executing the sys with tst cases that r derived from the spec. Of the real data 2 b prcssed by the sys. Tsting stages: Dev. Or compo. Tsting (Indiv. Compo.S r tsted indep, Compo.S may b fnctions or objects or coherent groupings of these entities.) Sys tsting( Tsting of the sys as a whole. Tsting of emergent properties is particularly imp.) Acceptance tsting ( Tsting with cstmr data 2 check that the sys meets the cstmr’s needs.) SW EVOL.: takes place when you chnge existing sw sys 2 meet new req. The sw mst evolve 2 remain useful. REDUCING COSTS: Chnge avoidance – whr the sw procs includes activities that can anticipate possible chnges b4e significant rewrk is reqd. E.G, a pro2type sys may b deved 2 show sm key features of the sys 2 cstmrs. Chnge 2lerance -whr the prcss is designed so that chnges can b accommodated at relatively low cost. This normally involves sm 4m of increm. Devel. Proposed chnges may b impl. In incr.S that have nt yet bn devel.. If this is impossible, then only a single incr. May have b altered 2 incorporate the chnge. SW PRO2TYPING: initial vrsn of a sys used 2 demonstrate concepts & try out design options. Useful in: The req eng prcss 2 help with req elicitation & valid.; In design prcsses 2 explore options & dev a UI design;In the tsting prcss 2 run back-2-back tsts. Bnefits: Improved sys usability.A closer match 2 users’ real needs.Improved design quality.Improved maintainability.Reduced devel ef4t.Pro2type devel – est. Prot obj, define prot funcnality, devel prot, eval prot.Prot shud focus on ras of the prod that r nt well-undrstd; Error checking & recovery may nt b included in the prot;Focus on funcnal rather than non-funcnal req. Such as reliability & security. Throw away prot – discarded after devel. No good base 4 prodion sys – It may b impossible 2 tune the sys 2 meet non-funcnal requ; Pro2types r normally undocumented; prot struc. Is usually degraded through rapid chnge;prot probably will nt meet normal org.Al quality st&ards. INCRE DEVEL.: Dev the sys in incr.S & eval. Each incr. B4e proceeding 2 the devel of the next incr.;Normal approach used in agile methods; Evaluation done by user/cstmr proxy. INCRE DELI.: Deploy an incr. 4 use by end-users; More realistic evaluation about practical use of sw;Difficult 2 implement 4 replacement syst as incr.S have less funcnality than the sys bing replaced. Adv.: Cstmr value can b delivered with each incr. So sys funcnality is available earlier. Early incr.S act as a prot 2 help elicit req 4 later incr.S.Lower risk of overall proj failure. The highest priority sys services tend 2 receive the most tsting. Prob.S: Most sys req a set of basic facilities that r used by diff parts of the sys.(As req. R nt defined in detail until an incr. Is 2 b impl., it can b hard 2 identify common facilities that r needed by all incr.S).The essence of iterative prcsses is that the spec. Is deved in conjunction with the SW( However, this conflicts with the procurement modl of many org.S, whr the complete sys spec. Is part of the sys devel contract. BOEHM’S SPIRAL: Prcss is repres. As a spiral rather than as a sequence of activities with backtracking. Each loop in the spiral repres a phase in the prcss. No fixed phases such as spec. Or design – loops in the spiral r chosen depending on wht is reqd. Risks r explicitly assessed & resolved throughout the prcss. Sec2rs- obj setting – specific onj of the phase r identified. Risk assessment & reduction – risks r assessed & activities put in place 2 reduce the key risks. Devel. & valid. – devel modl can b any of generic modl. Planning – proj is reviewed & next phase of spiral is planned.Modl usage – Spiral modl has bn very influential in helping ppl think about iteration in SW prcsses & introducing the risk-driven approach 2 devel. In practice, however, the modl is rrly used as published 4 practical SW develRATIONAL UNIFIED PRCSS: modern generic prcss modl that is organized in2 phases (inception, elaboration, construction & transition) but separates activities (req., analysis & design, etc.) from these phases. A modern generic prcss derived from the wrk on the UML & associated prcss. Brings 2gether aspects of the 3 generic prcss modls discussed previously. Normally describd from 3 perspectives: A dynamic persp. That shows phases over time; A static persp. That shows prcss activities; A practive persp. That suggests good practice.Phases – Inception( Est. The bus. Case 4 the sys.) Elaboration( Devel an undrstndng of the prob. Domain & the sys architecture.) Construction( Sys design, prog & tsting.)Transition( Deploy the sys in its operating environment). Rup iteration – In-phase iteration( Each phase is iterative with results devel increly.) Cross-phase iteration( As shown by the loop in the RUP modl, the whole set of phases may b enacted increly.) Wrkflows in RUP: Bus. Modlling – The bus. Prcsses r modlled using bus. Use cases. , Req. – Ac2rs who interact with the sys r identified & use cases r deved 2 modl the sys req.., Analysis & design – A design modl is created & documented using architectural modls, compo. Modls, object modls & sequence modls. , Implemetation – The compo.S in the sys r impl. & struc.D in2 impl. Sub-syss. Au2matic code generation from design modls helps accelerate this prcss. , Tsting : iterative prcss that is carried out in conjunction with impl.. Sys tsting follows the compl. Of the impl.. , Deployment – A prod release is created, distributed 2 users & installed in their wrkplace. , config. & chnge mngmnt – This sporting wrkflow managed chnges 2 the sys, proj mngmnt- This supporting wrkflow manages the sys devel, environment – This wrkflow is concerned with making approp. Sw 2ols available 2 the sw devel team.
RUP adv: Dev SW iteratively (Plan incr.S based on cstmr priorities & deliver highest priority incr.S first). Manage req(Explicitly document cstmr req & keep track of chnges 2 these req). Use compo.-based architectures( Organize the sys architecture as a set of reusable compo.S).Visually modl SW( Use graphical UML modls 2 present static & dynamic views of the SW)Verify SW quality( Ensure that the SW meet’s org.Al quality st&ards.) Control chnges 2 SW( Manage SW chnges using a chnge mngmnt sys & config. Mngmnt 2ols.)
CH3:
RAPID SW DEVEL: Spec., design & impl. R inter-leaved. Sys is deved as a series of vrsns with stakeholders involved in vrsn evaluation. User interfaces r often deved using an IDE & graphical 2olset.AGILE METHODS: Focus on the code rather than the design R based on an iterative approach 2 sw develR intended 2 deliver wrking sw quickly & evolve this quickly 2 meet chngng req.Aim of agile methods is 2 reduce overheads in the SW prcss (e.G. By limiting docum.) & 2 b able 2 respond quickly 2 chngng req without excessive rewrk. Principles: Cstmr Involvement – Cstmrs shud b closely involved throughout the dev prcss. Their role is provide & prioritize new sys req & 2 eval. The iterations of the sys.Incre Deli. – sw is deved in incr.S with the cstmr specifying the req 2 b included in each incr.. Ppl nt prcss – The skills of the devel team shud b recognized & exploited. Team mmbrs shud b left 2 dev their own ways of wrking without prescriptive prcsses.Embrace chnge – Expect the syss req 2 chnge & so design the sys 2 accommodate these chnges.Maintain simplicity – Focus on simplicity in both the sw bing deved & in the dev prcss. Whrevr possible, actively wrk 2 eliminate complexity from the sys.Prob.S: It can b difficult 2 keep the interest of cstmrs who r involved in the prcss, Team mmbrs may b unsuited 2 the intense involvement that characterises agile methods, Prioritising chnges can b difficult whr there r multiple stakeholders, Maintaining simplicity reqs extra wrk, Contracts may b a prob. As with other approaches 2 iterative devel. PLAN DRIVEN & AGILE SPEC.: Plan-driven devel: A plan-driven approach 2 SW engi. Is based around separate devel stages with the outputs 2 b produced at each of these stages planned in adv.. Nt necessarily waterfall modl – plan-driven, incre devel is possible Iteration occurs within activities. Agile devel: Spec., design, impl. & tsting r inter-leaved & the outputs from the devel prcss r decided through a prcss of negotiation during the SW devel prcss. XTREME PROG: XP takes an ‘xtreme’ approach 2 iterative devel. New vrsns may b built several times per day;Incr.S r delivered 2 cstmrs every 2 weeks;All tsts mst b run 4 every build & the build is only accepted if tsts run successfully.XP & agile principles: Incre devel is supported through small, frequent sys releases. Cstmr involvement means full-time cstmr engagement with the team. Ppl nt prcss through pair prog, collective ownership & a prcss that avoids long wrking hours. Chnge supported through regular sys releases. Maintaining simplicity through constant refac2ring of code.XP Release cycle: Select user s2ries with this release, break down s2ries 2 tasks, plan release, dev/integrate/ tst sw, release sw, eval. Sys. XP Practices/Principles – Incre planning – Req. R recorded on s2ry cards & the s2ries 2 b included in a release r determined by the time available & their relative priority. The devers break these s2ries in2 devel ‘Tasks’.Small releases – The minimal useful set of funcnality that provides bus. Value is deved first. Releases of the sys r frequent & increly add funcnality 2 the first release.Simple design – Enough design is carried out 2 meet the current req. & no more.Tst – first develo: An au2mated unit tst framewrk is used 2 write tsts 4 a new piece of funcnality b4e that funcnality itself is impl..Refac2ring: All devers r expected 2 refac2r the code continuously as soon as possible code improvements r found. This keeps the code simple & maintainable.Pair prog: Devers wrk in pairs, checking each other’s wrk & providing the support 2 always do a good job. Collective ownership: The pairs of devers wrk on all ras of the sys, so that no isl&s of expertise dev & all the devers take responsibility 4 all of the code. Anyone can chnge anything. Continous integration: As soon as the wrk on a task is complete, it is integrated in2 the whole sys. After any such integration, all the unit tsts in the sys mst pass. Sustainable pace: Large amt.S of overtime r nt considered acceptable as the net effect is often 2 reduce code quality & medium term prodivity . On site cstmr: A representative of the end-user of the sys (the cstmr) shud b available full time 4 the use of the XP team. In an xtreme prog prcss, the cstmr is a membr of the devel team & is responsible 4 bringing sys req. 2 the team 4 impl.. REFAC2RING: Prog team look 4 possible sw improvements & make these improvements even whr there is no immediate need 4 thm. This improves the underst&ability of the sw & so reduces the need 4 docmn.. Chnges r easier 2 make bcause the code is well-struc.D & clear. However, sm chnges reqs architecture refac2ring & this is much more expensive. Examples – Re-org. Of a class hierarchy 2 remove duplicate code. Tidying up & renaming attributes & methods 2 make thm easier 2 underst&. The replacement of inline code with calls 2 methods that have bn included in a prog library. XP Tsting features: Tst-first devel. Incre tst devel from scenarios. User involvement in tst devel & valid.. Au2mated tst harnesses r used 2 run all compo. Tsts each time that a new release is built.XP Tsting difficulties: 1.Progmers prefer prog 2 tsting & smtimes they take short cuts when writing tsts. E.G, they may write incomplete tsts that do nt check 4 all possible exceptions that may occur.2. Sm tsts can b very difficult 2 write increly. E.G., in a complex user interface, it is often difficult 2 write unit tsts 4 the code that implements the ‘display logic’ & wrkflow b/w screens. 3. It difficult 2 judge the completeness of a set of tsts. Although you may have a lot of sys tsts, your tst set may nt provide complete coverage. PAIR PROGR: In XP, progmers wrk in pairs, sitting 2gether 2 dev code.This helps dev common ownership of code & spreads knowledge across the team.It serves as an in4mal review prcss as each line of code is looked at by more than 1 person.It encourages refac2ring as the whole team can bnefit from this. Measurements suggest that devel prodivity with pair prog is similar 2 that of two ppl wrking independently. In pair prog, progmers sit 2gether at the same wrkstation 2 dev the SW. Pairs r created dynamically so that all team embrs wrk with each other during the devel prcss.The sharing of knowledge that happens during pair prog is very imp as it reduces the overall risks 2 a proj when team mmbrs leave. Pair prog is nt necessarily inefficient & there is evidence that a pair wrking 2gether is more efficient than 2 progmers wrking sep.Advantages: It supports the idea of collective ownership & responsibility 4 the sys.( Individuals r nt held responsible 4 prob.S with the code. Instead, the team has collective responsibility 4 resolving these prob.S). It acts as an in4mal review prcss bcause each line of code is looked at by at least two ppl. It helps support refac2ring, which is a prcss of SW improvement.( Whr pair prog & collective ownership r used, others bnefit immediately from the refac2ring so they r likely 2 support the prcss.)AGILE PROJ MNGT: The principal responsibility of SW proj managers is 2 manage the proj so that the SW is delivered on time & within the planned budget 4 the proj. The st&ard approach 2 proj mngmnt is plan-driven. Managers draw up a plan 4 the proj showing wht shud b delivered, when it shud b delivered & who will wrk on the devel of the proj deliverables. Agile proj mngmnt reqs a different approach, which is adapted 2 incre devel & the particular strengths of agile methods. SCRUM: The Scrum approach is a general agile method but its focus is on managing iterative devel rather than specific agile practices. Phases: 1.The initial phase is an outline planning phase whr you est. The general objectives 4 the proj & design the SW architecture.2. This is followed by a series of sprint cycles, whr each cycle devs an incr. Of the sys.3. The proj closure phase wraps up the proj, completes reqd docmn. Such as sys help frames & user manuals & assesses the lessons learned from the proj. SPRINT CYCLE: Sprints r fixed length, normally 2–4 weeks. They correspond 2 the devel of a release of the sys in XP.The starting point 4 planning is the prod backlog, which is the list of wrk 2 b done on the proj.The selection phase involves all of the proj team who wrk with the cstmr 2 select the features & funcnality 2 b deved during the sprint.Once these r agreed, the team organize thmselves 2 dev the sw.During this stage the team is isolated from the cstmr & the org., with all communications channelled through the so-called ‘Scrum master’.The role of the Scrum master is 2 protect the devel team from xtrnl distractions. At the end of the sprint, the wrk done is reviewed & presented 2 stakeholders. The next sprint cycle then bgins. Teamwrk in scrum:
The ‘Scrum master’ is a facilita2r who arranges daily meetings, tracks the backlog of wrk 2 b done, records decisions, measures progress against the backlog & communicates with cstmrs & mngmnt outside of the team. The whole team attends short daily meetings whr all team mmbrs shr info, describ their progress since the last meeting, prob.S that have arisen & wht is planned 4 the following day.SCRUM ADV.: The prod is broken down in2 a set of manageable & underst&able chunks.Unstable req. Do nt hold up progress. The whole team have visibility of everything & consequently team communication is improved.Cstmrs see on-time deli. Of incr.S & gain feedback on how the prod wrks.Trust b/w cstmrs & devers is est.Ed & a positive culture is created in which everyone expects the proj 2 succeed.Scaling Agile methods: Scaling up agile methods involves chngng these 2 cope with larger, longer projs whr there r multiple devel teams, perhaps wrking in different locations.‘Scaling up’ is concerned with using agile methods 4 deving large SW syss that cannt b deved by a small team.‘Scaling out’ is concerned with how agile methods can b introduced across a large org. With many yrs. Of SW dev experience. When scaling agile methods it is essential 2 maintain agile fundamentals -Flexible planning, frequent sys releases, continuous integration, tst-driven devel & good team communications.CH4: REQ ENG: prcss of est.Ing the services that the cstmr requ from a sys & the constraints under which it operates & is deved.USER REQ: Sttmnts in natural language plus dgms of the services the sys provides & its oper.Al constraints. Written 4 cstmrs.SYS REQ: A struc.D doc setting out detailed desc of the syst’s fnctions, services & oper.Al constraints. Defines wht shud b impl. So may b part of a contract b/w client & contrac2r. FUNC REQ: Sttmnts of services the sys shud provide, how the sys shud react 2 particular inputs & how the sys shud bhave in particular situations.May state wht the sys shud nt do.NON-FUNC: Constraints on the services or fnctions offered by the sys such as timing constraints, constraints on the devel prcss, st&ards, etc.Often apply 2 the sys as a whole rather than indiv. Features or services. May b more critical than funcnal req.. If these r nt met, the sys may b useless.DOMAIN REQ: Constraints on the sys from the domain of oper..Domain req. B new funcnal req., constraints on existing req. Or define specific computations.If domain req. R nt satisfied, the sys may b unwrkable.EX FUNC.: A user shall b able 2 search the appntmnts lists 4 all clinics.The sys shall generate each day, 4 each clinic, a list of patients who r expected 2 attend appntmnts that day. Each staff membr using the sys shall b uniquely identified by his or her 8-digit employee numbr.NON-FUNC IMP: may affect the overall architecture of a sys rather than the individual compo.S.May generate a no. Of related funcnal req that define sys services that r reqd. TYPES OF NON FUNC: Prod req:Reqwhich specify that the delivered prod mst bhave in a particular way e.G. Execution speed, reliability, etc.Org.Al req:Req which r a consequence of org.Al policies & procedures e.G. Prcss st&ards used, impl. Req.Xtrnl req:Req which arise from fac2rs which r xtrnl 2 the sys & its devel prcss e.G. Interoperability req, legislative req, etc. Metrics- Speed, size, ease of use, reliability, robustness, portability. DOMAIN REQ PROB: Understan-dability:Reqr expressed in the language of the application domain;This is often nt undrstd by sw engineers deving the sys.Implicitness: Domain specialists underst& the ra so well that they do nt think of making the domain req explicit. Struc. Of srs: preface, intro, glossary, user req definition, sys architecture, sys req spec., sys modls, sys evol., appendices, index.Ways of writing sys req spec: natural language, struc.D nat kanguage, design desc language, graphical ntations, mathmatical speci.Guidelines 4 writing req: Invent a st&ard 4mat & use it 4 all requ., Use language in a consistent way. Use shall 4 m&a2ry req, shud 4 desirable req., Use text highlighting 2 identify key parts of the requ., Avoid the use of computer jargon.,Include an explanation (rationale) of why a req is necessary.Prob.S with nat lang: Lack of clarity : Precision is difficult without making the document difficult 2 read.Req confusion: Funcnal & non-funcnal reqtend 2 b mixed-up.Req amalgamation:Several different req may b expressed 2gether.Struc.D spec: An approach 2 writing reqwhr the freedom of the req writer is limited & reqs r written in a st&ard way.This wrks well 4 sm types of req. E.G. Req 4 embdded control sys but is smtimes 2o rigid 4 writing bus. Sys req. 4m based spec: Defi.Of the funcn or entity.Desc of inputs & whr they come from..Desc of outputs & whr they go 2.Info about the info needed 4 the computation & other entities used.Desc of the action 2 b taken.Pre & post cond (if appropriate).The side effects (if any) of the funcn.Tabular spec: Used 2 supplement natural language.Particularly useful when you have 2 define a numbr of possible alternative courses of action.E.G, the insulin pump syss bases its computations on the rate of chnge of blood sugar level & the tabular spec. Explains how 2 calculate the insulin req. 4 different scenarios.REP activities:Req elicitation;Req analysis;Req valid.;Req mngmnt. REQ ELICITATION & ANAL.: Sw engineers wrk with a range of sys stakeholders 2 find out about the app domain, the services that the sys shud provide, the reqd sysper4mance, hardwr constraints, other sys, etc.Stages: req. Discovery: Interacting with stakeholders 2 discover their req. Domain req r also discovered at this stage, req. Classification & org.: Groups related req & organises thm in2 coherent clusters., req prioritization & negotitation: Prioritising req & resolving reqconflicts.. Req spec.: Req r documented & input in2 the next round of the spiral. PROB.S WITH REQ EL & ANA: Stakeholders don’t know wht they really want. They express req in their own terms. Diff stakeholders may have conflicting req. Org.Al & political fac2rs may influence the sys req.The req chnge during the analysis prcss. New stakeholders may emerge & the bus. Envi chnge.Typesof interview: Closed interviews based on pre-determined list of questions.Open interviews whr various issues r explored with stakeholders. EFFECTIVE INTERVIEW: B open-minded, avoid pre-conceived ideas about the req & r willing 2 listen 2 stakeholders.Prompt the interviewee 2 get discussions going using a springboard question, a req proposal, or by wrking 2gether on a pro2type sys.INTERVIEWS: Interviews r good 4 getting an overall underst&ing of wht stakeholders do & how they might interact with the sys. Interviews r nt good 4 underst&ing domain req.Req engineers cannt underst& specific domain terminology;Sm domain knowledge is so familiar that ppl find it hard 2 articulate or think that it isn’t worth articulating. SCENRAIOS: real life ex wht a sys shud do. Shud include: A description of the starting situation;A description of the normal flow of events;A description of wht can go wrong; In4mation about other concurrent activities;A description of the state when the scenario finishes.USE CASE: Use-cases r a scenario based technique in the UML which identify the ac2rs in an interaction & which describ the interaction itself.A set of use cases shud describ all possible interactions with the sys.High-level graphical modl supplemented by more detailed tabular description SCENARIO DIAG: may b used 2 add detail 2 use-cases by showing the sequence of event prcssing in the sys.ETHNOGRAPHY: A social scientist spends a considerable time observing & analysing how ppl actually wrk.Ppl do nt have 2 explain or articulate their wrk.Social & org.Al fac2rs of importance may b observed.Ethnographic studies have shown that wrk is usually richer & more complex than suggested by simple sys modls.Scope: Req. That r derived from the way that ppl actually wrk rather than the way I which prcss definitions suggest that they ought 2 wrk.Req that r derived from cooper. & awrness of other ppl’s activities(Awrness of wht other ppl r doing leads 2 chnges in the ways in which we do things)Ethnography is effective 4 underst&ing existing prcsses but cannt identify new features that shud b added 2 a sys.