When you contact a digital agency like WebstanZ, you're doing so because you have a specific requirement, a specific project to implement. We listen to you first, to understand your expectations and any potential constraints. An elicitation workshop is usually organized.
Elicitation is a process whose objective is to gather the information needed to propose, design and implement an optimal solution.
These initial discussions lead to the writing of a functional description, setting out the expected functionalities in a document. At this stage, the various requirements are listed, as well as what is “in scope” and what is “out of scope”, and an initial approach in terms of User eXperience (UX), User Interface (UI) and accessibility. A precise quotation can then be provided.
Next, we need to describe what the system is supposed to do: identify the stakeholders (users), define the workflows (processes) and the interactions between all these entities. This is where functional analysis comes in.
Functional Analysis?
Functional analysis is a structuring approach for the team in charge of creating or improving a product. The aim is to identify the customer's needs, in order to determine the product's functions, before looking for the technical and technological solutions to be implemented. (...)
What for?
Besides the obvious benefits of formalizing features, a functional analysis ensures the customer that WebstanZ has fully understood the project and its ins and outs. This increases trust, which is essential for a successful collaboration.
The idea behind functional analysis is to build a solid system, avoiding last-minute surprises, with a view to overall product quality.
When does it come in?
Depending on the project's level of definition, the functional analysis may begin before the quotation is sent, in order to flesh out and refine the functional description, or it may begin after the quotation has been accepted by the customer.
WebstanZ employs a hybrid, pragmatic project management methodology, with an initial waterfall phase, before moving on to a second phase in iterative mode, based on an agile approach and Scrum principles.
While functional analysis is a natural part of the waterfall phase at the start of the project, it is refined during the iterative development stages (sprints), through discovery tasks.
During project maintenance, once the project is in production, a functional analysis may still prove useful and necessary to study certain ambitious change requests, in a spirit of coherence, added value and relevance.
Use Use Cases to model flows
A use case is a concept used in software development, product design and other contexts to describe how a system can be used to achieve specific goals or tasks. It describes the interactions between users or stakeholders and the system to deliver a specific result.
At WebstanZ, we use FigJam to map information workflows. FigJam is an extension of Figma, a collaborative tool we use to discuss UX/UI issues in a very visual way.
The image below shows a typical use case for an e-commerce website. From the online catalog, the visitor chooses to add an item to his shopping cart (extend means that the task is triggered by a user action). This has for effect to ask Drupal (in the back office) to record the result of the action in the database. The front end (user-side application logic) then displays a link to the modified shopping cart. The Drupal and front-end actions are triggered automatically, following the first interaction (include). The terms extend and include are taken from UML standardization.
Writing User Stories that meet user needs
A user story is a general, informal explanation of software functionality written from the point of view of the end user. Its purpose is to explain how a software feature will bring value to the customer.
To take the example of adding to the shopping cart, we could write the User Story “Visitor - Adds an item to his shopping cart” as follows:
As a visitor
I'd like to add an item to my shopping cart
so that I can order it
The formulation “As/I wish-would like/For-So that” is typical of the concept of a User Story.
“As...” identifies the actor of the action (the persona)
“I wish/I'd like...” describes the desired functionality
“In order to/So that...” specifies the goal, the objective that creates value from the end-user's point of view.
A list of successive steps can be specified.
- The user reaches the product catalog.
- He clicks on an add-to-cart icon in front of a product.
- The item is added to the shopping cart.
Acceptance criteria are used to test the functionality once it has been implemented, to ensure that it corresponds to the need identified at the outset.
Prioritize tasks using MoSCoW method
The MoSCoW method is a technique for prioritizing needs or requirements for project management assistance and software development. (...)
MoSCoW is an acronym that combines the following terms:
Must have: the feature is essential to the system and must be implemented.
Should have: the feature is interesting and should be implemented.
Could have: “nice to have” feature, not necessary but a plus.
Won't have: feature not to be implemented for the time being.
Priorities are used to communicate to developers which features should be implemented in order of importance, knowing that they may be reviewed over time.
Conclusion
We have seen that functional analysis allows us to describe the features of a web project, to ensure improvement and change by providing the company with digital tools that meet its business needs. Different formats and phrasing ensure that the agency fully understands the customer's needs. Development can then proceed on a solid basis, to produce quality work and establish a relationship of trust with the customer, avoiding surprises along the way.
