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:

  • 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:

User:

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

目次

カテゴリ

タグ