Adressing requirements with agile practices

396 views

Published on

Describes how to handle non-functional requirements in your Agile project.

This presentation was done at Microsoft Techdays 2011.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
396
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • InternatQuality -> EvolutionExternalQuality -> Execution
  • are barely visible by stakeholders but simplify how to build the software
  • carry out the software's functions at run time, and as such, are not only visible by stakeholders but also highly desirable
  • The smaller is the betterBreak the work into self contained, discrete work item that can be satisfied in a finite period of timeIt should be clear whether you have satisfied the work item or notClarityFirst – I will give some background, or refresher on tools we break the functional scopeThen – we will look at breaking down the NFR
  • Master complexity by addressing goals. They are engaging; they enable conversations about how to create valueIt is a placeholder containing just enough information so that the stakeholders can prioritize it and the team can produce a reasonable estimate of the effort to implement it.Quick way of documenting a stakeholder’s desirable outcome without having to elaborate vast formalized requirement documentsEncourage the team to defer collecting detailsAn initial high level story can be written as a first cut and then split into more stories when the team successively refines the software and it becomes important to have the details
  • Canalsoaddpersonas to betterunderstand the users.
  • Role: Student, goal: buy a pass valid only on school days, benefit: go to schoolRole: Worker, goal: buy a monthly pass, benefit: go to work
  • Success criteria convey additional information about the storyThey are a specification as important, if not more important, than the storyThey are a key element of agile specifications
  • Precondition:Describes the current state of the systemAction: Describes a stimulas or a transition to that systemConsequence: describes the resulting states
  • Slide to announcenexttwo sections
  • are barely visible by stakeholders but simplify how to build the software
  • The smaller is the betterBreak the work into self contained, discrete work item that can be satisfied in a finite period of timeIt should be clear whether you have satisfied the work item or notClarityFirst – I will give some background, or refresher on tools we break the functional scopeThen – we will look at breaking down the NFR
  • Pair programming is a technique in which two teammates work together at one workstation. One, the driver, typing at the keyboard while the other, the observer, looking at what is produced as it is typed in. The two teammates switch roles frequently. While reviewing, the observer also considers the constraints imposed by the restrictions. Its main contribution is to come up with ideas for improvements and likely future problems to address. This allows the driver to focus his attention on the task at hand, using the observer as a safety net and guide
  • Peer review is a technique in which teammates organize a formal inspection to assess compliance with restrictions. Peer review use well-defined roles, checklists, preparation and inspection meeting to maximize improvements. One key characteristic of a peer review is that each teammate involved has a distinct role to play.Moderator: The moderator is responsible for organizing the meeting and keeping the inspection being productive and a pleasant activity.Author: The author is the person who creates the work product under review. He plays a minor role in the inspection. Its involvement is limited to listen and learn.Reviewer: The reviewer is a teammate responsible to suggest improvements. There is usually more than one reviewer per inspection.Scribe: The scribe records improvements that are detected as a list of rework to be done by the author. Neither the moderator nor the author should be the scribe.During preparation each reviewer works alone to scrutinize the work product under review. The reviewers use the checklist to stimulate their examination. Reviewers locate the checklist by looking at the contents of each restriction. Checklist should focus reviewer attention on areas that have been problems in the past. During the inspection meeting, the moderator chooses someone other than the author to present the work product under review. Reviewers suggest improvements using constructive feedbacks. The scribe records reworks as they are detected. The author should step out of the conversation and become silent as a fly on the wall. The inspection should not last more than two hours. Following the inspection, the moderator is responsible for seeing that all rework recorded by the scribe is carried out promptly by the author.
  • Robustness: Client-server architecture  remove the server, does the client code copes gracefully with errors during execution?
  • Bewarethattoomany restrictions caneasilyspoil the success of an iteration
  • moderator is responsible for seeing that all rework recorded by the scribe is carried out promptly by the author.
  • Restrictions make explicit cost of qualityNegotiate with stakeholders to remove restrictions
  • DO NOT REMOVE THIS SLIDE
  • Adressing requirements with agile practices

    1. 1. Addressing Non-FunctionalRequirements with Agile PracticesFrancois BoisvertMacadamian TechnologiesVersion: Oct 25th
    2. 2. Who Am I?• VP Services Delivery • Delivering quality software, on time and on budget • Customer satisfaction• Macadamian Technologies • Creating software products, • from napkin sketch to market ready • www.macadamian.com
    3. 3. Agenda1. Definition • Quality expectations2. Breaking down the scope • Functional requirements • Non Functional requirements3. Confirming the scope • Internal quality • External quality
    4. 4. DefinitionWhat are they?• Specify "how well" the "what" must behave• Impose constraints• Cut across all functional requirements• Criteria that can be used to judge the operation of a system, rather than specific behaviors• Also known as "technical requirements", “quality attributes” or "quality of service requirements“
    5. 5. DefinitionIt is all about quality1. Internal qualities 1. barely visible by stakeholders 2. simplify how to build the software 3. Evolution2. External qualities 1. Observable at run time 2. visible by stakeholders 3. highly desirable 4. Execution
    6. 6. DefinitionInternal Quality - What is it? Non-Functional Definition Requirement Simplicity Ease to understand or explain Maintainability Ease to change and evolve with minimal effort Testability Ease to confirm conformance by observing a reproducible behavior Portability Ease to reuse for multiple platforms Extensibility Ease to takes into consideration future growth
    7. 7. DefinitionExternal Quality - What is it? Non-Functional Definition Requirement Correctness Ability with which the software respects the specification. Performance Ease with which the software is doing the work it is supposed to do. Usually it is measured as a response time or a throughput. Reliability Ability with which the software performs its required functions under stated conditions for a specified period of time. Robustness Ability with which the software copes with errors during execution. Scalability Ability with which the software handles growing amounts of work in a graceful manner. Security Degree to which the software protects against threats. Usability Ease with which the software can be used by specified users to achieve specified goals.
    8. 8. Breaking down the scopeFrom Fuzzy to Accurate FR FR FR FR FR FR NFR
    9. 9. Breaking Functional RequirementsTranslate requirements to goals• Focus on creating value• Users desirable outcome first• Behavior Driven-Development• Enable conversations
    10. 10. Breaking Functional RequirementsExpress goals with user stories• User story • short description written in everyday language • represents a discrete piece of demonstrable functionality • It is a desirable outcome by a stakeholder• Classic template • “As a < role>, I want <goal> so that <benefit>”
    11. 11. Breaking Functional RequirementsExample: User stories for a Transit Authority• As a <student>, I want <to buy a pass valid only on school days> so that I can <go to school>• As a <worker>, I want <to buy a monthly pass> so that I can <go to work>
    12. 12. Breaking Functional RequirementsConfirm stories with success criteria• Establishes the conditions of acceptance• Describes how the stakeholders plan to verify the desirable outcome• Enables the team to know when they are done
    13. 13. Breaking Functional RequirementsExpress success criteria with scenarios• Scenarios • Concrete example written in everyday language • a significant exercise that is required for the fulfillment of a user story • It is a desirable outcome by a stakeholder • Expressed with formality• Classic template • “Given < precondition>, When <action> Then <outcome>”
    14. 14. Breaking Functional RequirementsExample: As a user, I can buy a bus pass Given the shopping cart contains a monthly pass When buyer checkout the shopping cart Then the price is 146 dollars
    15. 15. Breaking Functional RequirementsIllustrate collaboratively in a two-step process Step 1 Step 2 During the backlog maintenance During the iteration Variant of scenario 1 Key scenario 1 Variant of scenario 1 Variant of scenario 1 Variant of scenario 2 User Story Key scenario 2 Variant of scenario 2 Variant of scenario 2 Variant of scenario 3 Key scenario 3 Variant of scenario 3 Variant of scenario 3
    16. 16. Breaking Non-Functional RequirementsTreat NFR as constraints to guide your work• Imposes a condition to make the requirements in line with quality expectations• Sets a limit to comply with• Satisfied in a finite period of time• Helps determine whether you have satisfied the non-functional requirements• Applied to functional scope
    17. 17. Breaking Non-Functional RequirementsTwo types of constraint• Internal quality • Rule is a “constraint” that sets a limit to comply during software construction• External quality • Restriction is a “constraint” that sets a limit to comply during software execution
    18. 18. Breaking Non-Functional RequirementsInternal Quality using “Rules”• Rule is a constraint that sets how software construction is built• Rules are global and apply to each scenario• Rules are guidelines• Set the standards• Guide the team in their execution
    19. 19. Breaking Non-Functional RequirementsExamples - Rules Non-Functional Rule Requirement Simplicity Naming convention: Apply a naming conventions on all code Maintainability Continuous Integration: Verify each new checked in code if it integrates with success in the development branch. Testability Unit testing: Verify unit tests and Apply the Red-Green-Refactor concept. Write test first, do some code to make the test pass, Refactor the code. Portability Multi-target compiling: Verify code compile on multiple platforms Extensibility Design Patterns: Verify key architecture patterns are properly used
    20. 20. Breaking Non-Functional RequirementsRestrictions should be SMART• Specific • It should target a piece of functionality that is small, consistent and simple• Measurable • It imposes a limit that is measurable, otherwise how would you know when you’ve addressed it• Attainable • It is recognized as achievable by the team• Relevant • It is directly related, connected, and pertinent to the non-functional requirement• Traceable • It is linked with a requirement and a target that justifies why it exists
    21. 21. Breaking Non-Functional RequirementsExample - Restrictions Restriction (Performance) Scenario Measure: Response time must be smaller than 10 seconds Given buyer is logged has a student Recovery: Log issue and notify the user that the query When buyer request the list of transit fares cannot be completed Then | Id | Name |Price| | 002 | Student Monthly Pass | 76 | | 100 | One Day Pass |6 | | 202 | Student Booklet of | 15 | Restriction (Security) | | 10 Single tickets | 15 | Measure: User must be authenticated Recovery: Log issue and redirect to login page
    22. 22. Breaking down the scopeFrom Fuzzy to Accurate Recovery Restriction Scenario Test User Story Restriction Scenario Rules
    23. 23. Confirm Non-Functional RequirementsRules with collaborative construction• Pair programming • Two teammates work together at one workstation • Driver • Type at the keyboard • Focus his attention on the task at hand • Use the observer as a safety net and guide • Observer • Look at what is produced by driver • Consider the constraints imposed by the rules • Come up with ideas for improvements • The two teammates switch roles frequently
    24. 24. Confirm Non-Functional RequirementsRules with collaborative construction• Peer review (aka formal inspection during construction) • Well-defined roles • Moderator, author, reviewers • Planning • Inspection is scheduled by moderator (from code analysis measure) • Preparation • Reviewer works alone to scrutinize the work product under review • Reviewer uses the rule definition to stimulate their examination • Inspection • Moderator chooses someone other than the author to present the work product • Authoris a « fly on the wall » and scribe records reworks as they are detected • Constructive feedbacks, « I would replace with … », Emphasis is on improving knowledge • After inspection • Moderator is responsible for seeing that all rework is carried out promptly by the author
    25. 25. Confirm Non-Functional RequirementsConfirm restrictions with tests• Correctness: Acceptance testing• Performance: Response time or throughput testing• Reliability: Testing over a period of time (memory leaks ???)• Robustness: Simulate broken component• Scalability: Load testing (with growing amounts of work)• Security: Intrusion testing• Usability: Testing with real users
    26. 26. Confirm Non-Functional RequirementsTesting restriction is costly• Negotiate with stakeholders to reduce number of restrictions • Is it « really, really » a desirable outcome?• Target a specific iteration for testing a non- functional requirement • Benefit: Transform from a recurrent concern to a one- time concern • Benefit: Handle the concern with a user story
    27. 27. Confirm Non-Functional Requirements• Each scenario is not « Done » until • Each rule is confirmed • Each restrictions is tested • Each recovery is tested• Each user story is not « Done » until • Each rule is confirmed • Each tests
    28. 28. Next Steps• Add „Scenario‟, „Rule‟ and „Restriction‟ Work Item Type to your TFS• Improve internal quality using rules • Create global rules for scenario and user story • Enforce rules with collaborative construction• Improve external quality using restrictions • Create specific restrictions for each scenario • Enforce restrictions with tests
    29. 29. Resources• Training about Agile Specification and TFS • http://mariocardinal.com• Book • Title: Agile Specification • Author: Mario Cardinal • Publisher: Addison-Wesley • Publication Date: Spring 2012
    30. 30. Q&A

    ×