Presentation on theme: "Requirements Elicitation"— Presentation transcript:
1Requirements Elicitation Requirement techniquesRequirements ElicitationPresentation based on courses given at SEI Carnegie Mellon (USA) and Kingston Univ (GB)
2Requirements Elicitation System engineeringProjectsRequirement EngineeringBasic introductionCase StudiesStandardsRE TechniquesSoftware systemsReactive systemsReq. ElicitationReq. ValidationReq. ManagementReq. Expression &ModellingReq. TraceabilityExchanging Req.Presentation based on courses given at SEI Carnegie Mellon (USA) and Kingston Univ (GB)
3Contents Requirements elicitation Guidelines Methodology Basic techniques for eliciting requirementsInterviewsMeetingsPlanning...
4Some basic points Elicitation is not Acquisition Requirements are not available like sensor data Not just read them systematically !!Elicitation is not specification and modellingToo much importance has been given to expression and modellingRE Determines the success of the missionElicitation detrmines the success of the RE process
5What Is Elicitation ? Process of identifying needs Front End to systems developmentInvolves social, communicative issues and Technical issuesRequirement expression is the step to model the requirements.
6A common Problem !! What is your need ? I need a system that works OK Robust and respond to my wishes
7As problems in social life What is the requirement ?AVOID MISUNDERSTANDING !!
8A simple scenario I need a book What for ? Or What discipline ? To .....; in fact anything to level up my terminalSo you any item but Not necessarily a book
9Elicitation : a subset of goals Identify the relavant parties . The stackholdersGather the Wish List for each stachholderDocument and refine the Wish listExpected propertiesUnambiguousCompleteVerifiableConsistentModifiableTraceable
10Common generic problems Scope : too much or too littleUnderstandings : Users and developpersUsers have an incomplete understanding of their needsAnalysts and SE have a poor knowledge of problem domainEase of omitting obvious information Volatility : changing requirements
11The Scope problem Establish a bounday conditions for the target system Organisation and context analysis
12The Misunderstanding pb Share the same vision for a requirement
13Some data on the Pb56 % of errors were due to poor communication between user and analysteSuch errors cost 82% of the available staff timeThree main issuespeople involved comes from different backgroundsLanguage used may be too informal or too formalA large amount of information to be commnicated and not really structured
14The misun ... Stakholders may be located at different levels May correspond to levels to abstractionFrom informal knowledge to ...formal expressionNotion of maturity levelsDont mix up with abstraction levelsMany people are involved : QuestionsWhen in the eliciaition process ?At what level ?
15The Volatility problem REQUIREMENTS EVOLVE : A basisSome requiremenrs are more emphasized than needed during elecitation processThe boss is always rightsHis needs are more considered even not mature and ambigousChange may occur due toMisunderstandingScope
16An Elicitation methodology Framework (DOD-SEI) basic remark : Most requirements problems are due to requirements elicitationGeneral remark . No technique is comprehensive enough to adequatly cover all mentionned issuesObjective : Synthesize all methods and techniques into a methodology which can be instantiated upon a target system´s atributes
17See table 4.1 in SEI document Information gatheringRequirements Expression and analysis (see later course on this topic)Validation
19Fact findings User Developper Identify Stackholders Determine operational and problem contexteIdentify other systems´Perform context analysisIdentify domain expertsId. DomainConduct technological surveyAsses cost/implementation
20Requirements gathering UserDevelopperGet Wish ListClassify wish list* Functional* NFR* Env.* ...See paper on requirements categrorisation
21Evaluation and rationalisation UserDevelopperPerform abstraction to answer questionsee interview techniquesPerform risk assessmentCost benefit ...
22Prioritisation User Developper Prioritisation of requirements basis : cost, criticality, ...* Dtermine criticality
23Integration and validation UserDevelopperAdress completeness : TBD typevalidate req with respect concept of operationDecide to go on next step* Demo* prototype* ...Consistency checking
24Conclusion on the methodology Abstract methodologyStill be considered as guideAn evaluation crireria to be developped :No information on evaluation
25The stackholder connection Sometimes called requirements analysis or requirements discoveryInvolves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraintsMay involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders
27Gathering Information About... The organisationgoals, structure, functional units, policiesThe peopleauthority, duties, relationships, information, needsThe worktasks, work flows, procedures, schedules, volumes, performance criteriaThe work environmentwork areas, resources
28Gathering Information From... Documentationcharts, manuals, job descriptions, forms, reportsSystem users and managersExternal sourcesother companies, vendors, publications, seminars, workshops, on-line data services
29InterviewsThe requirements engineer or analyst discusses the system with different stakeholders and builds up an understanding of their requirements.Identifywork flowsfactors that influence the operations of systemsthe elements (documents, procedures, policies etc.) that make up systems
30Types of InterviewsClosed interviews. The requirements engineer looks for answers to a pre-defined set of questionsgoal-directed and systematicOpen interviews There is no predefined agenda and the requirements engineer discusses, in an open-ended way, what stakeholders want from the system.Appropriate when we want to explore an issueestablish rapport and obtain a broad view
31Interviewing essentials Interviewers must be open-minded and should not approach the interview with pre-conceived notions about what is requiredStakeholders must be given a starting point for discussion. This can be a question, a requirements proposal or an existing systemInterviewers must be aware of organisational politics - many real requirements may not be discussed because of their political implications
32Interview Steps Preparing Planning Opening and Closing Conducting Following up
33Preparing for the interview Revieworganisation reportsannual reportsstatements of departments goalslong-range planning goalsexisting procedure manualssystems documentationunderstand their language
34Planning of Interviews Identify sourcesprepare* purpose, outline of points to covervenueappointmentsprepare the interviewee* points to cover, useful documents
35Questioning Open questions leading questions tell me what happens when a customer callsleading questionsbe wary of negative responsesexceptions?Subjects who try to please
36Listening Judge content and not delivery withhold evaluation and responsebe flexiblework at listeningresist distractionskeep your mind openlisten for ideas
37Opening and closing and Following Up the interview Introduce yourselfstate the purpose of the interviewbriefly summarise the areas that have been discussed, highlight important points and your understanding of themthank the interviewee for the timeAsk closed questionsDocument the results
38Questionnaires Validity - sample size, audience Reliability Questions - open ended- fill in the blank- multiple choice- rating scales
39ScenariosScenarios are stories which explain how a system might be used. They should include- a description of the system state before entering the scenario- the normal flow of events in the scenario- exceptions to the normal flow of events- information about concurrent activities- a description of the system state at the end of the scenario
40ScenariosScenarios are examples of interaction sessions which describe how a user interacts with a systemDiscovering scenarios exposes possible system interactions and reveals system facilities which may be required Operational semantics
41Observation and social analysis People often find it hard to describe what they do because it is so natural to them. Sometimes, the best way to understand it is to observe them at workEthnography is a technique from the social sciences which has proved to be valuable in understanding actual work processesActual work processes often differ from formal, prescribed processes
42Meetings Meetings consume resources Meetings have different objectives must improve quality of meetingsMeetings have different objectivessolve problems, clarify issuesbrainstorm solutions to problemsresolve conflictsconduct reviewscollect and merge facts and datareport progressassign actions
43Meetings: PlanningDefine clearly the expected results or outcomes of the meetingFind if possible a way to eliminate the need for the meetingdo we really need the outcome of this meeting at this moment?Is there another more efficient and more effective way to accomplish what is to be accomplished by holding this meeting?If yes and no are the answers to the two questions then proceed
44Meetings: Planning Prepare agenda for the meeting reasonable time allocation for each topiccirculate at least two days before the meetingto allow time for the attendees to prepare, comment and make schedule arrangementsidentify and notify required meeting attendees. Must have the right peoplethe appropriate information and knowledge to support meeting goals and objectivesthe authority )direct or delegated) to make decisions and commitments if required by the meeting’s goals and objectivesthe need to understand what is going on and the rationale behind any decisions or commitments made during the meeting
45Meetings: Planning Meeting location considerations room size, lighting, noise, temperature, humidity can distractneed for audio/visual aids in working orderStart and Finish on timeRecord and publish minutesHave handouts ready for distributionreview the agenda, meeting goals and objectives firstdiscourage interruptions and deflections from the topic at handfollow the agenda schedule as closely as possible
46Active Listener Guidelines Clear your mind of everything except the speaker, the topic and what the speaker is actually saying. Prevent trying to read more into what the speaker is saying than the speaker is actually sayingCapture as accurately as possible the information that the speaker is conveyingLet the speaker know by actions that s/he is interested in what is being saidAsk questions as they arise to clarify points, indicate understanding and provide feedback to the speaker
47Active Listener Guidelines Ask that the central ideas, themes and summaries be repeated to assure complete understandingDo not attempt to formulate replies, rebuttals or counterexamples while the speaker is talkingDo not draw conclusions until you have heard the whole storyAccept that understanding is not agreeingDo not be afraid to ask if there is something that you have not been told.
48MethodologiesA number of techniques are available to describe the workings of a systemMany people have taken a number of these techniques and produced a method for using them to arrive at a specification
49Methodologies Division Main DivisionData drivenSSADMProcess drivenYourdonJSDIs there a universally best methodology?NoCan I combine methodologies?Maybe
50Comparison of Methodologies Can one compare the available methodologies?against an ideal methodologynot feasible because no suitable specification of an ideal methodology existsassess the features and facilities of each methodology within a formalised frameworkinvent questions about each methodologyask the questions for each methodologymerge and describe the resultsdecide?
51Typical Comparison Questions For the comparison one may askDoes the methodology cover all phases? Which ones? How thoroughly.Are the steps fairly proceduralised or does the methodology only give broad directions? Are analysis, design and implementation given equal weight?Is it data or process analysis oriented?Does it cover prototyping and incremental development?How are the results of analysis and design expressed?Is the methodology supported by software?What types of applications is it suited to? History?
52Decomposition Diagrams A high-level organisation (or function or activity) is decomposed into lower organisations (or functions or activities). The lower we go in the hierarchy the greater the detail revealedUsed to show organisation, system, program, file and report structuresorganisationfunctionsprocessesproceduresprogram structures
53Viewpoints for requirements elicitation The Preview approach adresses the cases whereSources from radical sourcesIdentify key business driversIncremental process for requirement elicitation
54Limited only to requirement elicitation PREVIEW ComponentsViewpoint name : an identifierViewpoint focus : interaction, domain, stakeholderViewpoint concerns : all concerns applicableViewpoint sources : individuals, documentsViewpoint requirements : Req. from sourceViewpoint history : changes recordLimited only to requirement elicitationand NOT Validation
55Example (Sommerville paper ICRE-98) Emergency braking systemViewpoint name : emergency braking systemViewpoint focus : The protection system of the train which must detect dangerous condistions and apply emergency braking to bring train to a safe stateViewpoint concerns : Safe compatibilityViewpoint sources : systems design; function spec of existing protection software
56ExampleViewpoint requirements : 1. Detection of excess speed , if the speed of the train exceeds the safe speedfor the current track segment by more than 6 kmh emergency braking must be applied2. Detection of overshooting, if the signal sensor indicates a danger setting and the front of the train has entered the signalled track segment, emergency braking shall be applied3. Frequency of invocation , detection of excess speed, detection of overshooting, and determining the necessity of emergency brake application shall be performed once every iteration of the on board software application cycleViewpoint history : case of evolving requirement(following an accident or a failure)
57Conclusions Elicitation Process is The FIRST PHASE Needs to be successful Just DO ITBe convinced it needs to be doneAny technique will do (see resources and papers)
59Reading and assignment PapersChristel & Kang : Issues in requirement elicitationRead sections 1 through 6 of the paper Issues in Requirements Elicitation and answer the following questions:Describe an example requirements elicitation for each of the three major categories of elicitation problems and suggest a technique for solution.What are the chief differences between the user-oriented and developer-oriented tasks of requirements elicitation?Contact XX for requirement elicitation for the following concept of operationHPI SchedulerWeb site for RE courseA students utilities to be done at HPI (web site for students).page