Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.

Slides:



Advertisements
Similar presentations
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 3: Requirements Overview Module 3 - Requirements Overview.
Advertisements

CPSC 333: Foundations of Software EngineeringJ. Denzinger 2.2. Use Cases: Scenario based requirements modeling Recommended: Booch, Rumbaugh, Jacobson:
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Actors and use cases Use-case diagram Brief notation Prioritization Fully dressed notation Requirements Functional requirements  Use-cases.
Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 1 Capturing the Requirements as use Cases  Requirements Description  We need to describe –The.
Use-case Modeling.
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
SE 555 Software Requirements & Specification1 Use-Case Modeling: Overview and Context.
Analysis Concepts and Principles
Copyright ©2004 Cezary Z Janikow 1 Use Cases n Within Requirements discipline/workflow n Verbal descriptions of important functional (behavioral, transactional,
SE 555 Software Requirements & Specification Requirements Analysis.
1 Business Models Modeling. 2 Why Model the Business Business modeling is a technique to help answer critical questions, such as: What do the workers.
Object Oriented Analysis and Design Using the UML
Slide 1 Requirements Workflow. Slide 2 The Phases/Workflows of the Unified Process Figure 3.1 l Phase is Business context of a step Workflow is Technical.
USE Case Model.
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
RUP Requirements RUP Artifacts and Deliverables
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Rational Unified Process (Part 1) CS3300 Fall 2015.
Chapter 5 Analysis Model. Analysis model (AM) The first step in describing how the system will implement the requirements specification The first step.
ANALYSIS REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
1 Objectives  Describe design constraints.  Identify methods of specifying functional requirements.  Describe techniques for writing and structuring.
Chapter – 6. Requirements Capture - Difficult A System has many Users. Each of them know what to do but no one knows the entire picture. Users do not.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Business Analysis and Essential Competencies
Software Engineering Chapter 8 Fall Analysis Extension of use cases, use cases are converted into a more formal description of the system.Extension.
From Use Cases to Test Cases 1. A Tester’s Perspective  Without use cases testers will approach the system to be tested as a “black box”. “What, exactly,
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Software Engineering Chapter 7 Fall Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts.
Requirements Artifacts Precursor to A & D. Objectives: Requirements Overview  Understand the basic Requirements concepts and how they affect Analysis.
Approaching a Problem Where do we start? How do we proceed?
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
UML-1 3. Capturing Requirements and Use Case Model.
Object Oriented Analysis and Design using the UML CIS 520 Advanced Object-Oriented Design.
Actors and Use Case Diagrams Month Day, Year. Agenda Training Plan Overview Review Detailing Requirements with Requisite Pro Concepts Setting Up XDE Integration.
UML-1 8. Capturing Requirements and Use Case Model.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Engineering Lab Use Cases Faculty of Information system Technology.
ANALYSIS - II REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
1 Use Case Diagrams Use Case Actor Use case description Use case realization (Scenario) Use case relationships –Extends –Uses.
1 Structuring Systems Requirements Use Case Description and Diagrams.
Shanghai Jiao Tong University 上海交通大学软件工程中心 Object Oriented Analysis and Design Requirements Overview.
Use Cases, Part I Understanding the Business Dynamics  Understand the business workflow  Identify system support points the system 'use cases'
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
1 System Analysis and Design Using UML INSTRUCTOR: Jesmin Akhter Lecturer, IIT, JU.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Use Case Diagram The purpose is to communicate the system’s functionality and behaviour to the customer or end user. Mainly used for capturing user requirements.
Rational Unified Process Fundamentals Module 3: Disciplines I.
Gerhard Dueck -- CS3013Requirements Capture 1  From Vision to Requirements  Why it is difficult?  Developers are not users  Inadequate requirements.
Unified Modeling Language User Guide Section 4 - Basic Behavioral Modeling Chapter 16 - Use Cases Chapter 17 - Use Case Diagrams.
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
Lecture 14 22/10/15. The Object-Oriented Analysis and Design  Process of progressively developing representation of a system component (or object) through.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
UML - Development Process 1 Software Development Process Using UML.
Use Case Model Use case description.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Business Modeling and Analysis
Requirement Discipline Spring 2006/1385 Semester 1.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
1 7 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 7 The Object-Oriented Approach to Requirements.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Use Case Model Use case description.
Use Case Realization Describes a collaboration among analysis classes that shows how a specific use case is realized Consists of flow-of-events analysis,
Product Life cycle (RUP)
Software Development Process Using UML Recap
Presentation transcript:

Requirements Capture

Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture nonfunctional requirements

1. List Candidate Requirements Feature list: – Ideas that customers, users, analysts, and developers think are good for the systems Each feature has: – Status (proposed, approved, etc) – Estimated cost to implement (like man-hours) – Priority (critical, important, optional) – Level of risk in implementation (p112)

2. Understand system context Domain model – Important concepts of the context and relationships among them. (p119) – A glossary of terms for better communication – Domain objects later transformed to classes Business Model – Model the business processes of the organization – Specify which processes are to be supported by the system (p122 & 124)

3. Capture functional requirements Use case model – Each use case describes a way of using the system by a user (p127) – Use case model contains all the use cases of the system – Interview users and customers to collect them – This model leads to analysis and design

4. Capture nonfunctional requirements System properties: environmental and implementation constraints, platform dependencies, reliability, timing constraints. Most nonfunctional requirements are relevant only to a certain use case. Supplementary requirements: (p128) – Nonfunctional requirements that cannot be applied to particular use cases

Artifacts of requirements workflow -1 Use-case model: – a model containing actors and use cases and their relationships. – allow developers and customers to agree on the requirements the system must satisfy. Actor: – Users who use the system and – external systems that interact with the system

Artifacts of requirements workflow -2 Use cases – Flow of events – Special requirements Architecture description – Architectural view of the use case model, which contains important and critical functionality and requirements of the system. Glossary: – Important and common terms used by analysts in describing the system User-interface Prototype

Activities of requirements workflow 1. Find actors and use cases 2. Prioritize use cases 3. Detail use cases 4. Prototype user interface 5. Structure the use-case model

1. Find actors and use cases -1 Objectives: – Delimit the system from its environment – Outline who and what (actors) will interact with the system and what functionality is expected from the system – Capture and define in a glossary common terms that are essential for describing the system

1. Find actors and use cases -2 Four steps: – Finding the actors (p147) At least one user who can enact the candidate actor Min. overlap between the roles played by different actors – Finding the use cases (p146) A use-case should deliver an observable result that is of value to the particular actor – the initiating actor Avoid too small or too large use cases

1. Find actors and use cases -3 Four steps: – Briefly describing each use case (p150) A step-by-step description of what the system needs to do when interacting with the actor – Describing the use case model as a whole (p151) Use use-case packages to organize use-cases Use diagrams and description to explain the use-case model as a whole, an how they are related to each other Let the users/customers to approve the use-case model through an informal review

2. Prioritize use cases The purpose is to provide input to the prioritization of use cases to determine which need to be developed in early iterations. The results are captured in an architectural views of the use case model. The architectural view of use case model contains the architecturally significant use case models

3. Detail use cases -1 Describe the flow of events for each use case Structuring the use-case description – Choose a complete basic path from the start state to the end state and describe it in one section – Basic path: “normal” path (p155) – Describe the rest of paths as alternatives of deviation from the basic path – Alternative paths are described in a separate section (p156)

3. Detail use cases -2 What to include in use-case descriptions – Define the start state and end states as precondition and post- conditions, respectively – How and when the use case starts and ends – The required order of actions – Paths of execution that are not allowed – Alternative path description – System interactions with the actor, explicitly specify what the system does and what the actor does – Usage of objects, values, and resources of the system

3. Detail use cases -3 Formalizing the use-case description – For simple use cases with fewer states, textual description may be used – For complex use cases Use statecharts to describe the states and transitions between those states (p160) Use Activity diagrams to describe transitions between states as sequence of actions Use Interaction diagrams to describe how a use case interacts with an actor

4. Prototype user interface -1 Creating a logical user interface design – Determine what elements are needed from the user interfaces to enable the use cases for each each actor – How should they be related to each other – What should they look like – How should they be manipulated – Sticky notes (for elements) on a whiteboard – User-interface elements for Pay-Invoice use case (p163)

4. Prototype user interface -2 Creating a physical user-interface design and prototype – Sketch the constellation of user interface elements – Additional elements may be added to organize the elements (like windows, folders, etc) – Each actor should be provided with a well-integrated, easy-to- use, and consistent interface – Prototypes may be built for user validation – Physical user interface for the Account and Invoice elements for the Pay-Invoice use case(p165)

5. Structure the use-case model Identify shared descriptions of functionality – The actions that are common to or shared by several use cases (ex. generalization between pay-invoice and perform- transaction) (p167) Identify additional and optional description of functionality – Extend relationship: additions to a use case’s sequence of actions (Pay-overdraft-fee to Pay-invoice) (p169) Identify other relationships between use cases – Like include relationship