Requirements Engineering for Web Applications. SR: System Vision Document Written by key stakeholders Written by key stakeholders An executive summary.

Slides:



Advertisements
Similar presentations
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Advertisements

Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Use-case Modeling.
1 CS 426 Senior Projects Chapter 4: Use Case Modeling [Arlow and Neustadt, 2002] February 8, 2007.
TSS Architecture Definition Context. TSS Scoping Study Context Detailed Requirements Specification (products, functionality) High Level Architecture Description.
SE 555 Software Requirements & Specification1 Use-Case Modeling: Overview and Context.
Documenting Requirements using Use Case Diagrams
Use Case Analysis Chapter 6.
1 CS 425 Software Engineering Project Preparation Use Case Modeling [Based on Chapters 3 & 4, Arlow and Neustadt, “UML and the Unified Process,” Addison-Wesley,
1 Team Skill 3 - Defining the System (Chapters of the requirements text) CSSE 371 Software Requirements and Specification Don Bagert, Rose-Hulman.
Use Cases.
1 CS 426 Senior Projects Chapter 4: Use Case Modeling [Arlow and Neustadt, 2005] February 5, 2009.
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
Software Requirements and the Requirements Engineering Process Chapters 5 and 6.
Chapter 7: The Object-Oriented Approach to Requirements
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Developing Enterprise Architecture
Chapter 4 Requirements Engineering
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
Object Oriented Analysis By: Don Villanueva CS 524 Software Engineering I Fall I 2007 – Sheldon X. Liang, Ph. D.
Requirements Analysis
Chapter 4 User Experience Model. User experience model (Ux) Visual specification of the user interface Visual specification of the user interface Both.
Chapter 5 Analysis Model. Analysis model (AM) The first step in describing how the system will implement the requirements specification The first step.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Business Analysis and Essential Competencies
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
Object-Oriented Analysis and Design An Introduction.
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University
Software Requirements (Advanced Topics) “Walking on water and developing software from a specification are easy if both are frozen.” --Edward V Berard.
Software Engineering Chapter 7 Fall Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
Chapter 9 요구사항 모델링: 시나리오 기반 방법론 Requirements Modeling: Scenario-Based Methods 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim.
 A software application is like a city  Modeling = Architecture  OOP = Civil Engineering  UML Classes = Blueprints of Buildings  UML is a common.
Chapter 7 Applying UML and Patterns Craig Larman
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University.
Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Engineering Lab Use Cases Faculty of Information system Technology.
1 Use Case Diagrams Use Case Actor Use case description Use case realization (Scenario) Use case relationships –Extends –Uses.
Requirements Engineering for Web Applications. SR: System Vision Document Written by key stakeholders Written by key stakeholders An executive summary.
Chapter 4: Use Case Modeling [Arlow and Neustadt, 2005] CS 790M Project preparation (II) University of Nevada, Reno Department of Computer Science & Engineering.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
CS212: Object Oriented Analysis and Design Lecture 32: Use case and Class diagrams.
CSE 403, Software Engineering Lecture 3 Requirements.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
Prof. Hany H. Ammar, CSEE, WVU, and
Requirements Analysis
Use Case Model Use case description.
4+1 View Model of Software Architecture
Requirements Management with Use Cases Module 4: Analyze the Problem Requirements Management with Use Cases Module 4: Analyze the Problem.
Requirement Discipline Spring 2006/1385 Semester 1.
Use Case, Component and Deployment Diagrams University of Sunderland.
Appendix Object-Oriented Analysis and Design: Use Cases and Sequence Diagrams Modern Systems Analysis and Design Fifth Edition Jeffrey A. Hoffer Joey F.
Team Skill 3 - Defining the System (Chapters of the requirements text ) Sriram Mohan 1.
George Wang, Ph.D. COMP 380/L Lesson 2. Use Case Use cases are a way to capture system functionalities (i.e., functional requirements) Based on use case.
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However,
Use Case Analysis Chapter 6.
Software Requirements and the Requirements Engineering Process
CMPE 280 Web UI Design and Development August 29 Class Meeting
Recall The Team Skills Analyzing the Problem (with 5 steps)
Requirements Elicitation and Elaboration
Other Requirement Artifacts
CS 420/620 HCI Use Case Modeling Project Preparation
CS 425 Software Engineering
CS 425/625 Software Engineering
SWR Use Case Modeling Francis Bordeleau (Mercury Computer Systems/Carleton University) Francois-Xavier Lebas (Thales)
Presentation transcript:

Requirements Engineering for Web Applications

SR: System Vision Document Written by key stakeholders Written by key stakeholders An executive summary of the solution An executive summary of the solution A high-level description of the problem that the system will address as a set of issues stated in business terms. A high-level description of the problem that the system will address as a set of issues stated in business terms. The list of stakeholders and users of the system with their descriptions, concerns, and responsibilities. The list of stakeholders and users of the system with their descriptions, concerns, and responsibilities. A list of features of the system expressed in business terms. A list of features of the system expressed in business terms. A list of system constraints described in business terms. A list of system constraints described in business terms. A list of nonfunctional constraints related to overall enterprise environment, including development standards and processes of the organization, limitation in cost or resources, etc. A list of nonfunctional constraints related to overall enterprise environment, including development standards and processes of the organization, limitation in cost or resources, etc.

SR: User-Stories An effective intermediate stop to the use cases An effective intermediate stop to the use cases A half-day workshop with representative of the user community A half-day workshop with representative of the user community Ask them to write up what they expect the possible interactions of the various users with the system are as stories Ask them to write up what they expect the possible interactions of the various users with the system are as stories Not give the users too much time to write stories. Not give the users too much time to write stories. User stories are a throwaway artifact, not maintained. User stories are a throwaway artifact, not maintained. Used as a basis for system use cases Used as a basis for system use cases Good for user experience model Good for user experience model

SR: Use Case Model - 1 Actors Actors A role played by a person or system that is external to the system but interacts with it. A role played by a person or system that is external to the system but interacts with it. System use case System use case A sequence of actions that describe the interaction between the actors and the system for a specific task or function A sequence of actions that describe the interaction between the actors and the system for a specific task or function Use case model Use case model UML diagrams and the use case definitions UML diagrams and the use case definitions A synthetic view of the functionality of the system A synthetic view of the functionality of the system

SR: Use Case Model - 2 Objectives of the use case model Objectives of the use case model Produce some diagrams that represent the actors and their relationships (actor diagrams) Produce some diagrams that represent the actors and their relationships (actor diagrams) Produce diagrams that represent the use cases with the actors and their relationships (use case diagrams) Produce diagrams that represent the use cases with the actors and their relationships (use case diagrams) Organize the use cases into packages that map to the conceptual categorization of the system functions Organize the use cases into packages that map to the conceptual categorization of the system functions

SR: Use Case Model - 3 Use the following to produce first draft of use cases Use the following to produce first draft of use cases User stories User stories Business use case model Business use case model Business object model Business object model Vision document Vision document Organize use cases into “business packages”, each of which contributes to the realization of a specific business function Organize use cases into “business packages”, each of which contributes to the realization of a specific business function

SR: Use Case Model - 4 Refine use cases Refine use cases Use a template for use case definition Use a template for use case definition Remove any ambiguity Remove any ambiguity Resolve conflicts Resolve conflicts Use the business rules to identify alternative paths in the use cases Use the business rules to identify alternative paths in the use cases Add concepts that are pertaining to the system, but the business to the business/system glossary Add concepts that are pertaining to the system, but the business to the business/system glossary

SR: Test cases As soon as the use cases are defined, test designer should start identifying As soon as the use cases are defined, test designer should start identifying Test scenarios Test scenarios Test cases Test cases Preparing of test cases can also help in validating use cases Preparing of test cases can also help in validating use cases

SR: Summary Artifacts of SR Artifacts of SR Vision document Vision document User stories User stories Use case definition Use case definition Use case model Use case model System glossary System glossary Use case packages Use case packages