Requirements Engineering Process + Requirement Elicitation

Embed Size (px)

DESCRIPTION

Requirements Engineering Process + Requirement Elicitation; SoftWare Engineering Slides

Citation preview

  • Requirements Engineering ProcessesProcesses used to discover, analyse and validate system requirements

  • ObjectivesTo describe the principal requirements engineering activitiesTo discuss feasibility of a system.To introduce techniques for requirements elicitation and analysis

  • Topics coveredFeasibility studiesRequirements elicitation Requirement elicitation technique Requirement analysis

  • Requirements engineering processesThe processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirementsHowever, there are a number of generic activities common to all processesRequirements elicitationRequirements analysisRequirements validationRequirements management

  • The requirements engineering process

  • Feasibility studiesA feasibility study decides whether or not the proposed system is worthwhileA short focused study that checksIf the system contributes to organisational objectivesIf the system can be engineered using current technology and within budgetIf the system can be integrated with other systems that are used

  • Feasibility study implementationBased on information assessment (what is required), information collection and report writingQuestions for people in the organisationWhat if the system wasnt implemented?What are current process problems?How will the proposed system help?What will be the integration problems?Is new technology needed? What skills?What facilities must be supported by the proposed system?

  • Requirement Elicitation Sometimes called requirements elicitation or requirements discoveryInvolves technical staff working with customers to find out about the application domain, the services that the system should provide and the systems operational constraintsMay involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders

  • Requirements Elicitation Techniques

    Interviewing and questionnairesRequirements workshopsBraining Storming and idea reductionStoryboards or ScenariosUse CasesEthnographyPrototyping

  • In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed.There are two types of interview Closed interviews where a pre-defined set of questions are answered. Open interviews where there is no pre-definedagenda and a range of issues are explored with stakeholders.Interviewing

  • Interviews in practiceNormally a mix of closed and open-ended interviewing.Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system.Interviews are not good for understanding domain requirementsRequirements engineers cannot understand specific domain terminology;Some domain knowledge is so familiar that people find it hard to articulate or think that it isnt worth articulating.

  • Effective interviewersInterviewers should be open-minded, willing to listen to stakeholders and should not have pre-conceived ideas about the requirements.They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as what do you want.

  • Technique: Requirements WorkshopThe requirements workshop is perhaps the most powerful technique for eliciting requirements.It gathers all key stakeholders together for a short but intensely focused period.The use of an outside facilitator experienced in requirements management can ensure the success of the workshop. Brainstorming is the most important part of the workshop.

  • Preparing for the workshopSelling the workshop concept to stakeholdersEnsuring the Participation of the Right StakeholdersLogistics Includes travel, lighting, and even afternoon sugar filled snacks.Warm-up materialsProject-specific information, Out-of-box thinking preparation

  • Role of the Facilitator Establish professional and objective tone to the meeting. Start and stop the meeting on time. Establish and enforce the rules for the meeting. Introduce the goals and agenda for the meeting.Manage the meeting and keep the team on track. Facilitate a process of decision and consensus making.Make certain that all stakeholders participate and have their input heard. Control disruptive or unproductive behavior.

  • Workshop Problems andSuggestionsTime Management Its difficult to get going after breaks and lunch. Key shareholders may be late returning Grandstanding, domineering positions Lack of input from stakeholdersNegative comments, petty behaviors, and turf warsFlagging energy after lunchFacilitator keeps a timer for all breaks and fines anyone that is late, everyone gets one free pass. Everyone gets one 5 minute position statement.Facilitator encourages everyone to use 5-minute position and great idea ticket. Use Cheap Shot Tickets, all others cost money. Lite lunches, afternoon breaks, rearrange seating

  • Technique: BrainstormingBrainstorming involves both idea generation and idea reduction.The most creative, innovative ideas often result from combining, seemingly unrelated ideas.Various voting techniques may be used to prioritize the ideas created.Although live brainstorming is preferred, web-based brainstorming may be a viable alternative in some situations

  • Rules for BrainstormingDo not allow criticism or debate. Let your imagination soar Generate as many ideas as possible Mutate (alter) and combine ideas Idea Reduction Pruning ideas that are not worthy of further discussion Grouping of similar ideas into one super topic Prioritize the remaining ideas

  • ScenariosScenarios are real-life examples of how asystem can be used. They should include A description of the starting situation; A description of the normal flow of events; A description of what can go wrong; Information about other concurrent activities; A description of the state when the scenario finishes.

  • LIBSYS scenario

  • Social and organisational factorsSoftware systems are used in a social and organisational context. This can influence or even dominate the system requirementsSocial and organisational factors are not a single viewpoint but are influences on all viewpointsGood analysts must be sensitive to these factors but currently no systematic way to tackle their analysis

  • ExampleConsider a system which allows senior management to access information without going through middle managersManagerial status. Senior managers may feel that they are too important to use a keyboard. This may limit the type of system interface usedManagerial responsibilities. Managers may have no uninterrupted time where they can learn to use the systemOrganisational resistance. Middle managers who will be made redundant may deliberately provide misleading or incomplete information so that the system will fail

  • EthnographyA social scientists spends a considerable time observing and analysing how people actually workPeople do not have to explain or articulate their workSocial and organisational factors of importance may be observedEthnographic studies have shown that work is usually richer and more complex than suggested by simple system models

  • Focused ethnographyDeveloped in a project studying the air traffic control processCombines ethnography with prototypingPrototype development results in unanswered questions which focus the ethnographic analysisProblem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant

  • Ethnography and prototyping

  • Scope of ethnographyRequirements that are derived from the way that people actually work rather than the way I which process definitions suggest that they ought to workRequirements that are derived from cooperation and awareness of other peoples activities

  • The requirements analysis process

  • Problems of requirements analysisStakeholders dont know what they really wantStakeholders express requirements in their own termsDifferent stakeholders may have conflicting requirementsOrganisational and political factors may influence the system requirementsThe requirements change during the analysis process. New stakeholders may emerge and the business environment change

  • Key pointsThe requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements managementRequirements analysis is iterative involving domain understanding, requirements collection, classification, structuring, prioritisation and validationSystems have multiple stakeholders with different requirements