As a functional analyst for web development projects, I have seen my role evolve over time. Coming from school and working on a first job, you tend to follow the guidelines you have been taught or those that are expected by your employer. A few years in, I have developed my own style due to changes in techniques and the release of tools to support those techniques.
I have never been a big fan of enormous documents stuffed with descriptions, flowcharts, UML boxes, etc., to describe a piece of software or development process. The static nature of these documents is the complete opposite of the lively dynamics of the software development projects in which I have been involved.
Analysis documents are usually a screenshot of the moment in time when the initial idea was conceived. Once the development of a project starts, these documents are usually put aside, never to see the light of day again. I have yet to see the first project in which the analysis document contains all the information of what was actually developed.
However, not all analysis techniques should be thrown overboard. Like all good things in life I merely suggest using them wisely and adapting them to the situation at hand, rather than just following conventions and guidelines because they are available. Surely there are projects that require a lot of documentation but in the agile web development projects in which I have been involved, this was not the case. I have tried to capture my way of working into a general process that fits different situations.
- Documenting the concept and the high level features
It’s always nice to have something on paper to which you can refer when necessary. In this document I only include a general description of the purpose of the application and a listing of the high level features. Avoid going into too much detail here since that might limit your open-mindedness later on.
- Create a flowchart/diagram
Depending on the nature of your project it’s always handy to make a flowchart or diagram. The purpose is to have something really visual to put on the table when you need some clarity, and something you can talk through with the client.
Since you’ve saved loads of time by not creating needless documentation, that time can be spent on creating a prototype and finetuning it. This part of the process is ongoing during the development so I’ll go into some detail here..
The sooner you get things visual through prototyping, the better. Several advantages will present themselves:
- There is something to talk about: even though it’s not a working application yet, you do have something visual to show. You will notice that for most people this helps a great deal when thinking about new features, improvements etc… you also get away from the abstract idea that was conceived and you start bringing things to life.
- Reality check: depending on the nature of your project this prototype already is a reality check. Since you are really getting a “feel” for what you want to accomplish, it’s also easier to see obstacles that you might run into or opportunities that you hadn’t thought of yet.
- Specific: whereas documents mostly remain high level, you can be really specific with prototypes. You’ll have to discuss the level of detail that you want to include, but in any case it makes things more tangible than a printed document lying on your table. Smashing magazine has an article in which they describe the levels of fidelity with which you can design a prototype. Depending on your particular needs you can choose one and with the right setup you can easily evolve into a higher level once your project is off and running.
- Speed up development: Once a first version which represents a first release of what needs to be developed is finished, you can start working simultaneously with the developers. New features can be prototyped/reality checked first before actually investing in development.
Of course there are also some downsides to prototyping. Depending on the level of “fidelity” that you implement in a prototype you have to guard people from not getting lost in details. Since you are making things visual and specific it’s very easy to start talking about things such as the colors or the placement of buttons.
When you are working iteratively with your client it’s important to guide this process carefully. Make sure that you keep your client on track and that you have a clear focus for discussing the prototype in each phase of your project.
When the process is guided carefully, prototyping can be a wonderful thing which is much easier to keep alive than a document. To me this means that the term “Functional Analyst” does not really apply anymore in agile development environments. Interview techniques and other classic requirements that this person had to possess are still useful but there are other attributes that have a much bigger impact on your role as an analyst.
- Interpersonal skills that allow you to build a relationship of trust with your client are very important in such an agile process.
- It’s also very important that you have an open mind and are always looking for solutions rather than problems.
- Finally a high level of creativity and feeling for what you are doing is more important than anything else. You’re not just writing down facts but you’re already processing them into a proposal for a solution.
The classic functional analyst that writes bulky documents can only survive in really formal environments where guidelines and rules outweigh productivity. Surely there are still places where this is needed and people willing to do this, I’m just glad it’s not me …
I’m not the right person to give advice on which prototyping or wireframing tool to use since I fell in love with Axure from the first time I used it. I have tested some other ones but given my prejudice I don’t think I ever gave them a real chance. Having somewhat of a technical background does help in the logical thinking process when prototyping for a software development process but I don’t feel that it’s as important as the attributes described above.
After all of this I’m still not sure what title I should give myself so I’ll stick with analyst. All I am saying is: give prototyping a chance!