OneStopTesting - Quality Testing Jobs, eBooks, Articles, FAQs, Training Institutes, Testing Software, Testing downloads, testing news, testing tools, learn testing, manual testing, automated testing, load runner, winrunner, test director, silk test, STLC

Forum| Contact Us| Testimonials| Sitemap| Employee Referrals| News| Articles| Feedback| Enquiry
 
Testing Resources
 
  • Testing Articles
  • Testing Books
  • Testing Certification
  • Testing FAQs
  • Testing Downloads
  • Testing Interview Questions
  • Career In Software Testing
  • Testing Jobs
  • Testing Job Consultants
  • Testing News
  • Testing Training Institutes
  •  
    Fundamentals
     
  • Introduction
  • Designing Test Cases
  • Developing Test Cases
  • Writing Test Cases
  • Test Case Templates
  • Purpose
  • What Is a Good Test Case?
  • Test Specifications
  • UML
  • Scenario Testing
  • Test Script
  • Test Summary Report
  • Test Data
  • Defect Tracking
  •  
    Software testing
     
  • Testing Forum
  • Introduction
  • Testing Start Process
  • Testing Stop Process
  • Testing Strategy
  • Risk Analysis
  • Software Listings
  • Test Metrics
  • Release Life Cycle
  • Interoperability Testing
  • Extreme Programming
  • Cyclomatic Complexity
  • Equivalence Partitioning
  • Error Guessing
  • Boundary Value Analysis
  • Traceability Matrix
  •  
    SDLC Models
     
  • Introduction
  • Waterfall Model
  • Iterative Model
  • V-Model
  • Spiral Model
  • Big Bang Model
  • RAD Model
  • Prototyping Model
  •  
    Software Testing Types
     
  • Static Testing
  • Dynamic Testing
  • Blackbox Testing
  • Whitebox Testing
  • Unit Testing
  • Requirements Testing
  • Regression Testing
  • Error Handling Testing
  • Manual support Testing
  • Intersystem Testing
  • Control Testing
  • Parallel Testing
  • Volume Testing
  • Stress Testing
  • Performance Testing
  • Agile Testing
  • Localization Testing
  • Globalization Testing
  • Internationalization Testing
  •  
    Test Plan
     
  • Introduction
  • Test Plan Development
  • Test Plan Template
  • Regional Differences
  • Criticism
  • Hardware Development
  • IEEE 829-1998
  • Testing Without a TestPlan
  •  
    Code Coverage
     
  • Introduction
  • Measures
  • Working
  • Statement Coverage
  • Branch Coverage
  • Path Coverage
  • Coverage criteria
  • Code coverage in practice
  • Tools
  • Features
  •  
    Quality Management
     
  • Introduction
  • Components
  • Capability Maturity Model
  • CMMI
  • Six Sigma
  •  
    Project Management
     
  • Introduction
  • PM Activities
  • Project Control Variables
  • PM Methodology
  • PM Phases
  • PM Templates
  • Agile PM
  •  
    Automated Testing Tools
     
  • Quick Test Professional
  • WinRunner
  • LoadRunner
  • Test Director
  • Silk Test
  • Test Partner
  • Rational Robot
  •  
    Performance Testing Tools
     
  • Apache JMeter
  • Rational Performance Tester
  • LoadRunner
  • NeoLoad
  • WAPT
  • WebLOAD
  • Loadster
  • OpenSTA
  • LoadUI
  • Appvance
  • Loadstorm
  • LoadImpact
  • QEngine
  • Httperf
  • CloudTest
  •  
    Languages
     
  • Perl Testing
  • Python Testing
  • JUnit Testing
  • Unix Shell Scripting
  •  
    Automation Framework
     
  • Introduction
  • Keyword-driven Testing
  • Data-driven Testing
  •  
    Configuration Management
     
  • History
  • What is CM?
  • Meaning of CM
  • Graphically Representation
  • Traditional CM
  • CM Activities
  • Tools
  •  
    Articles
     
  • What Is Software Testing?
  • Effective Defect Reports
  • Software Security
  • Tracking Defects
  • Bug Report
  • Web Testing
  • Exploratory Testing
  • Good Test Case
  • Write a Test
  • Code Coverage
  • WinRunner vs. QuickTest
  • Web Testing Tools
  • Automated Testing
  • Testing Estimation Process
  • Quality Assurance
  • The Interview Guide
  • Upgrade Path Testing
  • Priority and Severity of Bug
  • Three Questions About Bug
  •    
     
    Home » Testing Articles » Manual Testing Articles » Agile Requirements

    Agile Requirements

    A D V E R T I S E M E N T


    2

    In the last few years, the agile software development movement has created a paradigm shift in how we work to understand system requirements. Agile teams shape software systems using a collaborative process, with executable software at its heart and documents marginalised to a peripheral role. This creates a fundamental shift away from tools for managing requirements artefacts. Instead, we need tools that support collaboration and the gradual distillation of business rules into automated test suites.

    Agile software development is a general descriptive term for an approach that is implemented by a number of different software development methods, such as XP, Scrum and DSDM. The common ground shared by agile methods is that they support the values and principles embodied in the Agile Manifesto [1]. Agile software development evolved in response to deficiencies with document-heavy waterfall development. It is useful to begin by outlining some of the limits of the traditional approach to requirements before moving on to the main subject of this article, Agile Requirements.

    On traditional software development projects we talk about capturing the requirements -as if we are engaged in a hunt to cage some wild beasts that lurk in the jungle. What is actually meant by this phrase is a less exciting activity - producing documents, which specify a system in sufficient detail that software development can proceed by reference to these documents alone. If you cast your mind back and imagine all the requirements documents that you have ever read piled up, it is likely to be a hefty stack and the hours spent poring over those documents innumerable. Although, it is theoretically possible to capture my knowledge in a document from which the reader can extract the same knowledge without distortion, this may not be a practical or efficient way to communicate requirements for complex software systems.

    In determining our process for developing software it is important to remember that the primary purpose of a development project is to deliver is a software system that generates value to a business. Models and documents are essentially by-products of the development; they do not generate value directly. If we are to optimize the flow of value from software development then we need to think seriously about eliminating process inventory and waste.

    Limits of Documents

    A typical programmer's experience with traditional requirements is working from a document written in dry, formal language, that describes a desired software system. By studying this document, s/he gradually builds a mental model that guides the development of an executable software system. The requirements document acts as both means of communication and data storage (preserving evidence of the request). When you put yourself in the place of this programmer there are several flaws with the use of documents as a communication medium that you are likely to encounter. Documents are selective and unidirectional; they may also be ambiguous, vague and conceal gaps.

    Unidirectional

    Documents are a one-way communication medium; information flows from author to reader. There is no opportunity for the reader to ask questions, offer ideas and insights. The author may try to anticipate questions but cannot realistically be expected to address everything and in an attempt to cover everything, a concise abstraction may be lost in a forest of pages.

    A programmer working from a document is likely to find parts of the document difficult to understand. This may be due to poor choice of words by the author or lack of reader's background knowledge. How does that programmer get to the bottom of the intended meaning? In a corporate context, s/he may not have met the author and the normal channel for questions will be correspondence via email, which takes time. If working under time-pressure a programmer may make their own conclusion about the intended meaning to avoid delays. Getting answers to questions takes time but guessing the answer can lead to developing the wrong software system.

    From the author's perspective, there is likely to be a delay between writing a document and receiving questions from readers. Any gaps spotted by readers will require the author to update the document. Documents take effort to maintain with significant ceremony to sign-off each new draft. This makes it possible for documents to fall out of step with current agreed working understanding of system requirements.

    Selective

    The author writes from their personal perspective on the system under development and naturally makes assumptions about the background knowledge of the readers. Requirements documents often describe what is required rather than why � outlining a desired solution rather than explaining the problem space. Little is said about the needs of the users and business context surrounding the system development. Following traditional development process it is assumed that the programmer does not need to know this information because requirements are chosen purely on business grounds. The job of the programmer is limited to the technical implementation of a system rather than contributing ideas on how to achieve business benefits. However, during the implementation many micro-level decisions will be made by the programmer, an awareness of the system context could help with these.

    Cost

    When we work in the abstract realm of pure analysis, we are detached from physical constraints such as implementation costs and limits imposed by technology choices. If requirements are considered from a purely business perspective then we may get so creative that we specify a system that exceeds our budget.

    When planning a project it is useful to be able to identify the priority of requirements so that we can consider delivering the high value features early and can mark nice-to-have features as potential contingency for schedule slips. However, traditional requirements specifications fix the scope of the entire development, all system features described are deemed necessary and their descriptions are intertwined throughout the documents. Expressing requirements in a meshed form makes it difficult to trim scope in response to development delays.



    More Manual Testing Articles



    discussionDiscussion Center
    Discuss
    Discuss

    Query

    Feedback
    Yahoo Groups
    Y! Group
    Sirfdosti Groups
    Sirfdosti
    Contact Us
    Contact

    Looking for Software Testing eBooks and Interview Questions? Join now and get it FREE!
     
    A D V E R T I S E M E N T
       
       

    Members Login


    Email ID:
    Password:


    Forgot Password
    New User
       
       
    Testing Interview Questions
  • General Testing
  • Automation Testing
  • Manual Testing
  • Software Development Life Cycle
  • Software Testing Life Cycle
  • Testing Models
  • Automated Testing Tools
  • Silk Test
  • Win Runner
  •    
       
    Testing Highlights

  • Software Testing Ebooks
  • Testing Jobs
  • Testing Frequently Asked Questions
  • Testing News
  • Testing Interview Questions
  • Testing Jobs
  • Testing Companies
  • Testing Job Consultants
  • ISTQB Certification Questions
  •    
       
    Interview Questions

  • WinRunner
  • LoadRunner
  • SilkTest
  • TestDirector
  • General Testing Questions
  •    
       
    Resources

  • Testing Forum
  • Downloads
  • E-Books
  • Testing Jobs
  • Testing Interview Questions
  • Testing Tools Questions
  • Testing Jobs
  • A-Z Knowledge
  •    
    Planning
    for
    Study ABROAD ?


    Study Abroad


    Vyom Network : Free SMS, GRE, GMAT, MBA | Online Exams | Freshers Jobs | Software Downloads | Programming & Source Codes | Free eBooks | Job Interview Questions | Free Tutorials | Jokes, Songs, Fun | Free Classifieds | Free Recipes | Bangalore Info | GATE Preparation | MBA Preparation | Free SAP Training
    Privacy Policy | Terms and Conditions
    Sitemap | Sitemap (XML)
    Job Interview Questions | Placement Papers | SMS Jokes | C++ Interview Questions | C Interview Questions | Web Hosting
    German | French | Portugese | Italian