Chapter 7 Applying UML and Patterns -Craig Larman

Slides:



Advertisements
Similar presentations
Chapter 15: Packaged Software and Enterprise Resource Planning
Advertisements

Chapter 05: Evolutionary Requirements Definition : Requirements  “Requirements are capabilities and conditions to which the system, and more broadly.
Chapter 7 Other Requirements Good Fast Cheap Pick any two. 1CS John Cole.
Object-Oriented Analysis and Design
Systems Analysis and Design 9th Edition
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
Requirements Specification
1 SYS366 Week 1 - Lecture 2 How Businesses Work. 2 Today How Businesses Work What is a System Types of Systems The Role of the Systems Analyst The Programmer/Analyst.
NJIT Other Requirements Chapter 7 Applying UML and Patterns Craig Larman.
8/28/2005ECEN5543 Req Elicitation1 Targets of Requirements Engineering ECEN 5543 SW Engineering of Standalone Programs University of Colorado, Boulder.
Eleventh Edition 1 Introduction to Information Systems Essentials for the Internetworked E-Business Enterprise Irwin/McGraw-Hill Copyright © 2002, The.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
NJIT Evolutionary Requirements Chapter 5 Applying UML and Patterns Craig Larman.
Chapter 4: Beginning the Analysis: Investigating System Requirements
NJIT Inception is not the Requirements Phase Chapter 4 Applying UML and Patterns Craig Larman.
Introduction to Systems Analysis and Design
VENDORS, CONSULTANTS AND USERS
The Vision Document 1. Importance of a Vision Document  It describes the application in general terms, including descriptions of the target market, the.
Chapter 4: Beginning the Analysis: Investigating System Requirements
Copyright © Craig Larman All Rights Reserved Requirements.
Rational Unified Process (Part 1) CS3300 Fall 2015.
1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 4: Analyze the Problem.
1 Phases in Software Development Lecture Software Development Lifecycle Let us review the main steps –Problem Definition –Feasibility Study –Analysis.
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.
CIS 321—IS Analysis & Design Chapter 4: Analysis— Investigating System Requirements.
Business Analysis and Essential Competencies
ITEC 275 Computer Networks – Switching, Routing, and WANs Week 12 Chapter 14 Robert D’Andrea Some slides provide by Priscilla Oppenheimer and used with.
231 Business Modeling - Domain Analysis Most materials taken from the RUP textbook Chapter 8 and OOSE, pp
Introduction to the Requirements Document
OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN. COURSE OUTLINE The world of the Information Systems Analyst Approaches to System Development The Analyst as.
Approaching a Problem Where do we start? How do we proceed?
Chapter 7 Applying UML and Patterns Craig Larman
Lecture 7: Requirements Engineering
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 The Analysis Phase System Requirements Models and Modelling of requirements Stakeholders as a source of requirements.
Accounting Information System By Rizwan Waheed M.Com 710.
VENDORS, CONSULTANTS AND USERS. WHY CAN’T COMPANIES DEVELOP THEIR OWN ERP PACKAGES? To develop an ERP package is a complex & time consuming activity which.
Inception Chapter 4 Applying UML and Patterns -Craig Larman.
CS 772: Global Knowledge Networks V. “Juggy” Jagannathan CSEE, West Virginia University.
Developing Business/IT Solutions Chapter 12 McGraw-Hill/IrwinCopyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Software Engineering 1 Object-oriented Analysis and Design Chap 24 Iteration 2 More Patterns.
Understanding Requirements Chapter 5 Applying UML and Patterns -Craig Larman.
BTS330: Business Requirements Analysis using OO Lecture 6: Systems.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Introduction to Project Management.  Explain what a project is?  Describe project management.  Understand project management framework.  Discuss the.
Foundations of Information Systems in Business. System ® System  A system is an interrelated set of business procedures used within one business unit.
Inception is not Requirement phasee Chapter 3 and 4 Applying UML and Patterns -Craig Larman.
IS2210: Systems Analysis and Systems Design and Change Twitter:
Requirements Analysis
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 Click to edit Master title style What is Business Analysis Body of Knowledge?
ITEC 275 Computer Networks – Switching, Routing, and WANs Week 12 Chapter 14 Robert D’Andrea Some slides provide by Priscilla Oppenheimer and used with.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
4 Chapter 4: Beginning the Analysis: Investigating System Requirements Systems Analysis and Design in a Changing World, 3 rd Edition.
ITEC 275 Computer Networks – Switching, Routing, and WANs
Chapter 2 The Origins of Software
Evolutionary requirements
Fundamentals of Information Systems, Sixth Edition
Inception.
VENDORS, CONSULTANTS AND USERS
Chapter 1 (pages 4-9); Overview of SDLC
Chapter 2 The Origins of Software
Chapter 2 The Origins of Software
Evolutionary Requirements
Other Requirement Artifacts
Business Modeling - Domain Analysis
Chapter 5 Evolutionary requirements
Chapter 2 The Origins of Software
Other System Requirements
Presentation transcript:

Chapter 7 Applying UML and Patterns -Craig Larman Other Requirements Chapter 7 Applying UML and Patterns -Craig Larman

Introduction While the primary requirements of a computer system tend to be the functional requirements—the list of activities that the system must perform, it is also necessary to capture an number of other requirements to build a system. These are called non-functional requirements, and may be captured in a Vision Statement, Glossary and Supplementary Specification.

Supplementary Specification Documentation costs money and takes time. Use only enough resources to produce the desired results efficiently and effectively. Documentation Packaging Licensing Supportability

The Vision The Vision serves to communicate to project sponsors and key stakeholders the reasons for the project, the problems to be solved, a description of the stakeholders and their needs, along with a description of the proposed solution. It includes the core requirements and becomes the contractual basis to develop further requirements.

Topics for a Vision Stakeholders Introduction Positioning Market Demographics Non-user Interests User Interests Key goals and problems for stakeholders User Goals and environment Introduction Positioning Business Opportunity Problem Statement Product Position Alternatives Competition

Why system features in Vision? Use cases are not the only way to describe functional requirements. Sometimes a succinct list of key functional requirements will give a better immediate grasp of the problem and proposed solution.

Glossary The Glossary captures terms and their definitions in the business domain supported by the system. Be careful. Even simple terms may mean different things to different stakeholders and need to be defined. The Glossary can also perform the role of a Data Dictionary, or be supplemented by one.

Supplementary Specifications Common Functionality Logging Error Handling Business Rules Security Usability Reliability Recoverability Performance Supportability Adaptability Configurability Implementation Constraints Purchased Components

More Specifications Interfaces Domain Rules (business rules) Hardware Software Domain Rules (business rules) Legal Issues Reports Operating Systems Networking Systems Process Tools Development Tools Design Constraints Internationalization Standards Physical Environment Operation Rules

Domain Rules Domain or Business Rules are not functional requirements. Domain Rules tell how the business works, while functional requirements tell how the system works. Company policies, the laws of physics, and government regulations are examples of Domain Rules. Do not include system features.

Industry Domains Most computer consulting firms organize their staff by industry, so that they can develop application specific knowledge that will be useful to the companies hiring them. In New Jersey, most consulting companies have at least a Telecommunications Practice and a Pharmaceutical Practice. Other areas might include Retail, Insurance, Wholesaling, Light Manufacturing, and Electric Utilities.

Knowledge Domains In addition to Industry specific knowledge, there are many areas of knowledge that apply across a number of industries. The most thoroughly specified of these knowledge domains is accounting. Others might include inventory, scheduling, and queuing. Each has a body of specific knowledge that specialists know well.

Sub-Domains Within each knowledge domain, there are often specialized sub-domains. For example, Retail Inventory, Just-In-Time Inventory, Service Inventory, Manufacturers Inventory, and Serial Number Inventory are distinct approaches, each of which is used across a variety of industries.

UML Diagrams in Inception Aside from the possible inclusion of a few high level use case diagrams, the inception phase is almost all text. Most diagramming occurs in the Elaboration Phase.