• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile Requirements Writing
 

Agile Requirements Writing

on

  • 24,569 views

Pathfinder Development's approach to writing requirements for agile software development.

Pathfinder Development's approach to writing requirements for agile software development.

Statistics

Views

Total Views
24,569
Views on SlideShare
23,392
Embed Views
1,177

Actions

Likes
133
Downloads
0
Comments
6

25 Embeds 1,177

http://agile.soup.io 422
http://www.pathf.com 387
http://butlerhouse.net 102
http://businessandrequirements.blogspot.com 57
http://pathfindersoftware.com 53
http://www.slideshare.net 39
http://brisdom.com 30
http://businessandrequirements.blogspot.in 26
http://www.butlerhouse.net 23
http://confluence.vireg.com 8
http://businessandrequirements.blogspot.ca 5
http://feeds.feedburner.com 3
http://bummerware.tumblr.com 3
http://www.sophia.org 3
http://www.pearltrees.com 2
http://planetrails.digitalcodes.org 2
http://businessandrequirements.blogspot.com.au 2
http://www.hanrss.com 2
http://www.soup.io 2
http://businessandrequirements.blogspot.sg 1
http://planetrubyonrails.net 1
http://businessandrequirements.blogspot.co.uk 1
http://translate.googleusercontent.com 1
http://businessandrequirements.blogspot.sk 1
applewebdata://9A5D2829-76ED-431B-8082-8400F53A3FF0 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

16 of 6 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agile Requirements Writing Agile Requirements Writing Presentation Transcript

    • From Concept to Coding THE ART OF WRITING REQUIREMENTS
    • The Beginning: Oh, the noise! Oh, the Noise! Noise! Noise! That's one thing he hated! The NOISE! NOISE! NOISE! ~ The Grinch PATHFINDER DEVELOPMENT © 2008 The beginning of a project generates a lot of great ideas; BUT, until a structure or cohesion is applied to these ideas, they end up being a loose collection of separate ideas with no direction. (And weʼve all worked on THOSE kinds of projects before.) Requirements brings cohesion and direction to the noise.
    • Requirements: Establish the territory; establish the context; establish the direction PATHFINDER DEVELOPMENT © 2008 Because we are consultants, when we start new projects we like to know the clientʼs territory, context and direction. Territory is the space the client occupies - their vertical; context is the clientʼs role within that territory - what service to they provide; direction is where the client needs to go - does the project support this
    • Product Requirements defines product concept and user base PATHFINDER DEVELOPMENT © 2008
    • From Problem to Solution Client: Sustainable Developer Works with communities and planners ★ Promotes emerging technology ★ • wind farms, sustainable housing, etc. PATHFINDER DEVELOPMENT © 2008 Hereʼs our imaginary client: a Sustainable Developer. Their territory is construction/development; the context is that they bring green ideas to traditional planning/building.
    • Business Problem: no one gets our ideas until theyʼre built -- and then itʼs too late. PATHFINDER DEVELOPMENT © 2008 If you canʼt articulate the problem, how can you define a solution?
    • Product Concept: We need an interactive tool to visually explain our ideas in order to get usersʼ input and buy-in PATHFINDER DEVELOPMENT © 2008 The product concept addresses the problem; it is the overarching idea of your software and all features need to relate back to it. Defining the concept is the first step in restraining scope creep.
    • Identify the Users Who will be using this software Research who will be using your product ★ Identify the Personas ★ PATHFINDER DEVELOPMENT © 2008 Identifying users allows you to create a product that meets their needs, instead of a product that meets what it thinks the needs of the users are. Addressing the actual needs of the people who will be using your product puts you further ahead on the road to success.
    • Personas: Personas are fictitious characters created to represent the different user types that might use a site or product. PATHFINDER DEVELOPMENT © 2008 Personas are effective in keeping meetings focused on the product and the users who will be directly interacting with it. Addressing any issues from the POV of a persona removes the personal from resolving fringe case arguments or the latest widget advocates; i.e., stating it makes no sense to Persona Sally is an effective argument since she is the end user of the product
    • Who are the Personas for this Product: We need an interactive tool to visually explain our concepts in order to get usersʼ input and buy-in PATHFINDER DEVELOPMENT © 2008 hereʼs the concept again -- research into the types of users interacting with this product will yield personas
    • city council the community fellow visionaries PATHFINDER DEVELOPMENT © 2008 For our case study, weʼll say our research uncovered users who can be categorized into these groups: city council fellow visionaries the community
    • Identify Usersʼ Goals What do they need to accomplish; what are their goals High level User Stories describe needs and goals ★ As a user, I need to do a task so I can accomplish my goal ★ PATHFINDER DEVELOPMENT © 2008 Personas have needs and goals. User stories help us to transform these needs and goals into user requirements. These requirements will, in turn, define what it is weʼre building.
    • As a member of the Community, I need to: Search for developments in my area ★ so that I can stay current View the proposed solutions so that I ★ can become informed Be able to add my comments so that ★ my voice is present View a list of meeting times so that I ★ can plan to participate Receive alerts so that I can be ★ updated PATHFINDER DEVELOPMENT © 2008 User Story: As a user, I need to do something in order to get this benefit.
    • User Needs > Features > Scope Personasʼ definition helps to determine: Tasks the system must support for user to meet their ★ goals • add an account • manage that account Which tasks to consolidate into features ★ • Adding an account and managing that account means at a high level weʼll need an Account area in the application Features & tasks determine the scope and effort ★ PATHFINDER DEVELOPMENT © 2008
    • Concept + Users + Tasks = List of Features PATHFINDER DEVELOPMENT © 2008 The list of features is what youʼll need to begin to scope out a project. Writing user stories for the features helps to nail down scope and determine the needed effort by development. Ranking the features helps with the iteration planning.
    • Feature Requirements define the scope and functionality PATHFINDER DEVELOPMENT © 2008
    • Anatomy of a Feature Requirement For each Feature: Identify the user stories ★ Write the acceptance tests ★ Diagram the workflow ★ Create the wireframes ★ Write the specifications ★ PATHFINDER DEVELOPMENT © 2008 At Pathfinder, weʼve found documenting these five attributes are sufficient to fully define a feature. Starting at the highest level (user story), we drill down into the details, uncovering gaps or discrepancies before weʼve started coding. Design before development saves money and time.
    • Anatomy of a Feature Requirement For each Feature: Identify the user stories ★ Write the acceptance tests ★ Diagram the workflow ★ Create the wireframes ★ Write the specifications ★ PATHFINDER DEVELOPMENT © 2008 At Pathfinder, weʼve found documenting these five attributes are sufficient to fully define a feature. Starting at the highest level (user story), we drill down into the details, uncovering gaps or discrepancies before weʼve started coding. Design before development saves money and time.
    • User Story: States the functionality of a feature as told from the POV of the Persona. Describes the what, not the how. PATHFINDER DEVELOPMENT © 2008 User Stories are very high level and are used to estimate the degree of difficulty to implement (which ties in with iteration planning) Use cases are a sequence of steps detailing the interactions between an actor and the system and are generally used to capture the functional requirements of a system before implementation.
    • Characteristics of a good User Story - who, what, why A user story is written at a high level ★ Tells you who is using the feature ★ Describes what a user can do with this feature, not how theyʼll do it ★ States the featureʼs benefit for the user Used to generate the acceptance tests PATHFINDER DEVELOPMENT © 2008 The syntax we use for User Stories is: User Story: As a [persona - who], I want [feature - what], so I can [benefit - why].
    • User Stories - Where to Start? Identify the tasks a user needs to do in a feature I need to create/update/delete accounts ★ Write the user stories based on those tasks, but at a high level I need to manage accounts ★ The acceptance tests will get into more detail PATHFINDER DEVELOPMENT © 2008 The syntax we use for User Stories is: User Story: As a [persona - who], I want [feature - what], so I can [benefit - why].
    • User Story: As a [persona - who], I want [feature - what], so I can [benefit - why]. PATHFINDER DEVELOPMENT © 2008
    • User Story: As a Community member, I want to find planning meetings, so I can participate in the process. PATHFINDER DEVELOPMENT © 2008
    • Anatomy of a Feature Requirement For each Feature: Identify the user stories ★ Write the acceptance tests ★ Diagram the workflow ★ Create the wireframes ★ Write the specifications ★ PATHFINDER DEVELOPMENT © 2008
    • Acceptance Test: series of scenarios based on the User Story that defines the scope of the feature along with its acceptance criteria. PATHFINDER DEVELOPMENT © 2008 Describe the feature such that everyone – the business people, the analyst, the developer and the tester – have a common understanding of the scope of the work and agree to a common definition of “done”.
    • Characteristics of a good Acceptance Test Acceptance Tests have more detail than a User Story but less than the development specifications Two parts: Title describes an activity that the user wants to do in ★ this feature Scenario is described in terms of Givens, Events and ★ Outcomes PATHFINDER DEVELOPMENT © 2008 Acceptance tests are the next level down in details from the User Stories. They are scoping out the feature and defining what complete means for that feature. While they are written in more detail than a user story, itʼs still more along the lines of a scenario rather than specifications.
    • Givens, Events, Outcomes Scenarios: Precondition (the givens) ★ Actions (the events) ★ Expected Behavior (the outcome) ★ PATHFINDER DEVELOPMENT © 2008 The givens should define all of, and no more than, the required context The event should describe the actions the user takes Outcome describes the desired behavior of the actions
    • Title Given that [context] And that [some more context] When [event/action] And [additional actions] Then [expected outcome] And [additional expected outcome] PATHFINDER DEVELOPMENT © 2008
    • Search for Events Given that the user is a member of the community And that the user has successfully logged in When the user enters search criteria for an event And the user specifies a location Then the systems returns all events for that location that match the search criteria PATHFINDER DEVELOPMENT © 2008
    • Anatomy of a Feature Requirement For each Feature: Identify the user stories ★ Write the acceptance tests ★ Diagram the workflow ★ Create the wireframes ★ Write the specifications ★ PATHFINDER DEVELOPMENT © 2008
    • Workflow: diagrams a sequence of steps from start to finish that a user takes in order to complete a feature. PATHFINDER DEVELOPMENT © 2008
    • Workflow Diagrams The end-to-end flow visualizes the big picture Identifies the starting point(s) ★ Notes any decision point(s) ★ Shows any subpaths a user can take ★ Declares the End Point ★ PATHFINDER DEVELOPMENT © 2008
    • Workflow Language start page action decision? process end PATHFINDER DEVELOPMENT © 2008 Regardless of the language you use, be consistent in your diagrams and differentiate between the different actions in a flow. Also, know your audience -- in the US and other Western cultures we read left to right, top to bottom. Therefore, construct your flows in such a way that they flow naturally for your readers.
    • Workflow Diagrams Illustrate a Userʼs Path through the Feature ★ Highlight Start Point(s) ★ Identify Decision Point(s) ★ Show where the flow ends PATHFINDER DEVELOPMENT © 2008 A good diagram will show all the entry points, the decisions and their results, and any branches available to the user. The flow will also show the end point. They help team members create the user experience, both at the UI layer and the backend workflow.
    • Anatomy of a Feature Requirement For each Feature: Identify the user stories ★ Write the Acceptance Tests ★ Diagram the workflow ★ Create the wireframes ★ Write the specifications ★ PATHFINDER DEVELOPMENT © 2008
    • Wireframes: a visual guide used to suggest the layout of the fundamental elements in the interface. PATHFINDER DEVELOPMENT © 2008 Because a picture is worth 1,000 words.
    • Wireframes Provides a visual reference for the structure of a page and placement of elements Establishes the language, content and structure of user interaction PATHFINDER DEVELOPMENT © 2008
    • What does a Wireframe look like? PATHFINDER DEVELOPMENT © 2008 wireframes can run from pencil sketches to whiteboard drawings to layouts using a vector-based graphic program to high- fidelity. The type of wireframe you use is the one appropriate to the state of your project and to the feature you need to convey.
    • PATHFINDER DEVELOPMENT © 2008 wireframes can run from pencil sketches to whiteboard drawings to layouts using a vector-based graphic program to high- fidelity. The type of wireframe you use is the one appropriate to the state of your project and to the feature you need to convey.
    • PATHFINDER DEVELOPMENT © 2008 wireframes can run from pencil sketches to whiteboard drawings to layouts using a vector-based graphic program to high- fidelity. The type of wireframe you use is the one appropriate to the state of your project and to the feature you need to convey.
    • PATHFINDER DEVELOPMENT © 2008 wireframes can run from pencil sketches to whiteboard drawings to layouts using a vector-based graphic program to high- fidelity. The type of wireframe you use is the one appropriate to the state of your project and to the feature you need to convey.
    • PATHFINDER DEVELOPMENT © 2008 wireframes can run from pencil sketches to whiteboard drawings to layouts using a vector-based graphic program to high- fidelity. The type of wireframe you use is the one appropriate to the state of your project and to the feature you need to convey.
    • PATHFINDER DEVELOPMENT © 2008 Since it is the conversation around the drawing, and not the drawing my itself, that is of interest, wireframes can capture that conversation by notating the user interactions.
    • Anatomy of a Feature Requirement For each Feature: Identify the user stories ★ Write the Acceptance Tests ★ Diagram the workflow ★ Create the wireframes ★ Write the specifications ★ PATHFINDER DEVELOPMENT © 2008
    • Specifications: document the details and behavior of a feature, explaining the content and actions so that developers can start coding. PATHFINDER DEVELOPMENT © 2008
    • Specifications Describe: Elements that should appear on a page How the user interacts with a page What happens when the user does something PATHFINDER DEVELOPMENT © 2008 write in plain english -- not developer speak or consultant speak
    • Specifications Search Events Search criteria - at least one is required: ★ • date - standard text field with calendar widget • location - pulldown of locations in the system • sponsor - pulldown of city aldermen showing FirstName LastName Search validation ★ • date format is valid - MMMDDYYY • at least one field has data On Submit If errors: ★ • cancel submit • highlight fields with errors (if no fields contain data, show message that at least one field must contain data) • display error message: Please correct the error before continuing If no errors: ★ • Display search results on the Events List Page PATHFINDER DEVELOPMENT © 2008
    • for more information, contact: Paul Dittmann pdittmann@pathf.com | 312.372.1058 x6006