1 / 30

Executable Requirements Let You Play More Foosball!

DPR301. Executable Requirements Let You Play More Foosball!. Eric Landes Agile Coach Press Ganey. Agenda. What bad looks like How it happens Better ways Example. Bad Requirements Examples. Lengthy Unfocused Ambiguous Verified Manually. Bad requirement might look like:.

shae
Download Presentation

Executable Requirements Let You Play More Foosball!

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DPR301 Executable Requirements Let You Play More Foosball! Eric Landes Agile Coach Press Ganey

  2. Agenda • What bad looks like • How it happens • Better ways • Example

  3. Bad Requirements Examples • Lengthy • Unfocused • Ambiguous • Verified Manually

  4. Bad requirement might look like: • As a consumer of the Comments webService, I can retrieve the sentiment percentage of comments by service • Acceptance Criteria: • Include percent negative, percent positive, percent neutral and percent mixed by service - this will be consistent with our database reports (see database comments page under Attachments section). • Include percentages from the x time period - this will be in the configuration file. For October, it will be from the past 30 days. • Neutral category includes comments categorized as neutral and mixed • The percentage of positive/negative/neutral should add up to 100% by service Because some clients have a category of Open, which we are not using, there is a chance that the percentages will not add up to 100%. • If there is more than 1 site (e.g. CSS ID) or client per service (e.g. CSS ID), aggregate the positive/negative/neutral/mixed percentages. • Include the total number of surveys (e.g. sample size) across all services and sites the user has permission to. This should be consistent with how we count 'total surveys processed' for the database reports (see database comments page under Attachments section). • The percentages and n updated daily based on surveys received. • Exclude Employee (EP, SE, EX), Physician (ME, SS), Community Image (CI) and Safety Culture (SC) in all scenarios from the Improvement Opportunities; use application's configuration file to allow easy changes to this list. • FYI:  if the account has not contracted for comments (indicated in the profile), the widget should not appear or will be replaced by an advertisement). • FYI:  if the account has contracted for comments but has no comments, then the widget should appear with a message like "no data available" - message tbd. • Reference pg 2 under the Links of this story for a wireframe - this wireframe will be updated to incorporate mixed. Comments widget story can be referenced under the Links section of this story

  5. A Common Scenario As a non frequent traveller member visitor to our web site, I want to be able to browse the hotel properties In order to capture sales from non members. demo

  6. So, What Happened?

  7. How did the issues come about? • Working in isolation • Speaking different languages • Trying to cover too many… • Types of users • Actions of a specific user • Exceptions to the ‘happy path’ • Limiting to one type of artifact • Documentation that becomes stale

  8. A Better Strategy • Our strategy for executable requirements means knowing when the requirements are met. This is achieved by: • Collaborating Closely • Creating a Common Language • Removing Ambiguity • Layer Your Test Types

  9. Tips for Close Collaboration • Collaboration on acceptance criteria between customer and team • Get the different parties together • Same room • Video conference/Skype • Collaboration tools like Dabbleboard • Phone call • Confirm agreement with lite documentation

  10. Speak the Same Language • Capture the Common Objective • “Elevator Statement”/Theme • Create a Shared workspace • Physical • Wiki • Keep the Team Consistent

  11. Remove Ambiguity • Provide Additional Context • Have the Conversation • Create an Overview • Supplement with Picture(s) or Diagrams • Identify the Actor or Persona • Mock the UI with Wireframes

  12. Executable Requirements

  13. Layer Your Tests • Traditionally, your test layers might look a lot like this: UAT Manually Executed Test Scripts

  14. Layer Your Tests - More • Traditionally, your test layers might look a lot like this: UAT Manually Executed Test Scripts Unit Test

  15. Layer Your Tests - More • Traditionally, your test layers might look a lot like this: UAT Manually Executed Test Scripts Unit Test

  16. Better Yet… UAT Primarily Exploratory Tests Manual Tests Manually Executed Test Scripts Automated Functional Tests Unit Test Story

  17. Type of Executable Requirements • Automated Functional Tests • Functional tests can be written, regardless of the use of Unit Tests • Automated and integrated into the build activity • Are not necessarily UI tests • Unit Tests cover small pieces of the code, are created by the developers, and are outside the scope of this session. • See “Test Driven Development by Example” by Kent Beck, or “Clean Code” by Robert Martin

  18. So what? • Executable Requirements are a time saver • Helps IT and Business work more closely together • Get the feature right the first time • Lowers the cost of iterating • Reduced maintenance and “end of project” tails to regress • Frees team up to improve software without the big cost of manual regression testing • Introduce new features • Fixing defects • Refactor code

  19. Good Executable Requirements • Understandable to developer • Understandable to business • Unambiguous • Automated • Run frequently

  20. Defining Executable Requirements Fitnesse Scenario: Existing Application Eric – Product Owner/Customer Eric – Technology Team Member . demo

  21. Defining Executable Requirements Specflow Scenario: Existing Application Eric – Product Owner/Customer Eric – Technology Team Member . demo

  22. Speaker Contact Information • Eric Landes (Press Ganey) • corporatecoder@aspalliance.com • http://www.linkedin.com/in/ericlandes • http://twitter.com/ericlandes • This slide deck was developed in association with Dan Neumann • Dan@NeuManagementLLC.com • http://www.linkedin.com/in/MeetDanNeumann • http://twitter.com/Dan_SB

  23. Required Slide Speakers, please list the Breakout Sessions, Interactive Discussions, Labs, Demo Stations and Certification Exam that relate to your session. Also indicate when they can find you staffing in the TLC. Related Content • Breakout Sessions • DEV 204Manual Testing with Microsoft Test Manager. • Dev 309 Test Automation with Microsoft Visual Studio 2010… • Find Me Later At… Visual Studio ALM

  24. DPR Track Resources • http://www.microsoft.com/visualstudio • http://www.microsoft.com/visualstudio/en-us/lightswitch • http://www.microsoft.com/expression/ • http://blogs.msdn.com/b/somasegar/ • http://blogs.msdn.com/b/bharry/ • http://www.microsoft.com/sqlserver/en/us/default.aspx • http://www.facebook.com/visualstudio

  25. Resources • Connect. Share. Discuss. http://northamerica.msteched.com Learning • Sessions On-Demand & Community • Microsoft Certification & Training Resources www.microsoft.com/teched www.microsoft.com/learning • Resources for IT Professionals • Resources for Developers http://microsoft.com/technet http://microsoft.com/msdn

  26. Complete an evaluation on CommNet and enter to win!

More Related