Copyright 2013-2014 Robert W. Hasker. Requirements-based Development  System specification: series of “shalls”  The registration system shall support.

Slides:



Advertisements
Similar presentations
Copyright Robert W. Hasker. Imperative Requirements- based Development  System specification: series of “shalls”  The registration system.
Advertisements

COPYRIGHT © 2012 ALCATEL-LUCENT. ALL RIGHTS RESERVED. 1 Agile documentation development methodology Giby Panicker and Judith Benjamin 1-Dec-2012.
Ni.com Introduction to Agile and Scrum Speaker/Author: Paul Packebush Section Manager, Corporate Metrology Author:Logan Kunitz Staff Calibration Engineer.
Agile Planning. The problem with documentation Argument: “Heavy” documentation too much for most business-style projects.
Copyright © 2012 by Mark J. Sebern Product Backlog PBI types (extended list) Feature Change Defect Technical improvement Knowledge acquisition Briefly,
Agile Project Management with Scrum
Copyright © by Mark J. Sebern Software Engineering Process I SE Product backlog, estimation, velocity.
Iterate (Requirements, Design) IMD07101: Introduction to Human Computer Interaction Brian Davison and Tom McEwan 2011/12.
AN OVERVIEW BY JAMIE STARKE The Role of Prototyping.
Requirements Analysis CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 7, 2003.
Lecture 2 Teams Principles What makes a good project Project Definition Project Plan.
The Architecture Design Process
Ch 5 Specification page 1CS 368 Context Specification one of the most commonly cited reasons for an IT project failure is unclear objectives and requirements.
Software Development Models: Waterfall and Spiral Sung Hee Park Department of Mathematics and Computer Science Virginia State University August 21, 2012.
 MODERN DATABASE MANAGEMENT SYSTEMS OVERVIEW BY ENGINEER BILAL AHMAD
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
© 2010 AT&T Intellectual Property. All rights reserved. AT&T and the AT&T logo are trademarks of AT&T Intellectual Property. Deeper Dive Into: User Stories.
Software Development Landscape
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Incorporating Pragmatic Usability Testing Into a Software Test Plan Carla Merrill, Ph.D. Focused Design focuseddesign.com
Copyright Robert W. Hasker. Story Review  Elements of a Scrum story:  The three C’s:  Sprintable stories:  Mechanisms for obtaining stories:
Project Workflow. How do you do it? -Discussion-
Frameworks in project management
Mobile Aps: Agile Mentoring Review
Approaching a Problem Where do we start? How do we proceed?
© Bennett, McRobb and Farmer Avoiding the Problems Based on Chapter 3 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
Copyright © 2012 by Mark J. Sebern Scrum Overview (from
Agile: Lessons Learned (a retrospective) Tony
CS CS 5150 Software Engineering Lecture 2 Software Processes 1.
CS3100 Software Project Management Agile Approaches.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Theories of Agile, Fails of Security Daniel Liber CyberArk.
Software Engineering Jon Walker. What is Software Engineering? Why do we call it Software Engineering? Why not just call it programming or software development?
Copyright © by Mark J. Sebern Software Engineering Process I SE 2800.
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
CSPC 464 Fall 2014 Son Nguyen. 1. The Process of Software Architecting, Peter Eeles, Peter Cripss 2. Software Architecture for Developers, Simon Brown.
1 What is the Software Life Cycle? The stages of developing a software application Requirements Analysis High-level Design Plan Low-level Design Implementation.
Cultivating Agile Requirements
Dr. Rob Hasker. What if every project used Scrum?  Why might Scrum not be perfect for every project? Hard to get the big picture Early choices may have.
Lecture 4: Requirements Engineering COSI 120b, Principles of Software Engineering.
Agenda: Overview of Agile testing Difference between Agile and traditional Methodology Agile Development Methodologies Extreme Programming Test Driven.
Dr. Rob Hasker Dr. Brad Dennis. Scrum review experience  Lessons learned Saturday Differences from process taught? Similarities? Other lessons?
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Dr. Rob Hasker. Should every project use Scrum?  When might Scrum not be an appropriate model?  What are some of its limitations? Hard to get the big.
1 Requirements Engineering for Agile Methods Lecture # 41.
Copyright 2015, Robert W. Hasker. Classic Model Gathering Requirements Specification Scenarios Sequences Design Architecture Class, state models Implementation.
User Stories- 2 Advanced Software Engineering Dr Nuha El-Khalili.
Introduction to Agile. Introduction Who is this guy?
CS 4500: Software Development Software Process. Materials Sommmerville Chapters 1, 2 and 3 Software Cycle and Models:
 SBOK™ (SCRUM Body of Knowledge)  Student course workbook  Case study booklet  Scrum in a page  Scrum Product Owner Certified physical certificate.
Informed Traveler Program and Applications Agile / Scrum Overview Jerry Inberg.
Project Workflow.
Embedded Systems Software Engineering
Dr. Rob Hasker SE 3800 Note 3 Ch. 4, 5.
The Systems Engineering Context
Information Technology Project Management – Fifth Edition
Requirements and User Stories
HCI in the software process
User Stories Applied, Mike Cohn Chapter 1: An Overview
Johanna Rothman Know What “Done” Means Chapter 11
The Role of Prototyping
Introduction to Agile Blue Ocean Workshops.
HCI in the software process
Adjective: Able to move quickly and easily. Principles and Values
Scrum Science NGSS: Engineering, Technology, Applications of Science
HCI in the software process
Human Computer Interaction Lecture 14 HCI in Software Process
Adapting Agile in Pharmaceutical Industries
Presentation transcript:

Copyright Robert W. Hasker

Requirements-based Development  System specification: series of “shalls”  The registration system shall support lecture, discussion, and lab-based courses.  The snowba shall clear sidewalks of up to 4 inches of snow.  The snowba shall commence clearing snow when the depth is greater than ½ inch.  Forms a contract  Changes can be very expensive, so focus is on obtaining correct set of requirements early.

Correctness  Why “shall”?  Ensures requirements distinct from discussion.  Example: 4 inches is the maximum height allowed since greater heights would require wheels that are too large for a self-contained unit.  What if we find errors later?  Either an error in the contract or implementation.  In practice, a large percentage of project failures trace to errors in requirements.  Problem: natural languages are not always precise – is this model even feasible?

Alternative to requirements  PBIs could be requirements  Could write lists of high-level and low-level requirements, organized by feature.  Traditional requirements require lots of grooming.  Alternative: Use cases  Collection of detailed scenarios – advantages?  Usual agile approach: user stories:  As a user_role, I want to goal so that benefit.  Light-weight requirement: focused on asking client for details rather than writing a contract.  Agile manifesto: collaboration over contracts Agile manifesto

Elements of stories  As a user_role, I want to goal so that benefit.  As a homeowner, I want the snowba to commence clearing snow when the accumulation reaches ½” so that I do not have to pay the city to clear my sidewalk.  user_role: how user interacting with system  Same user might have multiple roles!  goal: what user wants to achieve  benefit: why – critical to understanding story  How long should these stories be?  What are the conditions of satisfaction?

A matter of scale  Stories can be very detailed:  As a student, I want to see the total number of credits for the courses which I have added to my schedule so I can limit my workload.  Stories can be very broad – epics.  As a student, I want to take courses that allow me to complete major requirements so I can graduate in four years.  Why can’t we just write epics?  Why not have lots of detailed stories?  How do epics and stories interact w/ the PB?

Size hierarchy Time Unit Scale of Enclosing Entity EpicMonthsProduct Feature/ Theme WeeksRelease StoryDaysSprint TaskHours

Conditions of Satisfaction Condition 1 Condition 1 Condition 2 Condition 2 Condition 3 Condition 3 The “three C’s” Card, Conversation, Confirmation Story Title As a, I want to so that.

Good stories p. 88 IIndependent NNegotiable VValuable EEstimatable SSmall (appropriate size) TTestable What do these qualities mean? Why do we want them?

How would we “test” stories?  Best practices: integrate testing throughout product cycle  So how to test a story?  One solution: “Wizard of Oz” testing

Nonfunctional requirements  Definitions:  A property of the system, not a specific operation A property of the system, not a specific operation  Cross/cutting concerns/needs which apply to many user stories.  Not bad  Examples?  Safety, security, performance, robustness  Learnability, natural language support  Traditional concern: hard to test  How to handle in Scrum?  Include in definition of done?

Knowledge-acquisition stories  Prototype/spike/experiment/proof of concept  Example: evaluate alternative designs  Key: repeatable results  Why shouldn’t these be allowed?  Why should they be allowed?  How does the cost to unwind factor in?

Knowledge-acquisition stories  Prototype/spike/experiment/proof of concept  Example: evaluate alternative designs  Key: repeatable results  Why shouldn’t these be allowed?  Be suspicious of anything not delivering value  Why should they be allowed?  Important principle: fail fast  How does the cost to unwind factor in?

Gathering stories  Who should do it?  Should product owner be the sole team rep?  Basic method: ask user  Why might this not be effective?  User-story-writing workshop  What? Who? Why? How long? Goal?  Steps:  User role analysis: give names, personas to roles  Brainstorm: bottom-up, top-down, story map  Story Mapping: epics, themes, stories – p. 97  Often more focused on prioritization.

Stories vs. Requirements  Are stories just another form of requirements?  Can document reqs in criteria  Why wouldn’t reqs work as sprint tasks?  Why might we still need a traditional requirements document?  Safety critical systems: must trace requirements through project.  Would stories be the most effective way to organize such requirements?

Review  Traditional requirements: shalls  Collaboration over contract negotiation  Stories  Basic form As a user_role, I want to goal so that benefit.  Non-functional requirements, knowledge acquisition  Gathering stories  User-story-writing workshop  Story mapping

Exercise: WheresMyClass app  Epic: As a student, I want my phone to direct me to my next class so I avoid penalties for arriving late.  Assumption: building floor plans uploaded to Google to allow showing location within building.  Assumption: have API for finding current location and planning routes from current location to a target location.  In-class exercise: write stories for this app.

Jira Demo  Create story  Assign story points  Create subtasks  Move to current sprint  Change status of story in sprint