18 January Writing a Functional Spec. Administrivia How many teams will want departmental web space vs links to your own space? Please send me your CS.

Slides:



Advertisements
Similar presentations
Lecture 5: Requirements Engineering
Advertisements

Ch 3: Unified Process CSCI 4320: Software Engineering.
May 2, May 2, 2015May 2, 2015May 2, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa, CA.
Introduction to Software Engineering Dr. Basem Alkazemi
Requirements Analysis CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 7, 2003.
8 September Announcements  GIT Class: Friday 3-5 SN 115 (Peter Parente)  Information for Project Links PageProject Links Page  Hot Topics Teams.
22 September Fundamental Steps STEPS  Requirements  Design  Implementation  Integration  Test  Deployment  Maintenance MODELS Waterfall.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Design and Evaluation of Iterative Systems n For most interactive systems, the ‘design it right first’ approach is not useful. n The 3 basic steps in the.
Introduction to Software Engineering Dr. Basem Alkazemi
Designing a System 4 October Beyond the Technology What will be implemented – external view –“glossy” brochure –Use cases and user types Translation.
Overview of Software Requirements
Administrivia Turn in ranking sheets, we’ll have group assignments to you as soon as possible Homeworks Programming Assignment 1 due next Tuesday Group.
Software engineering Olli Alm Lecture 2: requirements, modelling & representation.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
CSC230 Software Design (Engineering)
Chapter 4 Capturing the Requirements 4th Edition Shari L. Pfleeger
1 CMPT 275 Software Engineering Requirements Analysis Phase Overview of Requirements Analysis Activity System Context Diagrams.
CS 235: User Interface Design August 27 Class Meeting Department of Computer Science San Jose State University Spring 2015 Instructor: Ron Mak
CS 235: User Interface Design August 27 Class Meeting Department of Computer Science San Jose State University Fall 2014 Instructor: Ron Mak
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 7 Requirements Engineering Software Engineering: A Practitioner’s Approach, 6/e Chapter.
The Software Development Life Cycle: An Overview
Chapter 4 Requirements Engineering
Diane Pozefsky. Engineering  Turning ideas into reality  Creating something useful from other things using science and math.
Requirements Gathering. Why are requirements important? To understand what we are going to be doing We build systems for others, not for ourselves Requirements.
COMP 523 DIANE POZEFSKY 20 August AGENDA Introductions Logistics Software Engineering Overview Selecting a project Working with a client.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
3 September Engineering  Turning ideas into reality  Creating something useful from other things using science and math.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
21 August Agenda  Introductions  Logistics  Selecting a project  Working with a client.
CMPT 275 Software Engineering
1 Chapter 5 Software Engineering Practice. 2 What is “Practice”? Practice is a broad array of concepts, principles, methods, and tools that you must consider.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Coming up: Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
IT Technical Support 1. Introduction Technical support personnel offer support for individual and organizations in a variety of ways. This module focuses.
Why Written Requirements?  Unambiguous  Defines goals  Cost of finding a requirements bug later can be 100 times more expensive.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University.
3 September Sources of requirements  People Stakeholders ○ Who are the stakeholders? Issues: ○ Conflicting requirements ○ Wants vs. needs Helping.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 7: Requirements Engineering Software Engineering: A Practitioner’s Approach, 6/e.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Requirements Engineering Lesson 2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software.
Systems Development Life Cycle
By Germaine Cheung Hong Kong Computer Institute
Requirements specification Why is this the first major stage of software development? –Need to understand what customer wants first Goal of requirements.
CSE 303 – Software Design and Architecture
Lecture 4: Requirements Engineering COSI 120b, Principles of Software Engineering.
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
Chapter 4 – Requirements Engineering Lecture 1 The hardest part of the software task is arriving at a complete and consistent specification, and much of.
WORKING WITH A CLIENT 22 August THE GOALS Common understanding Concept Capabilities Users Communications Expectations.
Lecture 4/2/16. Learning Objective Establishing requirements Define requirements Requirements discovery vs requirements gathering Classifying Requirements.
17 January Requirements. The Plan Quick Pass on Software Engineering “Just enough” context Start with what you need for your first deliverables Back up.
Developing Requirements. 1. Domain Analysis Domain: The general field of business or technology in which the customers expect to be using software Domain.
Software Engineering Lecture 10: System Engineering.
 System Requirement Specification and System Planning.
Requirements sprint.
Classifications of Software Requirements
CMPE 280 Web UI Design and Development August 29 Class Meeting
Chapter 4 – Requirements Engineering
Chapter 5 – Requirements Engineering
REQUIREMENTS Project management tools
Requirements Analysis Scenes
Client communication.
Requirements Analysis
Chapter 5 Understanding Requirements.
Use Case Modeling Part of the unified modeling language (U M L)
Requirement Engineer Terms and Conditions
REQUIREMENTS Project management tools
Presentation transcript:

18 January Writing a Functional Spec

Administrivia How many teams will want departmental web space vs links to your own space? Please send me your CS ids Names for your projects

The Plan Quick Pass on the Software Engineering Process (next week) Context on what you are doing Focus on specifics that you need for your deliverables Back up to higher level discussions and more enterprise-oriented options Today: toward the functional spec

Software Engineering Fundamental Steps Requirements Design Implementation Integration Test

Requirements Analysis To build something, we first must understand what it is we’re building Establish expectations Understandable by both the client and the developer

Why Written Requirements? Unambiguous Defines goals Cost of finding a requirements bug later can be 100 times more expensive ‘99 weather satellite where used wrong units (metric vs. feet)

Our Requirements Phase What does the client want to do? User stories – his (or her) terms Use cases – your terms Extract the essence: requirements Translate to a system: functional spec

Talking to the client Active listening Restate what you hear How to extract information Ask them to “tell stories” Focus on the interface: that’s what the user sees Start the design process with the customer Draw pictures!

User Requirements Identify the user groups Understand their goals Determine the total user experience How users perform their tasks now  Task and goal descriptions, importance ranking, strategies, measures, and targets  Stories and scenarios describing how they currently perform their tasks

User Requirements - Persona A description of a fictitious user representing a distinct user group User groups are based on unique goals Each persona represents a unique set of goals for design Personas help direct the design Allow designers to focus on people’s needs and differences Skills, motivations, emotions, behaviors Use each persona as though it were a real person “What would Jackie do if …”

Persona excerpt from hotel reservation system

Story excerpt

User Interfaces as a Requirements-Gathering Tools User Knowledge and experience Age and gender Physical handicaps Characteristics of tasks and jobs Psychological characteristics Function Menu design: what’s the natural order? Types of controls: what’s the natural mechanism?

Use Cases A statement of the functionality users expect and need, organized by functional units  Functional units are any natural division  Relationships between user roles and use cases  User activities, decisions, and objects involved

Documenting Use Cases UML diagrams are often used Requires tools Will discuss later, not use for now We will use simple text description Examples from last year Butterfly Lab Foreign Language Resource Center

A requirement must be … documented expressed precisely expressed as what, not how prioritized essential, desirable, optional primary, secondary, tertiary testable

The set of requirements must be… Consistent Three requirements: Only basic food staples will be carried Everyone will carry water Basic food staples are flour, butter, salt, and milk Complete The function tells whether 3 numbers produce an equilateral, isosceles, or scalene triangle.

Types of Requirements Functional: services that the application must provide Performance: speed, capacity, memory Reliability and availability: failure rates Error handling: how to handle Interface: user and program Constraints: systems or tolerances (Inverse requirements: what it won’t do)

Requirement Level Often addressed in two phases Customer level Developer level (will visit later) Once agreement exists with customer, developer “translates” them into his language Example User must never lose more than 10 minutes of work Autosaving is required

Sources of requirements People Broad range of stakeholders Conflicting requirements Wants and needs Helping the customer articulate the requirements: use cases Hardware constraints Laws of physics and nature Social responsibility

Sources of Requirements: People vs. Other (Brackett, CMU) Relatively highRelatively low % of requirements gathered from people Type of application highly constrained unconstrained missile guidance system flight control system for airliner enhancement to corporate accounting system manufacturing control system corporate accounting system video game decision support system for military tactics

What is a Functional Spec? Describes the features of the software product Describes the product's behavior as seen by an external observer Contains the technical information and data needed for the design Defines what the functionality will be, but not how it will be implemented Brooks’s architecture

What is an Architecture? Complete and detailed specification of the user interface (Brooks, The Mythical Man-Month) Architecture: what happens; implementation: how it is made to happen (Blauuw)

Architecture Example Non-digital clock Architecture = {face, hands, running mechanism} Implementations = watch, grandfather clock, wall clock, …