PowerPoint Presentation for IS-207 Copyright 2006 © Michael W. Schaffer. All rights reserved. Slide 1 Systems Analysis & Design Class #4 - Requirements 6/25/2015 4:13:36 AM

Slide 2 PDP: Requirements “What does it do?” and “For whom does it do it?” Who: Product Manager, Tech Lead, QA Lead, Project Manager, plus Define what the system does, and for whom. Develop cost assessment and baseline schedule, bottom-up Address risks early: prototype to test feasibility and platform/tools as needed.

Slide 3 Who drives Requirements? Product Manager is responsible for “What” is to-be-built Functional and non-functional req.’s Maintain a clear understanding of external forces and customer needs – fact-based. Business Analysts Technology staff involved early to provide feasibility and balance

Slide 4 Requirements – aka “Needs”? A Team Dialog … A taxonomy of requirements Users & Use Cases, UI/UE Data flow analysis Process analysis & documentation Revised Schedule and Plan

Slide 5 Requirements “Taxonomy” Product Functionality Non-Functional Platform & Compatibility (O/S, DBMS) Bandwidth & connectivity, Performance Marketing and Sales  Channels, Pricing and Licensing Packaging: SDK, integration hooks Product Support & Training, Roll-out

Slide 6 IBM Sales Model – c Deep and broad research (interviews and analysis) Document Information Needs, and develop benefit models Build a “Conceptual Model” – specific data-flows to consumers of information. Pitch the solution.

Slide 7 Textbook challenge #1 The text differentiates between Business Process Automation, BP Improvement, and BP Re- engineering. Improvement any incremental systems project Invention a “1.0” project

Slide 8 Know the history, then break it All projects benefit from knowing the background, whether incremental or true “1.0”. Get the background. All projects benefit from trying to expand the solution space early. More users, more information flows

Slide 9 Who is the end-user? Develop a clear vision of who uses the system: Information Needs Existing solutions (all types) and their issues with the status quo Goals & Fears … their unique perspective on the system

Slide 10 Political Support The process of requirements gathering (through end-user interviews, observation, etc.) creates opportunity to build critical support for your project.

Slide 11 Other players (stakeholders)… Buyer is rarely the end-user Influencers : IT, other departments In Venture-backed start-ups, the investors are critical. Your Boss

Slide 12 Joint Application Development JAD sessions – large, cross- functional meeting to discuss the proposed system Expensive -- lots of people Subject to domination Use with care, with great facilitators only.

Slide 13 Persona A useful technique for documenting in-depth “studies” of end-users “The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy …” (Alan Cooper)

Slide 14 Persona – II Especially useful when system to be developed is “1.0”: no old models, no existing basis End-users are novices, or new to the proposed system Requirements are difficult to define Multiple groups of end-users

Slide 15 Persona – III Your end-users will determine the style, look & feel, flavor of your system and its interfaces User Experience = Interactive Brand Iconography, Typography, Palette Visual Design has impact  Develop interactive requirements

Slide 16 The System is the Data At the core: any system is defined by the data obtained, stored, and displayed Data flow analysis is the center/core/key

Slide 17 DFD – Practical Example Launched Dec. 11, 1998, the Climate Orbiter plunged too steeply into the Martian atmosphere Sept. 23, 1999, and either burned up or crashed. In an initial failure report released Oct. 15, 2000, the review board blamed the navigation error on a communications foul-up between NASA's Jet Propulsion Laboratory and prime contractor Lockheed Martin.

Slide 18 Context Diagram Shows the context into which the system fits Shows the overall business process as just one process Shows all the outside entities that receive information from or contribute information to the system

Slide 19 Context Diagram of Alibris

Slide 20 Context of Quicken – 1995 (?)

Slide 21 Quicken

Slide 22 Data Flow Diagrams Keep them simple: Gane-Sarson Only three elements: Interface / Externals Process Data Store And data flows to inter-connect

Slide 23 DFD Shapes from Visio Visio 5.x Visio 2000

Slide 24 External Interfaces The Text says “External Entities”: Visio calls them Interfaces. An API or an external source, or an external consumer of data. Partner organizations … get their specs, and someone competent. A lot harder than it should be …

Slide 25 Data Stores Sure, could be a database... but do not get caught up in specifics too early. (Flat) Text files, XML files, cookies … firmware … any sort of repository. Physical model comes later!

Slide 26 An informal DFD

Slide 27 DFD – A more formal example Alibris, a typical eCommerce company DFD starts basic and clean Explode to more detail as needed.

Slide 28 Data Flow: Keys and Payload Data flows start general, i.e. “orders” or “inventory”. As you drive deeper, identify the “primary keys” in each element of the data flow: i.e.: Order number, SKU number Think about uniqueness … is the process feasible with the data present?

Slide 29 Data Flow: Keys and Payload Do not get caught-up in specifying every single data element of the payload. Use next phase for details Map the flow of “keys”, esp. across system seams to validate the design.

Slide 30 Data Flow: “Keys” example Partner sends an order for a set of books Purchase Order Number, SKUs Acknowledge Purchase Order Order number, mapped to PO Line-item ID’s needed? Ship product Ship status by PO? Line-item?

Slide 31 Elements of a Use Case Trigger -- event that causes the scenario to begin External trigger Temporal trigger All possible inputs and outputs Individual steps Show sequential order Show conditional steps

Slide 32 Scenario Template (Use Case) This template can be downloaded from the course download page.course download page

Slide 33 Integrating Scenario Descriptions DFDs generally integrate scenario descriptions Names of use cases become processes Names of inputs and outputs become data flows Combining “small” data inputs and outputs into a single flow

Slide 34 Steps in Building DFDs Build the context diagram Create DFD fragments for each scenario Organize DFD fragments into level 0 Decompose level 0 DFDs as needed Validate DFDs with user

Slide 35 DFD – Common Errors Miracle Black Hole Gray Hole

Slide 36 DFD – Packet Concept

Slide 37 Illegal Data Flows

Slide 38 Use cases do not collect formulae, state, cardinality, performance, uptime,... Examples: 1. Order cost = order item costs * 1.06 tax 2. Promotions may not run longer than 6 months. 3. Customers only become Preferred after A customer has one and only one sales contact. 5. Response time is Uptime requirement is Number of simultaneous users will be... Capture those in any form available

Slide 39 Other semantics A system is a collection of processes (Verbs) operating on data entities (Nouns). As you collect requirements, think about the nouns you encounter as entities. When you encapsulate behavior and data, this becomes an object.

Slide 40 Non-Functional Requirements Gathered from users, and environment. Hardware, Operating system, Network issues Marketing requirements from sales channel (how to sell it?) Operating requirements … Performance requirements …

Slide 41 What happened to Prototypes? Do your users understand the system? Build a UI shell that shows the information interfaces and reports Iterate with the users until clarity is achieved. Document the results.

Slide 42 Now revise the Plan All this design enables the team to revisit the implementation plan How might this be built? Components available to buy? Resources needed? Feasible? Create a detailed project plan.