Functional Analyst: the “playmaker” of your agile web team

The web teams

When looking at the team for a standard web project, we usually find the following composition: the customer (business and IT), a UX & design team responsible for concept and graphic design, a hosting partner and the implementation team.

The AmeXio implementation team typically consists of the following roles: Project manager, Front End developer(s), Functional analyst, Technical lead, Architect, Infrastructure specialist and WCMS Developer(s). Each role does not necessarily have to be filled in by a different person. In smaller projects, the architect or infrastructural role can also be filled in by the technical lead.

When looking at the role of the functional analyst, however, we find that this role is filled in by a separate person in most cases. Does this mean that this task is too specific to be done by one of the more technical profiles? Not at all. But in practice we find that it works better if there is a specific person who takes the lead for the typical work of a functional analyst. This does not mean however that other team members are not involved in the analysis process. The analyst is in the lead for the analysis track and will also involve other team members in the process of shaping and challenging the functional solution. It is important to keep everybody informed about the product that is created and is beneficial for the quality.

Let’s dive a bit deeper into the role of the functional analyst in agile web project management.

1. DISCUSS THE FUNCTIONAL ASPECTS OF THE REQUIRED PRODUCT WITH THE CUSTOMER, UX & DESIGN TEAM AND DEFINE THE FUNCTIONAL REQUIREMENTS

Before the graphic, functional and technical design of a website can start, a site concept is required. This concept is conceived by the customer, together with a UX & design team. It usually includes an information architecture, a style guide, a functional inventory, wireframes and prototypes to illustrate functional behavior and navigation flows.

It is important that the implementation team is involved as soon as possible, because in this phase, the basics for all the future functionalities are defined. Typically, the functional analyst is involved here. The goal of this involvement is to get a more thorough view on the functional requirements behind the concept and to inform the concept team about the possibilities and limitations of the technical platform (Web Content Management System). This is to make sure that the shaped solution can be integrated in the technical environment in a smooth and cost-efficient way. Early involvement also helps to establish a good relation between all members in the team, which is beneficial during the whole project.

2. DISCUSS NON-FUNCTIONAL REQUIREMENTS AND CONSTRAINTS WITH THE CUSTOMER

Next to the functional requirements, the functional analyst needs to detect the business related non-functional requirements . Typical examples of these are browser requirements, device requirements, language requirements and usability requirements.

Once the big picture is clear, the detailed UX design and graphical design will start. This will typically be done by the communication agency. They deliver a design and UX approach for all the different page types that can be distinguished in a website.

After the page design is ready and approved by the customer, the functional analyst can execute the functional intake of the designs. The goal of this intake is to get a clear understanding of the functionality that is implicitly included in the design and to challenge it. Challenging means checking if the functional concept is logical and consistent and if it is a match with the selected WCMS. The latter is done together with the technical lead. Feedback and suggestions for improvement will be delivered to the customer. This input helps to tune the design already in an early stage.

An important remark related to the agile project methodology is that the start of the functional intake process does not have to wait until the full website is designed . The intake of approved designs can run in parallel with the design of new functionalities provided the global concept is clear. This helps in a great way to start up the technical analysis and development earlier.

On the other hand, running the design/analysis of a certain functionality at the same time as the development of it is not a good idea. Analysis and design require always a lot of discussions and have a relatively high throughput time. This time needs to be available. A good rule of thumb is that the design and analysis of an item should run at least one, and better two sprints a head of its actual development.

3. CREATE FUNCTIONAL SPECIFICATIONS TO ESTABLISH A CLEAR AND COMMONLY SHARED DESCRIPTION OF THE REQUIRED FUNCTIONAL BEHAVIOR

On completion of the design, the functional specifications for the frontend aspects of the delivered page template and page components, will be defined by the functional analyst. The frontend specifications focus on the aspects of the solution that can be seen and used by the end user (visitor) of the website. A typical example of a page template is a homepage, or an article page. A component is for example the main navigation or a video block that is displayed on a page.

Next to the required frontend behavior, the functional specifications for the Web Content Management System will be created. The goal of these specifications is to describe how the identified templates and components will be managed by the authors in the system. This is an important step that is sometimes forgotten. It is not only necessary to create a website that works great for the end user. It is also extremely important to create a great tool for the authors of the website. The design of the backend experience is usually the task of the functional analyst, in cooperation with the technical lead and the customer.

4. MAKE SURE THAT THE FUNCTIONAL ACCEPTATION CRITERIA ARE CLEAR

An important rule to keep in mind is that documentation should be delivered in the right amount, for the right audience, in the right time and place. Since every project is different, the approach regarding the documentation can also be different in each project. The most important thing is that you find a way to create useful documentation that benefits in the creation of the product you work on.

What is important to be noted here is that, besides written specifications, there is also the oral communication about the specifications. In an agile approach, work is organized in short periods of work (sprints). Before every sprint, the work that needs to be realized during the sprint is defined and assigned to a developer. Before the actual development starts, a global and individual briefing is organized to discuss the required functionality and the technical approach. In this process the functional analyst is responsible to inform the team about the available specifications and to further clear out the details, if required.

5. ASSIST DURING THE DEMOS

During the development process, the developers also need to communicate with the functional analyst and the customer to get additional inputs on certain topics. After each sprint, the working functionality is presented to and discussed with the customer, during the demo. Continuous communication about the functionality is extremely important, to deliver an optimal result. The analyst needs to make sure that this process is carried out.

6. EXECUTE THE FUNCTIONAL TESTING BASED ON THE SPECIFICATIONS AND ACCEPTATION CRITERIA

Based on the specifications, acceptation criteria are defined by the functional analyst, together with the customer. This gives a clear lead to developers and testers to evaluate if a certain piece of functionality is ready or not. In most projects, the functional analyst will also execute the role of functional tester. The functional testing is next to the more technical oriented peer review and unit tests part of the internal quality process. Starting from specifications and acceptance criteria, test scenarios will be created that help to verify if the required functionality is implemented in a correct way. Since the functional analyst has a good global view on the required functionality of the product, he is also best placed to execute these tests.

7. DO THE INTAKE OF REPORTED BUGS

The acceptance criteria and test scenarios will also be used by our customer to perform the acceptance tests . As a result of these tests defects will be logged. Typically, the intake of the logged defect is also done by the functional analyst. The analyst will detect if something is a defect or not. In the case of a real defect, a ticket will be dispatched to the right developer. In other cases, the functional analyst will provide the necessary information to solve the issue by providing the required documentation.

8. DELIVER USEFUL FUNCTIONAL DOCUMENTATION IN A FORMAT THAT PROVIDES VALUE TO OUR CUSTOMER

User Documentation is created during the project by the development team. The idea behind this is that this is best done in small parts by the people who know how a certain functionality works. That’s why the documentation is created by the developers during the sprints for the functionality that is developed in that sprint. Additionally, the functional analyst will do review and editing. The goal is to have the basic user documentation ready before (acceptance) testing starts, to make sure that all testers and authors have the required information when they start testing/authoring.

9. PROVIDE FUNCTIONAL TRAINING

Together with the customer, an appropriate format will be defined, to offer a documentation resource that provides value. This documentation will also be used during the functional training sessions . During these sessions the author team is informed about the functionalities of the content management system and will get specific information about the management of all the templates and components that are available in the system.

Testing, documentation and training are organized following the sprint flow, if the organizational structure of a customer allows this. This helps to get the customer testing team up and running as soon as possible and is a great way to collect user feedback in an early stage.