Web Technologies and Programming Lecture 03

Introduction to RE RE basics Requirements specification RE process RE specifics in web engineering System modeling Modeling Requirement use-case diagram activity diagram

pptx58 trang | Chia sẻ: hoant3298 | Lượt xem: 553 | Lượt tải: 0download
Bạn đang xem trước 20 trang tài liệu Web Technologies and Programming Lecture 03, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Web Technologies and ProgrammingLecture 03 2Modeling web applicationsRequirement Engineering 3Modeling web applicationsSummary of the previous lecture4Development Process modelsoftware development process activitiesRequirement for a web development process modelRational unified process model (RUP)suitability for web application developmentSummary of the previous lecture5Project managementResponsibilities/tasks of a Project managerPlanningRisk management People managementReportingProposal writingTraditional vs. web project managementOutlineIntroduction to RERE basicsRequirements specificationRE processRE specifics in web engineeringSystem modelingModeling requirements61. Requirement EngineeringRequirements Engineering: the principles, methods, & tools for drawing, describing, validating, and managing project goals and needsGiven the complexity of Web apps, RE is a critical initial stage activity, but often poorly executed71. Requirement EngineeringIt may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.However, there are a number of generic activities common to all processesRequirements elicitation;Requirements analysis;Requirements validation;Requirements management81. Requirement Engineering9The requirements engineering process1. Requirement Engineering10Costs: Inadequate software architectures“Unforeseen” problemsbudget overrunsproduction delays“that’s not what I asked for”Low user acceptance1. Requirement Engineering11Why requirement engineering:requirements don’t define themselves (Bell & Thayer, 1976) removal of mistakes post hoc is up to 200 times more costly (Boehm, 1981) iterative collection and refinement is the most important function of a software engineer (Brooks, 1987)1. Requirement Engineering12Why requirement engineering:A study based on 340 companies in Austria, more than two thirds consider the SRS as the major problem in development process (1995)A study on Web applications, 16% systems fully meet their requirement while 53% deployed systems do not (Cutter Consortium, 2000) 1. Requirement Engineering13Why requirement engineering:A study among 8000 projects, 30% of projects fail before completion & almost half do not meet customer requirements (Standish group, 1994)Unclear objectives, unrealistic schedules & expectations, poor user participation2. RE basics14Identify and involve the stakeholdersthose that directly influence the requirementscustomers, users, developersWhat are their expectations?may be misaligned or in conflictmay be too narrowly focused or unrealistic2. RE basics15What is requirement?The descriptions of what the system should doservices that it provides and the constraints on its operationIEEE 601.12 definition of requirement:1) Solves a user’s problem2) Must be met or possessed by the system to satisfy a formal agreement3) Documented representation of conditions in 1 and 22. RE basics16Requirements typesFunctional requirements:statement of serviceshow system reacts to inputhow system behaves in particular situationNon-functional requirements:constraints on services (timing, quality etc.)applies as a whole2. RE basics17Requirements are collected iteratively and change Keys to requirement definition:NegotiationScenario-based discoveryClear definition of context and constraints3. Requirements specifications18process of writing down the user and system requirements in a requirements documentUser requirements (for users)who do not have a technical background.should be understand able to usersavoid notations, use simple tables, forms etc.System requirements (for Software engineers)starting point for the system designhow system provides the servicesinclude more technical information.3. Requirements specifications19Natural language specification:Stories or itemized requirementscreate a standard formatdistinguish between mandatory and desirable requirementsdon’t use the technical wordsassociate rationale with each requirement3. Requirements specifications20Structured specification:Includesdescriptioninputs/outputsdescription of the actionpre conditionpost condition4. RE processElicitation & NegotiationManagementDocumentationValidation &Verification214. RE process22Elicitation and negotiation:RE engineer involve the stakeholder to defineapplication domainservicesconstraintsSteps:requirement discoveryInterviewing, scenarios, questionnaires, use-cases etc.classification and organizationprioritization and negotiation4. RE process23Documentation:requirements are documented after consensusRequirement verification and validation:validated: doing right things?verification: doing things right?4. RE process24Requirements management:Requirements management is the process of managing changing requirements during the requirements engineering process and system development.understanding and controlling changesproblem analysis and change specificationchange analysis and costingchange implementation5. RE specifics in web25Distinguishing characteristics:Multidisciplinary:experts from different disciplines i.e. media experts, content experts, usability experts etc.challenging to achieve consensusUnavailability of stakeholders:many stakeholders such as users are unknown during RE processneed to find suitable representatives5. RE specifics in web26Distinguishing characteristics:Rapidly changing requirements & constraints:environment is highly dynamicharder to stabilize requirementsUnpredictable operational environment:impossible to control the operation environmentaffects the quality requirementschange of bandwidth can change response time5. RE specifics in web27Distinguishing characteristics:Legacy Systems:constrained by existing systemexisting components drive the possibilitiesQuality aspects:are decisive i.e. performance, security, availabilityharder to get exact specification5. RE specifics in web28Distinguishing characteristics:User interface:key success-critical aspectshould be aware of usability principles Quality of content:accuracy, objectivity, credibility, relevance, actuality, completeness, or clarity5.1 RE principles for web29Understanding the system contextweb apps are always a component of a larger entitywhy do we need the system?how will people use it?Involving the stakeholdersget all groups involvedbalance – one group’s gain should not come at the expense of anotherrepeat the process of identifying, understanding and negotiating5.1 RE principles for web30Iteratively define requirementsrequirements need to be consistent with other system aspects (UI, content, test cases)start with key requirements at a high level; basis for:feasible architectureskey system use casesinitial plans for the project5.1 RE principles for web31Risk Orientationrisk management is at the heart of the analysis processwhat are the greatest risks?integration issues / legacy systemsexpected vs. actual system qualityhow to mitigate risks?prototyping show changes to customer iterativelyintegrate existing systems sooner than laterModeling web applications321. System modelingProcess of developing abstract models of a systemRepresenting system using graphical notationsUML 331. System modelingeach model presents a different view or perspective of the systemExternal perspective: system context and environmentInteraction perspective: how system interact with environment or within the system componentsStructural perspective: how system is organizedBehavioral perspective: dynamic behavior of the system and how it responds to events.341. System modelingModels are used duringRE phase to derive system requirementsuse-case diagram, activity diagramdesign phase to describe the system to engineersclass diagrams, sequence diagrams etc.after implementationto document system’s structure and operation351. System modelingWhy system modeling?reduce complexitydocument design decisionsfacilitate communication among team members361. System modelingLevels – the “how” & “what” of an applicationAspects – objects, attributes, and relationships; function & processesPhases – Development cycleUser interfaceApplication LogicAnalysisDesignImplementationStructureBehaviorPhasesLevelsAspects37Modeling dimensions:1. System modeling“The Unified Modeling Language is a visual language for specifying and documenting the artifacts of systems” Structural – Class diagramsBehavioral – Use Case diagrams, State machine diagrams381. System modelingLevels – Information, node/link structure, UI & page layout separate.Aspects – Same as Software ApplicationsPhases – Approach depends upon type of applicationCustomization – Context information (user’s preferences, bandwidth restriction, device characteristic etc.) and allow to adopt web application accordinglyInfluence other three dimensions ContentPresentationAnalysisDesignImplementationStructureBehaviorPhasesLevelsAspectsHypertextCustomization391. System modelingRequirement modelinguse-case diagramactivity diagramContent modelingclass diagramNavigational modelingto model nodes and navigational structure among themPresentation modelingmodel user interface, page-layout401. System modelingFor Web-centric modeling, UML is used with some extensions from UWE (UML-based web engineering) Modeling requirementsUse-case Diagram: The goal of the diagram is to provide a high-level explanation of the relationship between the system and the outside world (set goals)Activity diagram: a graphical representation of workflows of stepwise activities and actions with support for choice, iteration and concurrency422.1 Use-case diagramComponents:The systemThe use case task referred to as the use case that represents a feature needed in a software system43System NameUse-case title2.1 Use-case diagramComponents:The actor(s) who trigger the use case to activateThe communication line to show how the actors communicate with the use case44>HR system2.1 Use-case diagramThe include relationship represents the inclusion of the functionality of one use case within another The extend relationship represents the extension of the use case to include optional functionality 45>include use-casebase use-case>Base use-caseExtension use-case2.1 Use-case diagramA use-case-generalization is a relationship from a child use case to a parent use case, specifying how a child can specialize all behavior and characteristics described for the parent46GeneralizedSpecializeduserRegistered user2.1 Use-case diagramWeb specific requirements:Need to distinguish between functional and navigational use-casesUWE provides > to represent a navigational use-case while > to represent a functional use-case472.1 Use-case diagram48Consider an online video sharing system:Users can search and view the videosA user must be a register user to share videos2.1 Use-case diagram49Online video sharing systemuserRegistered user>Search a video>Watch a video>register>share a video>login>>2. The activity diagramElements of an activity diagram:An activity is a step in a process where some work is getting doneThe transition takes place because the activity is completed50activityRead a pageTurn the page2. The activity diagramElements of an activity diagram:A guard condition can be assigned to a transition to restrict use of the transition51Learn drivingDrive the car[get driving license]2. The activity diagramDecisionsMerge pointStart and end522. The activity diagram53User fill in the registration formUser selects submit buttonCorrect ?System shows error messageUser corrects inputNoUser is registered2. The activity diagramUWE activity diagram elements:userAction : user’s action or responsesystemAction : system’s actiondisplayAction : display actionnavigationAction : navigationdisplayPin : outputinteractionPin : input542. The activity diagram55>registratinForm{type=form}name{type=text}Email{type=email}Password{type=password}>inputData{validated}nameemailpassword>saveDataor within the system componentsSUMMARYIntroduction to RERE basicsRequirements specificationRE processRE specifics in web engineeringSummarySystem modelingModeling Requirementuse-case diagramactivity diagram57THANK YOU

Các file đính kèm theo tài liệu này:

  • pptxlecture_03_wt_requirement_engineering_7263_2028565.pptx
Tài liệu liên quan