Recommended
Recommended
More Related Content
What's hot
What's hot (17)
Viewers also liked
Viewers also liked (10)
Similar to Adressing requirements with agile practices
Similar to Adressing requirements with agile practices (20)
Recently uploaded
Recently uploaded (20)
Adressing requirements with agile practices
- 1. Addressing Non-Functional Requirements with Agile Practices Francois Boisvert Macadamian Technologies Version: Oct 25th
- 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. Agenda 1. Definition • Quality expectations 2. Breaking down the scope • Functional requirements • Non Functional requirements 3. Confirming the scope • Internal quality • External quality
- 4. Definition What 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. Definition It is all about quality 1. Internal qualities 1. barely visible by stakeholders 2. simplify how to build the software 3. Evolution 2. External qualities 1. Observable at run time 2. visible by stakeholders 3. highly desirable 4. Execution
- 6. Definition Internal 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. Definition External 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. Breaking down the scope From Fuzzy to Accurate FR FR FR FR FR FR NFR
- 9. Breaking Functional Requirements Translate requirements to goals • Focus on creating value • Users desirable outcome first • Behavior Driven-Development • Enable conversations
- 10. Breaking Functional Requirements Express 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. Breaking Functional Requirements Example: 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. Breaking Functional Requirements Confirm 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. Breaking Functional Requirements Express 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. Breaking Functional Requirements Example: 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. Breaking Functional Requirements Illustrate 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. Breaking Non-Functional Requirements Treat 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. Breaking Non-Functional Requirements Two 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. Breaking Non-Functional Requirements Internal 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. Breaking Non-Functional Requirements Examples - 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. Breaking Non-Functional Requirements Restrictions 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. Breaking Non-Functional Requirements Example - 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. Breaking down the scope From Fuzzy to Accurate Recovery Restriction Scenario Test User Story Restriction Scenario Rules
- 23. Confirm Non-Functional Requirements Rules 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. Confirm Non-Functional Requirements Rules 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. Confirm Non-Functional Requirements Confirm 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. Confirm Non-Functional Requirements Testing 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. 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. 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. 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. Q&A
Editor's Notes
- 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