Show all posts
9 years ago

7 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. There are a lot of books, some of them very good, most of them almost useless for agile developers, since based on solid Requirements Definition Phase with The Spec in the end.

In fact the process can be described with just several steps. All of them are important and in general could not be skipped.

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:

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:

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:

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:

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:

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:

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. And yes, you may start development and plan the first iteration!

  • Anonymous

    3. Define System Usage Oatterns???
    it is PATTERNS,right?

  • Michael Dubakov

    Yep! Already fixed, thanks.
    Authors often blind you know.

  • bizrules

    6. UI Mockups?

    This is where so many development projects go off the rails. Mocking up UI’s without having any idea of who your various users are leads to horrible UI’s. It’s why big companies have version 6 of the same damn system.

    There are some ways of working around not having access to users. See this post on Breaking the First Commandment.

  • devcon

    I think simulation or prototyping helps. There are now some useful tools for this (like Simunication and iRise) that lead to tight requirements definition so avoid some of these problems.

  • Anonymous

    if i have fully subsystems and all are integrated with each other how i will integrate them, not simply sketching line these are connected how i will integrate or represent integration on inner side like subsystem-1 this link connected with subsystem-2 and subsymtem-2 this link connected with subsystem-1 ?

  • Anonymous

    What does this sentence mean?

    For example, Manager comes at work and start checking yesterday results.

    Maybe it should read:
    For example, Manager comes
    to x
    work and
    starts x
    yesterdays x

  • Anonymous

    This is what people today don’t seem to understand: if sentence structure and grammar are so bad a reader cannot understand the point, the reader cannot trust that the information presented is accurate.

  • Prometheus1923

    If you look to sentence structure and grammar to determine trust and validity then you are a perfect mark for every con artist in the world. Many, if not the majority, of the most brilliant minds in history had horrible grammar/sentence structure. Look at the raw journals/letters of Einstein, Heidegger, Turing, Oppenheimer, etc (good blogging, at least to me, resembles journaling much more than anything like a pre-print final draft in paper based publishing). Look at the best, or most famous, con-artists in the world and they were meticulous with things like grammar. Check out Madoff, Lustig, Weil, Abagnale.

    When bouncing throughout the world of ideas you should be focusing on the ideas themselves and not proper English grammar (if it is even your first language). In that realm only people with something to hide or something to prove worry about proper linguistic formalities.

Request a demo
Our product specialists will show you the beauty and power of Targetprocess 3 and help you to customize it for your process and business requirements
Request a demo