Requirements Gathering (Part II) — Developing Requirements
After identifying the stakeholders and ranking them, let’s move on to action!
The most common methods for develop requirements gathering are as follows:
One-on-one interviews: You have a meeting with the stakeholder (sponsors, seniors, experts…) , you ask them questions and you ask the follow up questions to their answers. It’s a good practice in the initial phase of the analysis.
Tips: You have to prepare the interview:
> Research your interviewee(s) — ask someone, on linkedin (name, role in organization, role on project…);
> Plan the discussion — Unstructured, Structured or Semi-structured;
The most recommended method is the semi-structured because you have a plan but you let the interviewee take you in otherdirections. This way you can follow a logic without straying too far from the main subject, but you also manage to make the interview not so formal;
> Prepare your attitude: You have to be curious! You need to ask “why” and “but if..?” It is important at this stage to understand the need to plan the best solution in the future. Sometimes there is no need… Sometimes the requested functionality may not satisfy what the customer really needs. Don’t conduct an interview, have a conversation; ask open-ended questions; give them time to think, use their language (business) and not yours (technical), ask about their goals, priorities and problems, identify the people who are part of this process and ask “if we can also talk to them”. Ask “Do you want updates from me periodically?” or “How would you like me to involve you?”.
Group interviews: You meet with more than one stakeholder, ask them questions, you get lots of info and opinions all at once. Stakeholders themselves learn information from each other. There is more transparency. It’s a good practice in the middle of the analysis. You should try to bring together more than one interested party at a meeting in order to discuss ideas for the project.
Tips: > You need to ask “Who are the right people to include?”;
> You can bring someone to take notes, for instance another business analyst;
> Get feedback from stakeholders on existing report process (what works, what doesn’t work), get their ideas on best possible process;
> A brief introduction should be made, explaining a background of what will happen; the goal of the meeting, the structure;
> What we hope to learn and receive from them. Some doubts;
> Always confirm answers and ideas to validate that we are understanding things. Ask if anyone has any questions, if they have any other topic that hasn’t been discussed yet.
Modeling: Business Requirements come in many forms, from hastily scribbled wish lists thrown over the transom to the developers, to monolithic Word documents that wade far into the technical weeds. Someone facilitating the elicitation of requirements can use process modeling to begin the discussion, and keep the business focused on the functions it needs to perform. This allows the business to concentrate on what is needed, and lets the software designers determine how those needs will be fulfilled.
The modeling is used in the business requirements (requirements inherent to the entire business involved in the project) and should contain all the details of it, including those that don’t intend to automate.
There are several ways to model business requirements, including simple workflows. The most common modeling language is BPMn (Business Process Modeling Notation) which consists of a simple notation that both people with knowledge in the business and people with technical knowledge understand. Usually this flowcharts are validated with the experts in the business.
Watch out! You will soon be able to read more about BPMn on this page!
Use case diagrams: Typically use case diagrams are constructed in the UML language. Initially it is necessary to identify the actors in question and then identify the sequence of events that the actor makes in the system.
It is important to identify scenarios to prioritize and identify system functionality, what the system should or should not do.
This requirements development method is more common for functional requirements, that is, requirements that refer to application functionalities. What should be automated and developed.
Watch out! You will soon be able to read more about use case diagrams on this page.
Prototyping: developing an illustration of a system/product/process for learning purposes. Validate questionable requirements, develop detailed requirements, identify missing requirements. Prototyping consists of creating a prototype of the features that the application must mirror. It’s not the end result, it’s not the end design! However, it is always necessary to consider design thinking and what is user friendly!
Tips: > When to prototype: When you want to elicit more requirements, when you’re stuck, when you want to validate what you have so far;
> Define your goals;
> Create the prototype (you could use a lot of tools: adobe, visual paradigm, canva, magic mockups, Mockuper…);
> Show it to stakeholders, assess what you’v learned;
> It doesn’t have to be pretty, it has to be functional.
Watch out! You will soon be able to read more about prototyping and design thinking on this page!
Other methods:
Brainstorming: Brainstorming is a method design teams use to generate ideas to solve clearly defined design problems. In controlled conditions and a free-thinking environment, teams approach a problem by such means as “How Might We” questions. They produce a vast array of ideas and draw links between them to find potential solutions.
The brainstorming generates lots of ideas all at once. We always aim for a free, open and continuous flow of ideas; Actively facilitated, creatively generates ideas.
Tips: > Coming up with user stories;
> Coming up with requirements and solutions;
> The session should be open-minded and relaxed;
> Five rules: don’t judge, don’t comment, don’t edit, don’t execute, don’t worry!
Observation: The observation technique of the work performed by the user can be done in person or through screen sharing when the work performed is not manual. It’s very important to watch the user perform the functions he intends to improve. If you want to turn a manual process into digital it’s crucial to understand how manual work is performed; if you want to improve a system or product it is fundament to check how the user currently uses that system/product step by step.
With this technique we can observe in detail how things are actually accomplished without someone telling us and this reduces the omission of informationand there’s less likely to escape details.
Tips: > Ask them: What they do? How they do it? Why they do it?;
> You will be able to observe what the user does. You could repeat the process while she/he watches you.
Focus Groups: Semi-structured group interview for collecting qualitative information about opinions/attitudes. The subject of the focus group is typically a system, a process or a product. Useful early in the analysis phase of a project (for current state) and late in the analysis phase (for future state). It’s not very scientific, attitudes/opinions can vary.
Tips: > Write a statement of what you want to know;
> Write the questions.
Surveys: Series of questions, posed to a sample population, answered within a fixed period of time… and then carefully analyzed. You needto select the participant group. They are more scientific than focus groups.
Tips: When selecting people, it’s very important that neither the people who are answering the questionnaires are biased, nor that the questions themselves are biased, it means, that the question is not already leading to a specific answer.
> Define certain objectives in the surveys, namely scales from 0 to 10 or qualitative scales;
> Current state: to understand how things are done today;
> Future state: to get input on the solutions;
> You have to define goals, design survey, conduct survey and analyze results.