NJIT Other Requirements Chapter 7 Applying UML and Patterns Craig Larman.

Slides:



Advertisements
Similar presentations
An Introduction to professional services. The professional services The professional services support businesses of all sizes across the economy, providing.
Advertisements

WAREHOUSING MANAGEMENT
Chapter 7 Other Requirements Good Fast Cheap Pick any two. 1CS John Cole.
Object-Oriented Analysis and Design
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.
8/28/2005ECEN5543 Req Elicitation1 Targets of Requirements Engineering ECEN 5543 SW Engineering of Standalone Programs University of Colorado, Boulder.
Copyright 2006 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
NJIT Evolutionary Requirements Chapter 5 Applying UML and Patterns Craig Larman.
Management Information Systems, 4 th Edition 1 Chapter 16 Alternative Avenues for Systems Acquisitions.
Chapter 13 - Inventory Management
Chapter 4: Beginning the Analysis: Investigating System Requirements
Chapter 4 After Green Light. After the Green Light Contractual Agreement Marketing Requirements Document (MRD) Project DefinitionBudget Project Approval.
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 6: INTERNAL CONTROL AND FINANCIAL REPORTING FOR CASH AND MERCHANDISE SALES LEARNING OBJECTIVE 1 Distinguish among service, merchandising, and manufacturing.
VIRTUAL BUSINESS RETAILING Lesson 2 Purchasing. MAIN IDEA  Purchasing inventory for a store is an important & complicated job  To be successful, a store.
What is A-Tracker A-Track is a Palm OS application that allows a company to track its equipment - office equipment, computers, vehicles, automobiles, library,
Chapter 4: Beginning the Analysis: Investigating System Requirements
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 4.1.
Requirements Management with Use Cases Module 6: Define the System Requirements Management with Use Cases Module 6: Define the System.
1 BTS330 Vision & Scope. 2 IT Projects What defines project success? On time Within budget Delivers what the clients want The reality Less than 20% of.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
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.
Develop A Foundational Knowledge Of Pricing To Understand Its Role In Marketing.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
1 BTS330 Vision and Scope. √ Determine a vision for the business √ Create initial use-case model showing key actors and use cases by business area Benefits.
Software Requirements Engineering CSE 305 Lecture-2.
ITEC 275 Computer Networks – Switching, Routing, and WANs Week 12 Chapter 14 Robert D’Andrea Some slides provide by Priscilla Oppenheimer and used with.
Introduction to the Requirements Document
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Chapter 3 Systems Planning and Selection 3.1.
OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN. COURSE OUTLINE The world of the Information Systems Analyst Approaches to System Development The Analyst as.
Chapter 7 Applying UML and Patterns -Craig Larman
Chapter 7 Applying UML and Patterns Craig Larman
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 3 Identification and Selection of Development Projects.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 The Analysis Phase System Requirements Models and Modelling of requirements Stakeholders as a source of requirements.
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.
GLOBAL MARKETING Distribution Management. Why A Distribution Strategy? To make the right quantities of the right product or service available at the right.
Inception Chapter 4 Applying UML and Patterns -Craig Larman.
INTRODUCTION TO MANAGEMENT INFORMATION SYSTEM. INTRODUCTION Now a day, there are many companies, which depend on their computers for their day-to-day.
CHAPTER 2 TYPES OF BUSINESS INFORMATION SYSTEM. INTRODUCTION Information System support business operations by processing data related to business operation.
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.
Department of Marketing & Decision Sciences Part 5 – Distribution Wholesaling and Physical Distribution.
BTS330: Business Requirements Analysis using OO Lecture 6: Systems.
Introduction to Project Management.  Explain what a project is?  Describe project management.  Understand project management framework.  Discuss the.
Requirements Management with Use Cases Module 3: Analyze the Problem Requirements Management with Use Cases Module 3: Analyze the Problem.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Essentials of Systems Analysis and Design Fourth Edition Joseph S. Valacich Joey F.
Outlines Overview Defining the Vision Through Business Requirements
ITEC 275 Computer Networks – Switching, Routing, and WANs Week 12 Chapter 14 Robert D’Andrea Some slides provide by Priscilla Oppenheimer and used with.
Slide 1 Software Construction Software Construction Lecture 3.
Group member: Mohd Yatim Bin Idris (805540) Monalisa Lee (803737)
1 Block 3 Session 2 Continue.. & Session 3 Distribution systems, EDI and the organization: –Major developments over the last 30 years have been achieved.
4 Chapter 4: Beginning the Analysis: Investigating System Requirements Systems Analysis and Design in a Changing World, 3 rd Edition.
Chapter 13 - Inventory Management
Evolutionary requirements
Chapter 13 - Inventory Management
Book: Integrated business processes with ERP systems
Managing Short-Term Assets
VENDORS, CONSULTANTS AND USERS
Book: Integrated business processes with ERP systems
The Basics of Information Systems
The Basics of Information Systems
Other System Requirements
Presentation transcript:

NJIT Other Requirements Chapter 7 Applying UML and Patterns Craig Larman

Trade Offs Fast, Cheap, Good -- choose any two. We are back to Time, Cost and Quality. Each will affect the others. When I had my own business, I used several different printers for different combinations of fast, cheap, and good.

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.

Not a checklist This section is not a listing of things that have to be documented in a system. It is a description of a wide variety of possible items and artifacts. Documentation costs money and takes time. Use only enough resources to produce the desired results efficiently and effectively.

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 Introduction Positioning Business Opportunity Problem Statement Product Position Alternatives Competition Stakeholders Market Demographics Non-user Interests User Interests Key goals and problems for stakeholders User Goals and environment

Vision—Product Overview Product Perspective Summary of Benefits Assumptions and Dependencies Cost and Pricing Licensing and Installation Summary of System Features Other requirements and constraints

Key Vision Questions Problem Statement Key High Level Goals Key Problems for the Stakeholders What are the root problems and goals?

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 Specification The Supplementary Specification captures such requirements as documentation, supportability, packaging, licensing and many of the “-ilities” of systems.

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

More Specifications Interfaces Hardware Software Domain 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.

NJIT Some Sample Domains Inventory, Accounting, Queuing and Scheduling

Inventory Doing Inventory right can give a company an overwhelming competitive advantage. Wal-Mart is really a computerized Retail Just-In-Time inventory system with stores attached. It is so good that it put K-Mart in bankruptcy and Sam Walton’s children make up half of the ten richest people in the world.

Wal-Mart’s Inventory Wal-Mart puts the responsibility for restocking their stores on their suppliers. Every time an item is sold, the cash register notes the transaction and the store computer accumulates them. The suppliers have direct access to this information, and send resupplies whenever necessary.

Economic Order Quantity K-Mart’s Inventory was based on EOQ, which balances off quantity discounts against the cost of placing an order. This is an adversarial system, because stores want small orders (to avoid overstock sales and costly warehousing) while manufacturers want big orders so they can run production lines efficiently.

Just-In-Time Inventory By contrast, Wal-Mart’s system has advantages for both the store and the manufacturer. With continuous resupply, the manufacturer doesn’t have to wait for an order. They might keep one production line running all year. In addition, both parties benefit from keeping an item in stock so that customers don’t buy it elsewhere.

Another JIT Example The automobile industry has long sought to have Just-In-Time Inventory. Factory complexes have been built in Spain and Brazil where parts manufacturers own plants next to the automobile assembly plants. In some cases, the part manufacturers even put their parts on the car on the assembly line.

Manufacturer’s Inventory The distinctive nature of a Manufacturer’s Inventory is the “Kit.” A Kit is a collection of parts that might include other Kits. For example, a right front door kit for an automobile might include a door shell kit, a window kit, an inside panel kit, a lock kit, a door handle, an armrest and other items.

Serial Number Inventory The distinctive feature of a serial number inventory is that each item is unique. You cannot apply the idea of Economic Order Quantity. Think of an Automobile Dealer. Even if two cars are the same make, model, and color, with the same accessories, they have unique Vehicle Identification Numbers, and must be tracked separately.

Accounting Sub-Domains Another knowledge domain that has specialized sub-domains is accounting. I used to own a company that sold accounting systems to Certified Public Accountants. I had two specialties; tax preparation software and client write-up software, and I represented several manufacturers of software. My main source was Accountant’s Microsystems Inc., and I could sell and install a turn key system with both specialties and the associated hardware.

Queues Queuing theory is used in a wide variety of industries, because no one can afford to maintain resources for peak demand in times of slack demand. Think of tellers in a bank, cash registers in a store, pumps at a gas station, or telephone switches in a central office. Queuing theory helps banks identify how many tellers they need, and tells local phone companies when they need to upgrade their central offices.

Scheduling Resource scheduling is closely related to queuing theory. Once you know what your demand for resources is, how do you fulfill those demands? One of the most demanding scheduling tasks is airline crew scheduling. You need the right number of people in the right place at the right time, and have to work around seniority, FAA rules, union contracts, vacations, and illness.

Possible Steps in Scheduling Task Identification Demand Forecasting Constraint Identification Resource Leveling Resource Availability Resource Allocation Location Shifting Last-minute changes Feedback

Requirements Reliability Never assume that requirements are completely understood, adequately captured, effectively described, or reasonably complete. Requirements discovery and scope creep tend to occur throughout the software development process and even after the system is put into production.

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.