WIXLIB

Questions Why does prototyping fall between waterfall andagile? What is the process model of the SoftwareEngineering Projects? Does an agile process model deliver maintainablesoftware? Give a couple of (motivated) arguments.Requirements EngineeringMark van den BrandTom Verhoeff/ Faculteit Wiskunde en InformaticaRequirements EngineeringPAGE 1Domain Analysis The process by which a software engineer learnsabout the domain to better understand the problem: 03-05-12PAGE 2The domain is the general field of business ortechnology in which the clients will use the softwareA domain expert is a person who has a deepknowledge of the domainBenefits of performing domain analysis: / Faculteit Wiskunde en Informatica03-05-12Faster developmentBetter systemAnticipation of extensions/ Faculteit Wiskunde en Informatica03-05-12PAGE 3

Domain analysisDomain analysisDomain analysis document:Example document:http://www.site.uottawa.ca/ oductionGlossaryGeneral knowledge about the domainCustomers and usersThe environmentTasks and procedures currently performedCompeting softwareSimilarities to other domains/ Faculteit Wiskunde en Informatica03-05-12PAGE 4Starting Point for Software Projects/ Faculteit Wiskunde en InformaticaBEvolution ofexisting systemCDgreen field project!/ Faculteit Wiskunde en Informatica03-05-12A problem can be expressed as: RequirementsClients have producedmust be determinedrequirementsAPAGE 5Defining Problem and Scope Newdevelopment03-05-12PAGE 6A difficulty the users or customers are facing,Or as an opportunity that will result in some benefitsuch as improved productivity or sales. The solution to the problem normally will entaildeveloping software A good problem statement is short and succinct/ Faculteit Wiskunde en Informatica03-05-12PAGE 7

Defining the ScopeProcesses in requirements engineering Narrow the scope by defining a more preciseproblem List all the things you might imagine the system doing Exclude some of these things if too broad Determine high-level goals if too narrowRequirements elicitationRequirements specificationRequirements validation and verificationRequirements negotiationSpecificationExample: A university registration systemInitial list of problemswith very broad scopeNarrowedscopeScope ofanother systemElicitationbrowsing coursesregisteringroom allocationexam schedulingfee paymentbrowsing coursesregisteringroom allocationNegotiation03-05-12PAGE 8/ Faculteit Wiskunde en InformaticaWhat is a Requirement ?Types of Requirements It is a statement describing either 1) an aspect of what the proposed system must do,or 2) a constraint on the system’s development.In either case it must contribute in some way towardsadequately solving the customer’s problem;the set of requirements as a whole represents anegotiated agreement among the stakeholders.A collection of requirements is a requirementsdocument./ Faculteit Wiskunde en InformaticaValidationexam schedulingfee payment/ Faculteit Wiskunde en InformaticaDocumentation &Management03-05-12PAGE 1003-05-12PAGE 9Functional requirements Describe what the system should doQuality requirements Constraints on the design to meet specified levels ofqualityPlatform requirements Constraints on the environment and technology of thesystemProcess requirements Constraints on the project plan and developmentmethods/ Faculteit Wiskunde en Informatica03-05-12PAGE 11

Functional RequirementsQuality Requirements What inputs the system should accept What outputs the system should produce What data the system should store that othersystems might use What computations the system should perform The timing and synchronization of the above/ Faculteit Wiskunde en Informatica03-05-12All must be verifiableExamples: Constraints on PAGE 12Response timeThroughputResource usageReliabilityAvailabilityRecovery from failureAllowances for maintainability and enhancementAllowances for reusability/ Faculteit Wiskunde en Informatica03-05-12VragenConceptual modeling Why is domain analysis crucial for goodrequirements? Why is scoping important in problem definition? What is the difference between functional and nonfunctional requirements? What is the relation between requirements andtesting? You model part of reality: the Universe of Discourse (UoD) This model is an explicit conceptual model People in the UoD have an implicit conceptual model of thatUoD Making this implicit model explicit poses problems:PAGE 13 analysis problems negotiation problems/ Faculteit Wiskunde en Informatica03-05-12PAGE 14/ Faculteit Wiskunde en Informatica03-05-12PAGE 15

Conceptual modelingConceptual modeling Requirements engineering is difficult Beware of subtle mismatches: a library employee may also be a client there is a difference between a book and a copy of abook status info present / not present is not sufficient; a(copy of a) book may be lost, stolen, in repair, . Success depends on the degree with which wemanage to properly describe the system desired/ Faculteit Wiskunde en Informatica03-05-12PAGE 16/ Faculteit Wiskunde en InformaticaConceptual modelingConceptual modeling Humans as sources of information: How we study the world around us: different backgrounds short-term vs long-term memory human prejudices limited capability for rational thinking/ Faculteit Wiskunde en Informatica 03-05-12PAGE 17people have a set of assumptions about a topic they study(paradigm)this set of assumptions concerns: how knowledge is gathered how the world is organized this in turn results in two dimensions: subjective-objective (wrt knowledge) conflict-order (wrt the world) 03-05-12PAGE 18which results in 4 archetypical approaches to requirementsengineering/ Faculteit Wiskunde en Informatica03-05-12PAGE 19

Conceptual modelingElicitation techniques Four approaches to RE: Asking: functional (objective order): the analyst is the expertwho empirically seeks the truth social-relativism (subjective order): the analyst is a change agent’. RE is a learning process guided by theanalyst radical-structuralism (objective conflict): there is astruggle between classes; the analyst chooses foreither party neohumanism (subjective conflict): the analyst is kindof a social therapist, bringing parties together/ Faculteit Wiskunde en Informatica03-05-12PAGE 20 interviewDelphi techniquebrainstorming session Observing task analysisscenario analysisethnographyform analysissynthesis from existingsystemBrainstorming Conduct a series of interviewsAsk about specific detailsAsk about the stakeholder’s vision for the futureAsk if they have alternative ideasAsk for other sources of informationAsk them to draw diagrams analysis of naturallanguage descriptionsdomain analysisBusiness ProcessRedesign (BPR)prototyping/ Faculteit Wiskunde en InformaticaInterviewing Others:03-05-12PAGE 21Appoint an experienced moderatorArrange the attendees around a tableDecide on a ‘trigger question’Ask each participant to write an answer and passthe paper to its neighbour!!!!!! / Faculteit Wiskunde en Informatica03-05-12PAGE 22Joint Application Development (JAD) is a technique based onintensive brainstorming sessions/ Faculteit Wiskunde en Informatica03-05-12PAGE 23

ObservationTask Analysis Task analysis is the process of analyzing the waypeople perform their jobs: the things they do, thethings they act on and the things they need to know. The relation between tasks and goals: a task isperformed in order to achieve a goal. Task analysis has a broad scope.Read documents and discuss requirements withusersShadowing important potential users as they dotheir work ask the user to explain everything he or she is doingSession video taping/ Faculteit Wiskunde en Informatica03-05-12PAGE 24/ Faculteit Wiskunde en Informatica03-05-12PAGE 25Task AnalysisScenario-Based Analysis Task analysis concentrates on the current situation.However, it can be used as a starting point for a newsystem: Provides a more user-oriented view perspective onthe design and development of an interactivesystem. The defining property of a scenario is that it projectsa concrete description of an activity that the userengages in when performing a specific task, adescription sufficiently detailed so that the designimplications can be inferred and reasoned about. users will refer to new elements of a system and itsfunctionality scenario-based analysis can be used to exploit newpossibilities/ Faculteit Wiskunde en Informatica03-05-12PAGE 26/ Faculteit Wiskunde en Informatica03-05-12PAGE 27

Scenario-Based Analysis (example) first shot: Scenario-Based Analysischeck due back dateif overdue, collect finerecord book as being available againput book backas a result of discussion with library employee: what if person returning the book is not registered as a client? what if the book is damaged? how to handle in case the client has other books that are overdue,and/or an outstanding reservation?/ Faculteit Wiskunde en Informatica03-05-12PAGE 28Scenario viewStandard view concrete descriptionsfocus on particular instanceswork-drivenopen-ended, fragmentaryinformal, rough, colloquialenvisioned outcomesabstract descriptionsfocus on generic typestechnology-drivencomplete, exhaustiveformal, rigorousspecified outcomes/ Faculteit Wiskunde en InformaticaForm analysisPrototypingProceedings request form:Client name Title Editor Place Publisher Year 03-05-12PAGE 29The simplest kind: paper prototype. a set of pictures of the system that are shown to usersin sequence to explain what would happenThe most common: a mock-up of the system’s UI Written in a rapid prototyping languageDoes not normally perform any computations, accessany databases or interact with any other systemsMay prototype a particular aspect of the systemCertainty vs uncertainty/ Faculteit Wiskunde en Informatica03-05-12PAGE 30/ Faculteit Wiskunde en Informatica03-05-12PAGE 31

QuestionsUse case analysis Which problems can arise when making explicit theimplicit model in conceptual modeling? What is the purpose of requirements elicitation? Name a number of elicitation techniques? / Faculteit Wiskunde en Informatica03-05-12PAGE 32Use-Cases: describing how the user willuse the system A use case is a typical sequence of actions that auser performs in order to complete a given task 03-05-12/ Faculteit Wiskunde en InformaticaPAGE 33A use case should PAGE 3403-05-12Use cases The objective of use case analysis is to model thesystem from the point of view of how users interact with this system when trying to achieve their objectives.It is one of the key activities in requirements analysisA use case model consists of a set of use cases an optional description or diagram indicating howthey are related/ Faculteit Wiskunde en InformaticaDetermine the classes of users that will use thefacilities of this system (actors) Determine the tasks that each actor will need to dowith the system Cover the full sequence of steps from the beginning ofa task until the end.Describe the user’s interaction with the system . Not the computations the system performs.Be written so as to be as independent as possible fromany particular user interface design.Only include actions in which the actor interacts withthe computer. Not actions a user does manually/ Faculteit Wiskunde en Informatica03-05-12PAGE 35