Agile Methodology and System Analysis



Vidya V Iyer

University of Missouri, St Louis

November 29, 2006


Introduction to Agile Methodology

Principles of Agile Methodology

Agile Analysis

Steps of Agile System Analysis Process

Artifacts from Agile Analysis

Agile Analysts

Agile Requirements

Agile Requirements Best Practices

Agile Analysis Risks and Rewards





Agile- denoting the quality of being agile; readiness; nimbleness, activity, dexterity in motion”- software development methods are attempting to offer an answer to the eager business community wanting lighter weight and faster and nimble software development processes. This is especially the case with rapidly growing and volatile internet software industry as well as for the emerging mobile environment[Abrahhamson,2002].

According to Highsmith and Cockburn(2001), “ what is new about agile methods is not the practices they use, but their recognition of people as the primary drivers of project success, coupled with intense focus on effectiveness and maneuverability. This yields new combinations of values and principles that define an agile view of the world.

Cockburn defines the core of agile software development methods as the use of light but sufficient rules of project behavior and the use of human-and communication oriented tools. The agile process is both light and sufficient. Lightness is a means of remaining maneuverable. Sufficiency is a matter of staying in the game(Cockburn, 2002).

Miller(2001) gives the following characterization to agile software processes from the fast delivery point of view, which allows shortening the life-cycle of projects:

*      Modularity on development process level

*      Iterative with short cycles enabling fast verifications and corrections

*      Time bound with iteration cycles from one to six weeks.

*      Parsimony in development process removes all unnecessary activities.

*      Adaptive with possible emergent new risks

*      Incremental process approach that allows functioning application building in small steps

*      Convergent approach minimizes the risk

*      People-oriented i.e., agile processes favor people over processes and technology

*      Collaborative and communicative working style.

Favaro(2002) discusses the emergence of strategies for confronting a vague process showing changing requirements. He proposes an iterative development paradigm as the common denominator of agile processes. Requirements may be introduced, modified, or removed in successful iterations.

A basic set of commonsense approaches emerging from agile software development processes have been suggested by Ambler (2002a) as follows:

*      People matter

*      Less documentation is possible

*      Communication is a critical issue

*      Modeling tools are not as useful as thought

*      Big up-front design is not required.

Thus, the focal points of light and agile methods are simplicity and speed. In development work, accordingly, the development group concentrates only on the functions needed at first hand, delivering them fast, collecting feedback and reacting to received information. A development method is agile if it is incremental ( small software releases with rapid cycles), cooperative( customer and developers working constantly together with open communication), straightforward( the method itself is easy to learn and to modify), and adaptive( able to make last minute changes)[Dave,2005]. Initially, agile methods were called "lightweight methods." In 2001, prominent members of the community met at Snowbird and adopted the name "agile methods." Later, some of these people formed The Agile Alliance, a non-profit organization that promotes agile development. Early agile methods—created prior to 2000—include Scrum (in management) (1986), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and DSDM (1995)[Wikipedia,24].


Principles of Agile Methodology:

The principles of Agile Methodology(AM) which are reflected in the Agile Manifesto also are[Martin,2002]:

*      Customer satisfaction by rapid, continuous delivery of useful software

*      Working software is delivered frequently (weeks rather than months)

*      Working software is the principal measure of progress.

*      Even late changes in requirements are welcomed.

*      Close, daily, cooperation between business people and developers

*      Face-to-face conversation is the best form of communication.

*      Projects are built around motivated individuals, who should be trusted

*      Continuous attention to technical excellence and good design.

*      Simplicity

*      Self-organizing teams

*      Regular adaptation to changing circumstances

Although agile methods differ in their practices, they share a number of common characteristics, including iterative development, and a focus on interaction, communication, and the reduction of resource-intensive intermediate artifacts. (Cohen et al., 2004) The suitability of agile methods in general can be examined from multiple perspectives. From a product perspective, agile methods are more suitable when requirements are emergent and rapidly changing; they are less suitable for systems that have high criticality, reliability and safety requirements, although there is no complete consensus on this point (Cohen et al., 2004). From an organizational perspective, the suitability can be assessed by examining three key dimensions of an organization: culture, people, and communication. In relation to these areas a number of key success factors have been identified (Cohen et al., 2004):

*      The culture of the organization must be supportive of negotiation

*      People must be trusted

*      Fewer but more competent people

*      Organizations must live with the decisions developers make

*      Organizations need to have an environment that facilitates rapid communication between team members


Agile Analysis

Most people have the perception that the deliverable from the “analysis phase” is a set of “analysis” documents and artifacts. This perception is a result of waterfall practices. For Waterfall, the deliverable is an analysis document. Waterfall methodologies believe that the status of a project can be determined from these interim deliverables. The main reason is that they are tangible and can be measured by “thud factor” and the complexity of their contents. The analysis documents do not show what is unknown about the project, that is, the true risks associated with the project. The analysis documents also state the requirements as absolute that makes them difficult to challenge by the development team. Users place undue confidence in the documents because so much effort has been placed in them. Business Analysts in Waterfall methodologies invest significant effort in the documents because they are the visible means by which they will be judged. Business users, project managers and business analysts all focus on the documentation which causes a reinforcing spiral. Huge amounts of effort are placed in making sure the last T is crossed and I is dotted. None of this effort makes its way into the final software. The end result is that business analysts spend a majority of their time on creating documentation rather than performing analysis, that is, learning about the problem[Matts,2003].

Agilists see the Analyst role as creating documentation. This is because Waterfall Business Analysts spend the majority of their time creating documentation. They do not see real value activity that is learning about the problem. Agile analysis is highly iterative and incremental process where developers and project stakeholders actively work together to understand the domain, to identify what needs to be built, to estimate that functionality, to prioritize the functionality, and in the process optionally producing artifacts that are just barely good enough. What agile analysis isn’t is:

*      It isn’t a phase of a project

*      It isn’t a task on a project schedule

*      It isn’t a means unto itself [Ambler, 2006c] 

What is agile analysis?   An agile analysis effort exhibit the following traits:

  1. Agile analysis should be communication rich.  Agile developers prefer warm communication techniques such as face-to-face discussion and video conferencing over cold techniques such as documentation and email. Agile developers prefer to work as closely as possible to their project stakeholders, following AM’s active stakeholder participation practice wherever possible.
  2. Agile analysis is highly iterative.  Analysis and design activities both rely on each other: estimating is part of analysis yet that relies on some design being performed to identify how something could be implemented and your design efforts rely on sufficient analysis being performed to define what needs to be built.  Hence analysis is iterative. 
  3. Agile analysis is incremental. Agile analysis is incremental, that you don’t need to build systems all in one go.  This philosophy supports the incremental approach favored by common agile software processes where the work is broken done into small, achievable “chunks” of functionality.  These chunks should be implementable within a short period of time, often as little as hours or days.
  4. Agile analysis explores and illuminates the problem space.  Your primary goal is to identify and understand what your project stakeholders need of your system.  Furthermore, this information needs to be communicated to everyone involved with the project, including both developers and stakeholders.  This promotes understanding of, and agreement with, the overall vision of your project.  
  5. Agile analysis includes estimation and prioritization of requirements.  It is during estimation and prioritization of requirements where software development becomes “real” for project stakeholders.  It is very easy to say that you want something but much hard to agree to a price for it, let alone to trade it off for something that is immediately more important to you.  
  6. Agile analysis results in artifacts that are just good enough.  If any artifacts are created at all as the result of the agile analysis (by following the AM practice discard temporary models after all) they should be either agile models or agile documents.  Such artifacts are typically far from perfect, they just barely fulfill their purpose and no more[Ambler,2004d].

The agile way of thinking breaks both the temporal constraint, and the structural coupling of analysis. In an agile project the analysis is not done all up front, nor is it directly map-able to the internal structure of the software[Agarwal et al 2000].

In an agile project, analysis is performed through collaboration between the business stakeholders (possibly represented by business analysts), and the developers. Together they identify features that the system will be required to perform. Features are broken down into small tasks that can be completed in a month or less. The developers estimate these tasks based upon past history in order to establish their cost. Then, the stakeholders decide the priority of the tasks by weighing their cost against their importance to the business. This priority then sets the order in which the tasks will be developed.

Clearly, in order to establish tasks that are less than a month in length, and then estimate those tasks, a considerable amount of design must be performed. This includes at least a rough understanding of the datasets, data transformations, and user interfaces that the application must deal with. Thus, completion of analysis depends upon design.

At the same time a significant amount of business analysis must be performed to understand what the features and tasks must be before they can be estimated. Thus, design depends upon analysis. This mutual dependence of analysis and design completely breaks the temporal constraint. Neither can be done without the other.

On the other hand, the design required to break the system into small tasks, and estimate those tasks does not necessarily imply anything about the internal structure of the software. It need not identify classes, relationships, and methods. Rather those tasks, and their estimates, describe external behaviors that are visible and demonstrable to the stakeholders. The temporal constraint is further weakened because the system can be designed, analyzed, and implemented concurrently. It is not necessary for all the features to be estimated and broken down into tasks before implementation begins. Indeed, the stakeholders could choose a few of the most important features. The team could break them into tasks, estimate them, prioritize them, and choose a month’s worth of the highest priority tasks to implement. Indeed, in an agile project they repeat this activity[Ambler,2002b].


Steps of Agile System Analysis Process

While software system analysis is a complex and hard activity, people use it many years, so there should be some patterns and guides. In fact the process can be described with just several steps. All of them are important and in general could not be skipped[Dubakov, 2006].

1. Identify System Users

This is the most important question. If you miss with users, you will build the wrong solution. All further analyses will relay on defined user roles, so be very careful with this first step. Typical questions:

*      Who will use the system?

2. Define Main Users Goals

Each user in the system has specific goals. One user role will use system not very frequently to solve just a few problems, while another user role will use system about 2 hours per day and resolve many complex problems. Why user will use this system? What problems will it solve? Typical questions:

*      What I (as a user ___) want to achieve with help of the system?

3. Define System Usage Patterns

Each user has common behavioral patterns. For example, Manager comes at work and start checking yesterday results. Or Frequent Flyer wants to optimize travel expenses for the next month, or sales person having a call with existing unhappy customer. Or Resource Manager handles requests on additional developers for 3 projects simultaneously. All these are typical usage patterns. This is the best starting point for functional solution. You clearly see the real problems, you understand them well, you have all you need to be creative and invent simple, effective and elegant solution. Typical questions:

*      What are the typical user behaviors (daily, specific situations, etc.)?

4. Invent Functional Solution to Meet Users Goals and Usage Patterns

This is just a logical continuation of previous step, but maybe the most complex step. Here you think how to solve exact problem, discuss the solution, jump to steps 5-6, refine the solution, write down it and move to the next usage pattern. Typical questions:

*      What is the best way to satisfy usage pattern?

5. Define Main Navigation Paths

This and next steps usually performed together with step 4. Usually it is hard to invent great solution without tracking user paths and sketching some UI areas. In fact it is better to stay off UI as far as you can. In discussions replace all phrases like "Then User clicks Leads link in the top menu and sees leads list" with "Then User sees leads list". Concentrate on information user need on each step, not on links and clicks. Good navigation path looks like this:


  1. Quickly add new lead into the system
  2. See leads list
  3. Find leads added yesterday
  4. See additional details for each yesterday lead

There is no UI in the list above, just information. Typical questions:

*      What functional areas/action should user execute to complete usage pattern?

*      How many areas required to complete user goal in specific pattern?

6. Create UI Mockups

UI mockups are great to have a quick look at possible users/system interaction. Dashboard sketches are perfect. Forget about cool tools like Visio, Dreamweaver or any other UI prototyping tool. Dashboard sketches are the fastest, easiest and exciting thing to work with. You will group around dashboard with markers in hands and discuss where to place system settings link with great enthusiasm. Everyone can draw with a marker, but it is just not possible with computer. With marker in hand everyone feels that s/he can improve this UI and bring in cool ideas. Here is the place where team spirit rises! Draw UI sketch, make a photo on digital camera and put all photos in a single shared space.

7. Polish UI Elements

There is always a possibility to make things better, to improve something here and there. It is a good attitude. You should think about UI details of most important features that will be implemented right after the project start. But be careful, don't spend much time on UI perfection, likely it will change during development anyway. And never polish UI for features that will be implemented in 3+ months ahead of current date, with great possibility it will be a waste of time. Typical questions:

*      Can we improve UI to reduce clicks, provide better visibility, etc?

After all the steps above you will end up with solid understanding of future system, with the most important artifacts in hands and clear starting point.


Artifacts from Agile Analysis:

The artifacts created taking an agile approach to analysis are different than the ones created as the result of traditional analysis in a way.  They are in fact the same types of artifacts, a use case diagram is a use case diagram after all, but the way in which they are created are different.  The artifacts are created following the principles and practices of AM; they are just barely good enough and are often discarded so as to travel light[Ambler, 2002a].  

Table 1 lists common artifacts used during analysis modeling and suggests a simple tool with which you could create such an artifact

Table 1.  Candidate artifacts for analysis modeling[Ambler,19].


Simple Tool


Activity Diagram


UML activity diagrams are used during analysis modeling to explore the logic of a usage scenario (see below), system use case, or the flow of logic of a business process.  In many ways activity diagrams are the object-oriented equivalent of flow charts and data-flow diagrams (DFDs).

Class Diagram


Class diagrams show the classes of the system, their inter-relationships (including inheritance, aggregation, and association), and the operations and attributes of the classes.  During analysis you can use class diagrams to represent your conceptual model which depict your detailed understanding of the problem space for your system.

Constraint definition

Index card

A constraint is a restriction on the degree of freedom you have in providing a solution.  Constraints are effectively global requirements for your project.

CRC model

Index cards

A Class Responsibility Collaborator (CRC) model is a collection of standard index cards, each of which have been divided into three sections, indicating the name of the class, the responsibilities of the class, and the collaborators of the class.  Like class diagrams, CRC models are used during analysis modeling for conceptual modeling.

Data flow diagram (DFD)


A data-flow diagram (DFD) shows the movement of data within a system between processes, entities, and data stores.  When analysis modeling a DFD can be used to model the existing and/or proposed business processes that your system will support.

Entity/Relationship (E/R)  diagram (data diagram)


E/R diagrams show the main entities, their data attributes, and the relationships between those entities.  Like class diagrams E/R diagrams can be used for conceptual modeling, in many ways E/R diagrams can be thought of as a subset of class diagrams.

Flow chart


Flow charts are used in a similar manner to activity diagrams.

Robustness diagrams


Robustness diagrams can be used to analyze usage scenarios to identify candidate classes and major user interface elements (screens, reports, ...).

Sequence diagram


Sequence diagrams are used to model the logic of usage scenarios.  Sequence diagrams model the flow of logic within your system in a visual manner, enabling you to both explore and validate your logic.

State chart diagram


State chart diagrams depict the various states, and the transitions between those states, that an entity exhibits.  During analysis modeling state chart diagrams are used to explore the lifecycle of an entity that exhibits complex behavior.

System use case


A use case is a sequence of actions that provide a measurable value to an actor.  A system use case includes high-level implementation decisions in it.  For example, a system use case will refer to specific user interface components – such as screens, HTML pages, or reports.  System use cases will also reflect fundamental architectural decisions, such as the use of ATMs versus cell phones to access your bank account.  

UI prototype


A user interface (UI) prototype models the user interface of your system.  As a part of analysis modeling it enables you to explore the problem space that your system addresses in a manner that your project stakeholders understand.  Remember, the user interface is the system to most people. 

Usage scenario

Index card

A usage scenario is exactly what its name indicates – the description of a potential way that your system is used. 

Use case diagram


The use-case diagram depicts a collection of use cases, actors, their associations, and optionally a system boundary box.  When analysis modeling a use case diagram can be used to depict the business functionality, at a high-level, that your system will support.  It can also be used to depict the scope of the various releases of your system via the use of color or system boundary boxes.



Towards Agile Analysts

Fundamentally the activities performed by traditional business software analysts (BSAs) are varied, but a crucial goal was always to improve the communication between developers and project stakeholders.  In many “traditional” organizations that meant that BSAs formed a bridge between the two groups, a definite improvement in many situations, although at the same time erected barriers.  Now is the time to take the next step, to become more agile and have BSAs become the communication mentors/coaches on project teams[Ambler, 2002a]. 

Agile methodology (AM) suggests that development teams follows the practice ‘active stakeholder participation’ that they work closely with their project stakeholders.  The goal of this practice is to reduce the feedback loop and thereby improve communication.  However, the way that you work with your stakeholders will in part be determined by your team’s organization.  An interesting implication is that the role that a BSA takes on changes dramatically based on the communication options available to your team.  There are three categories of team organization that need to be considered with respect to how an “Agile BSA” will act on a project team[Ambler, 2006]:

*      One room – Developers and Stakeholders are Co-Located

*      Over the wall – Single Location But Not Co-Located

*      Across the network – Dispersed/Distributed Development


Agile Requirements:

Agile software development teams embrace change, accepting the idea that requirements will evolve throughout a project.  Agilists understand that because requirements evolve over time that any early investment in detailed documentation will only be wasted.  Instead agilists will do just enough initial modeling to identify their project scope and develop a high-level schedule and estimate.During development they will model storm in a just-in-time manner to explore each requirement in the necessary detail[Fernandez, 2001].

Because requirements change frequently you need a streamlined, flexible approach to requirements change management.  Agilists want to develop software which is both high-quality and high-value, and the easiest way to develop high-value software is to implement the highest priority requirements first.  Agilists strive to truly manage change, not to prevent it, enabling them to maximize stakeholder ROI.   Figure 1 overviews the agile approach to managing requirements, reflecting both Extreme Programming (XP)’s planning game and the Scrum methodology.  The software development team has a stack of prioritized and estimated requirements which needs to be implemented – XPers will literally have a stack of user stories written on index cards.   The team takes the highest priority requirements from the top of the stack which they believe they can implement within the current iteration.  Scrum suggests that one should freeze the requirements for the current iteration to provide a level of stability for the developers.  If this is done then any change to a requirement being currently implementing should be treated as just another new requirement[Cockburn 2002].   

Why Requirements Change

People change their minds for many reasons, and do so on a regular basis.  This happens because[Miller, 2001]:

  1. They missed a requirement.  A stakeholder will be working with an existing system and realize that it's missing a feature.
  2. They identified a defect.  A bug, or more importantly the need to address the bug, should also be considered a requirement.
  3. They realize they didn't understand their actual need.  It's common to show a stakeholder your working system to date only to have them realize that what they asked for really isn't what they want after all.  This is one reason why active stakeholder participation and short iterations are important to your success.
  4. Politics.  The political landscape within your organization is likely dynamic (yes, I'm being polite).  When the balance of political power shifts amongst your stakeholders, and it always does, so do their priorities.  These changing political priorities will often motivate changes to requirements.
  5. The marketplace changes.  Perhaps a competitor will release a new product which implements features that your product doesn't. 
  6. Legislation changes.  Perhaps new legislation requires new features, or changes to existing features, in your software. 

The bottom line is that if the requirements are frozen early in the lifecycle, then one is pretty much guaranteed that the system built will not be what people need, instead it would be what the users wanted initially.  That's not a great strategy for success.


Agile Requirements Best Practices[Ambler, 2005 e]:

   1.   Stakeholders actively participate

   2. Adopt inclusive models

   3. Take a breadth-first approach

   4. Model storm details just in time (JIT)

   5. Your goal is to implement requirements, not document them

   6. Create platform independent requirements to a point

   7. Smaller is better

   8. Question traceability

   9. Explain the techniques

  10. Adopt stakeholder terminology

  11. Keep it fun

  12. Obtain management support

  13. Turn stakeholders into developers

  14. Treat requirements like a prioritized stack


Agile Risks, Agile Rewards[Smith, 2005]:

In managing project risks on various projects, some common risks tend to occur in most of the projects in the following areas.

Product Definition

*      Product managers lack experience in creating user stories.

*      User interface requirements currently unclear.

*      Regional markets not yet decided.


*      Technology issues such as remote communication, data access and component frameworks.

*      Product managers located remotely.

*      Some team members not assigned full time.

*      Communication issues due to language barriers.


*      Variations in applying the unit test framework.

*      Providing functionality competes with delivering high quality.


*      Inadequate modeling tool for applying agile software engineering practices, such as test-driven development.

*      Software production unstable due to differences between developer-build and production-build environments.

*      Test hardware not available in time.

Sales and Distribution

*      Launch programs not yet defined.

*      Sales staff training measures open.

*      User and service documentation may not be translated into all target languages in time.


10 Tips for Successful Agile Analysis[Ambler, 2004d].

1. Active stakeholder participation is crucial.
You need to work together closely with your stakeholders to explore the business domain in detail. They must be available to supply information, to model with you, to provide feedback, and to make timely decisions.

2. Agile software development is an evolutionary process.
When you're analysis modeling on an agile project, you'll typically focus on a very small subset of the requirements at a time. For example, on an XP project, you and your programming pair may work with a project stakeholder to analyze a single user story, one of hundreds, and then move on to design and implement it. This analysis effort often takes several minutes, depending on the nature of the user story, as does the design effort. Then you'll spend several hours or days implementing the requirement only to start again with a new user story. Other agile approaches, such as Feature-Driven Development ( ), may invest a bit more time in analysis and design but they still work in a similar, evolutionary manner.

3. Analysis isn't a phase.
Analysis is something you'll do on a daily basis as an agile developer, because you're working in an evolutionary manner. It involves working with your stakeholders, as well as your fellow developers, to understand the problem domain whenever you need to. Analysis could be something as simple as asking a stakeholder, "What did you mean by this?", or as complex as drawing several diagrams to explore an aspect of what you're building. It's a much more informal than formal process, requiring open and honest communication.

4. Multiple models.
Effective developers realize that each type of model has its strengths and weaknesses; therefore they need to apply the right model(s) for the job at hand. Because software development is complex, you quickly realize that you need to know about a wide range of models in order to be effective.

5. You typically need only a subset of the models.
Although there are many modeling techniques available to you, the fact is that any given project team will require only a subset. Think of it like this: In your toolbox at home, you have a wide array of screwdrivers, wrenches, pliers and so on. For any given repair job, you'll use only a few of those tools -- different jobs, different tools. You never need all of your tools at once, but over time you'll use all of them in a variety of manners.

6. Models evolve over time.
You may start with an essential use case but quickly decide to evolve it into several system use cases. Or you may decide to develop a collection of Object-Role Model (ORM) diagrams on a whiteboard as input into your design-level UML class diagram, which in turn will evolve into Java source code. It's quite common to discard the interim artifacts and keep only the final products -- remember Agile Modeling (AM)'s Travel Light principle.

7. Analysis models need to be just barely good enough.
Keep your models as simple and lightweight as possible. Focus on understanding, not documentation. Use the simplest, most inclusive tools available. Recognize that your models don't need to be perfect.

8. Each model can be used for a variety of purposes.
Data flow diagrams can be used as both an analysis technique to explore your existing business processes as well as a design technique to redefine them. Similarly, Class Responsibility Collaborator models can be used for both analysis and design and use cases for requirements, analysis and sometimes even design.

9. Modeling lines are often blurred.
The traditional concept of development phases -- requirements, analysis, designs, coding, testing and deployment -- has left many people with the idea that we need to distinguish among various types of modeling. Yet when a stakeholder describes a requirement, such as the need to capture a student's home address, we'll often work through the phases within seconds of each other. We'll start thinking about what the user interface should look like, the various data elements that will be captured, the need for an Address class, the possibility of applying the Contact Point pattern, the need for an Address table in the database, and how to code it all in Java, moving from requirements through analysis through design to code without stopping to create a complete requirements model or a complete analysis model, and so on. While it's important to ask questions such as what do you need (requirements), what does that mean (analysis), and how are we going to build it (design), often we'll be doing so in an iterative, not a serial manner.

10. Use your stakeholders' terminology.
Don't force artificial, technical jargon onto your project stakeholders. They're the ones the system is being built for; therefore, you should use their terminology to model the system.


The nature of analysis has changed.  Several decades ago analysis was seen as a transformational process within a serial project lifecycle.  With the rising popularity of object-orientation in the 1980s and 1990s analysis was soon seen as part of an iterative and incremental process, and in the new millennia the nature of analysis is transforming once again.  Today analysis is better envisioned as a highly collaborative, iterative, and incremental endeavor involving both developers and stakeholders.  The evolution of the analysis process necessitates an evolution in the way that business system analysts (BSAs) work, and in many situations this role arguably disappears in favor of developers who are generalizing specialists.



  1. Ambler, Scot W .2006 c. Agile Analysis.. Ambysoft. Inc.


  1. Ambler Scott. 2004 d, May, 06. The Agile Analysis Top 10. Dr Dobbs Portal. Architecture and Design.


  1. Ambler Scott. 2005 e, September. Agile Requirements Best Practices.




  1. Fowler, Martin.2002 The New Methodology.


  1. Matts, Chris. 2003.Why Agilists Think Up-Front Analysis is inherently un-Agile.


  1. Dubakov, Michael. 2006, June 5. 7 Steps of Agile System Analysis Process. TargetProcess.


  1. Martin, Robert C. 2002, Feb 27. On Analysis.


  1. Fernandez, Edurado B. Building Complex object Oriented Systems with Patterns and XP. 2001, Aug.


  1. Smith, Preston G.;Pichler, Roman. 2005, April. Agile Risks and Awards.


  1. Dave, Thomas. 2005, May, June. Agile Programming: Design to Accommodate Change. IEEE Software. Vol. 22, No. 3


  1. Highsmith J and Cockburn A.2001. Agile Software Development: The Business of Innovation. Computer Vol 34, Iss. 9. 120-122.


  1. Cockburn, A. 2002. Agile Software Development. Boston. Addison-Wesley


  1. Miller,  D and Lee. J. 2001. The People Make the Process: Commitment to Employees, Decision Making, and Performance. Journal of Management. Vol. 27. 163-189.


  1. Favaro, J. 2002. Managing Requirements for Business Value.  IEEE Software. Vol 19. 15-17


  1. Ambler, S. W. 2002a. Agile Modeling: Effective Practices for Extreme Programming and the Unified Process. New York. John Wiley and Sons, Inc.


  1. Ambler S. W. 2002b. Lessons in Agility from Internet Based Development. IEEE Software. Vol. 19, Iss. 2. 66-73


  1. Ambler, Scot W. Rethinking the Role of Business Analysts.


  1. Ambler, S W. Artifacts of Agile Development.


  1. Cohen, D., Lindvall, M., & Costa, P. 2004. An introduction to agile methods. In Advances in Computers (pp. 1-66). New York: Elsevier Science.


  1. Agarwal, R and Prasad, J.2000. A field study of the adoption of software process innovation by information systems professionals. IEEE Transactions on Engineering Management. Vol. 47, Iss. 3. 295-308


  1. Anonymous. What is Agile Development.


  1. Abrahhamson, Pekka et al. 2002. Agile Software Development Methods: Review and Analysis. VTT Publications.