Requirements engineering is a crucial process in systems engineering, as it defines the objectives, functions, and constraints of a system. However, eliciting requirements from stakeholders can be challenging, especially when they are complex, ambiguous, conflicting, or hidden. How can you elicit difficult requirements effectively? Here are some tips and techniques to help you.
Before you start eliciting requirements, you need to understand the context of the problem, the needs and expectations of the stakeholders, and the scope and boundaries of the system. This will help you to identify the relevant sources of information, the key questions to ask, and the potential risks and assumptions. You can use techniques such as stakeholder analysis, problem statement, context diagram, and scope statement to establish the context.
You need to understand everyone's 'Why'. It could be several layers deep but there may be another solution that they aren't seeing - just keep asking 'why?' until you get to a fundamental. If there's multiple stakeholders get them in a room together with you, coffee and a pack of biscuits. It'll soon be worked out.
I’ve found the approach of working backwards very effective! What is the end vision, user problem or use case you are trying to solve? Outlining this clearly up front and creating and answering FAQs with this context in mind does help a lot with eliciting business and technical requirements. It also helps determining which requirements are core and non-negotiable and others that can be diluted initially and built upon in later iterations of the solution.
Often , in product development, a method that works best is to observe behaviors, actions and outcomes instead of explicitly asking questions of what is required. Often unmet needs of your end users are uncovered this way. It is when you solve for these unmet needs that you end up delighting your customer the most. Asking a user or a customer what they want might yield some results but often do not solve the issue at hand. Once we get to these unmet needs, then a proper system engineering approach helps us to rapidly lay out solutions.
Active Listening - Pay close attention to what stakeholders say Ask Open-ended Questions - Instead of asking yes/no questions, ask open-ended questions that require detailed answers Probe for Details - When stakeholders mention a requirement, probe further to understand its nuances, dependencies, and implications Use Different Techniques - Employ various techniques such as interviews, surveys, workshops, and brainstorming sessions Empathize - Put yourself in the shoes of stakeholders to understand their needs, challenges. Visual Aids: Utilize visual aids such as diagrams or storyboards Use an Iterative Approach Document, Document, Document Involve Stakeholders Early Seek Multiple Perspectives from a Variety of Disciplines
This is where to ask one of my favorite questions: ‘What are we trying to accomplish?’. In my industry (Defense) many standard specifications are applied by default or worse a ‘commercial’ spec is applied because it is perceived as cheaper but does not address the use case. Classification society rules and industry standards are developed with a bounded application in mind. It is up to the subject matter experts to understand how requirements apply to the customers application. Getting involved early when there is time to influence these specifications and requirements is invaluable.
There is no one-size-fits-all method for eliciting requirements, as different methods have different strengths and weaknesses. Depending on the situation, you may need to use a combination of methods, such as interviews, surveys, workshops, observation, prototyping, scenarios, or document analysis. Using multiple methods can help you to cross-validate, clarify, and refine the requirements, as well as to uncover hidden or implicit requirements that may not be expressed verbally.
People solve problems. So, having the right folks to solve the problem is the first step. Knowing the decision authority, resisters, supporters, stake Holders, customers, suppliers, partners etc is vital. Once the right parties are identified then give them guardrails like * The problem, * Target customers * Operational env for the solution * Anything else that is relevant During the session use a lot of brainstorming / visualization tools (mural, Miro and the likes) and facilitate conversations to find requirements and low cost ways of validating them. There will be a need for follow-ups. Follow them closely to ensure the requirements are hashed out.
You’ve hit the nail on the head! Employing a diverse set of methods to elicit requirements is critical because it acknowledges the complex nature of projects and the varied ways in which people express their needs and ideas. This eclectic approach not only enhances the quality of the requirements gathered but also promotes a more inclusive environment where every stakeholder has the opportunity to contribute, thereby enriching the project with a multitude of perspectives.
A mi me resultan útlies la observacion en el lugar de trabajo, la preguntas y repreguntas tratando de buscar las causa raiz de los problemas. Muchas veces apelo a alguna espina de pescado o alguna técnica de 5 por ques para encontrar las causas o tratar de enteder. Finalmente todo lo que entiendo lo modelo en un dibujo que represente lo que está sucediendo. Y suelo compartir ese ejercicio con lso stakeholders. En este punto uso mucho estrategias basadas en UML.
Ah, the art of versatility. When it comes to eliciting those elusive requirements, forget about one-size-fits-all solutions. Embrace the smorgasbord of methods at your disposal: interviews, surveys, workshops, observation—you name it. It's like assembling a toolkit with a bit of everything. By using multiple methods, you're not just cross-validating; you're shining a light into every nook and cranny, uncovering those hidden gems that lurk beneath the surface. It's about seeing the bigger picture, one method at a time.
Don't forget some very fundamental things like developing or working from the Concept of Operations (CONOPS) to do first order analyses, simple physics and chemistry, that should get "kinda sorta" numbers that are within 10% or so for reality. Then follow GSFC-STD-1000 to add margin. That CONOPS work should also define the first, and very rough, requirement and budget allocations.
One of the main challenges of eliciting requirements is to involve the right people at the right time. You need to identify who are the key stakeholders, such as customers, users, sponsors, regulators, or experts, who can provide valuable input and feedback on the requirements. You also need to consider their availability, communication preferences, and level of involvement. You can use techniques such as stakeholder map, RACI matrix, or communication plan to manage the stakeholder engagement.
Involve all relevant stakeholders in the requirements gathering process. This ensures that diverse perspectives are considered & helps uncover requirements that might otherwise be missed.
Purpose of the project determines the type and the people needed. High level requirements can be given by the management team, whereas details need to be obtained from SMEs and end-users. For seamless Integration with other systems and for conformation with the overall infrastructure, the IT, network, security, DBAs, and other teams may be needed. PMs should account for the man-hours spent on these sessions. Some orgs track time by every half hour and some team members have their own cost centers as opposed to the Project Cost center. This becomes complicated if permissions are needed to invite people for interviews!! (I experienced this).
Ah, the delicate dance of stakeholder engagement. Picture this: a gathering of minds, each with their unique insights and perspectives. To elicit those elusive requirements effectively, it's crucial to bring the right folks to the table at the right moment. Think customers, users, sponsors—the whole shebang. But here's the kicker: it's not just about who's there; it's about understanding their quirks and preferences. Stakeholder maps and RACI matrices? They're your secret weapons, ensuring everyone's on the same page. It's like orchestrating a symphony of collaboration.
It is important to identify the stake holders in the development and production of the services or products that are being consumed or delivered. Both internal and external requirements need to be identified and addressed by the solution. Using the Agile method to create the MVP and then get regular feedback is necessary to get the best results for the project.
Involving the right people is crucial to the success of eliciting requirements. It’s like assembling a team where each member holds a piece of the puzzle. By carefully selecting stakeholders based on their expertise, interest, and influence over the project, you ensure a comprehensive collection of requirements. This inclusivity strengthens the project’s foundation, as it is built on a well-rounded understanding of needs and expectations from all corners of the stakeholder spectrum.
One of the most effective ways to elicit difficult requirements is to ask open-ended questions that encourage the stakeholders to explain their needs, expectations, and concerns in detail. Open-ended questions are those that cannot be answered with a simple yes or no, such as what, why, how, when, where, or who. You can use techniques such as 5 Whys, root cause analysis, or goal-oriented requirements engineering to ask open-ended questions that reveal the underlying motivations and rationale behind the requirements.
Without focus, open ended questions just lead your team and budget down a rabbit hole. If you want to capture a piece of blue ocean and enter a new market with little competition or barriers standing in the way of your companies innovators, then ask focused questions. Opened ended questions should be saved for the end of a survey, when the participate has "Dried Up" and nothing is forthcoming, otherwise you are just leading them on. Save the 5 Whys and root cause analysis for things that go south, ie; escaped production issues. Remember that you can sell one of anything, it's only when you sell the next one that you are doing it right and more importantly, Sales revenue comes from relationships, people buy from people that they like.
When faced with those tricky requirements, open-ended questions are your golden ticket. Think "what," "why," "how"—the whole gamut. They're like keys to unlocking the deeper layers of stakeholder needs. Ever heard of the 5 Whys or root cause analysis? They're your trusty companions, guiding you through the maze of motivations and rationale behind those requirements. It's about digging deeper, peeling back the layers one question at a time.
"Try this and tell me what you think." As much as you hate to do it, sometimes you have to define requirements by implementing something for the customer as a conversation starter. The old adage is "Build one to throw away."
Asking open-ended questions is a powerful technique in uncovering the real needs and challenges stakeholders face. It opens the door to in-depth discussions, encouraging stakeholders to share their thoughts more freely and thoroughly. This method not only reveals more nuanced insights into their requirements but also fosters a collaborative environment where stakeholders feel valued and heard, further enhancing the quality and accuracy of the requirements gathered.
In order to inspire inspiration, you can't give anyone the answers, or they are doing it your way. Which is likely not the best way since you are likely not the one doing the job. It is only through unique discovery that you learn what you don't know. This goes both down the chain as well as up the chain for a project manager or an engineer that needs to understand the needs of the sponsor as well as the abilities of the team. It is only through discovery of what we don't know that we achieve success and innovation.
Another way to elicit difficult requirements is to use visual aids that help the stakeholders to understand and communicate their requirements more clearly and effectively. Visual aids are any graphical representations that illustrate the system, such as diagrams, models, sketches, or prototypes. You can use techniques such as use case diagram, data flow diagram, state machine diagram, or wireframe to use visual aids that capture the functional, behavioral, or structural aspects of the system.
Even if remote working is fashionable, nothing is more effective for identifying a tricky requirement than being in front of a huge board (preferably an entire wall), to express and share your conception of the problem. This resolves a lot of misunderstandings
Using visual aids such as architectural diagrams, use case diagrams, and component mappings can greatly enhance project discussions by providing clear, visual representations of the system's design, functionality, and interactions. These visual aids facilitate alignment among stakeholders, reduce the risk of misunderstandings, and help set the development course in the right direction from the outset.
Using visual aids is a game-changer in bridging the gap between technical and non-technical stakeholders. These tools act as a universal language, simplifying complex concepts and facilitating a clearer understanding of the requirements. By visualizing ideas, stakeholders can more easily identify discrepancies, offer suggestions, and align on expectations, ensuring a smoother development process and a final product that more accurately reflects their needs.
In my experience, good specifications always start with good definitions. Definitions are essential and save an enormous amount of time, both in writing requirements and in initializing the project. Better still, definitions based on diagrams are easier for the sales team to understand. The risk of having an irrelevant bid for system realization is greatly reduced.
Visual aids are your secret weapon when it comes to unraveling those tough requirements. Think diagrams, models, sketches—the works. They're like roadmaps, guiding stakeholders through the intricate landscape of system requirements. From use case diagrams to wireframes, these visual gems capture the essence of functionality, behavior, and structure with a single glance. It's about speaking the language of visuals, creating a shared vision that leaves no room for misinterpretation.
The final step of eliciting requirements is to validate and verify that they are correct, complete, consistent, and clear. This means that you need to check that the requirements meet the stakeholder needs and expectations, that they do not contradict or overlap with each other, and that they are understandable and unambiguous. You can use techniques such as reviews, inspections, walkthroughs, or testing to validate and verify the requirements and to resolve any issues or gaps.
I ask the question: how does the requirement connect (i.e. interface) with the system? In cases where there is no connection, the requirement should be challenged -- there are exceptions.
Validation and Verification. It's time to dot those i's and cross those t's. Think reviews, inspections, walkthroughs—the whole nine yards. It's about ensuring those requirements hit the mark: correct, complete, consistent, and crystal clear. Picture this: a meticulous process of checks and balances, ensuring every requirement aligns seamlessly with stakeholder needs and expectations. From resolving issues to filling in gaps, it's the final stamp of approval that seals the deal.
You don't necessarily need to do full MBSE, but it's a good idea to build a model of your System of Interest especially when it's something very new and less experienced. SysML diagrams come very handy here, and you might choose any of the modelling frameworks available and suitable. Keep it as simple as possible. Your model will be very useful to Validate your requirements, force stakeholder feedback, correction and new requirements that were not seen before. Iterate as you go and capture everything. If you are able to also animate your model to simulate the system behaviour, then the value you get from this validation activity is even higher. And you'll get much less changes later in the project when they are more expensive.
I may be wrong here, but to me this wording muddies the concepts of Verification and Validation. I think it's unhelpful to say the final step of *elicitation* is to "V&V" that requirements are correct/complete/consistent/clear. Even assuming you perform some validation activities on a new requirements set, you almost certainly don't immediately verify those requirements. I come from the Aerospace context so perhaps the jargon is a little different in other industries. But to me this whole prompt comes across as buzzword-speak.
As a DevOps Engineer, the culmination of gathering requirements involves a meticulous process of validation and verification to ensure accuracy, comprehensiveness, coherence, and clarity. This entails a thorough assessment to confirm that the defined requirements align with stakeholder expectations and objectives, exhibit no conflicts or redundancies, and are articulated in a straightforward and unequivocal manner. To achieve this, deploying strategies like peer reviews, code inspections, walkthroughs, and targeted testing is essential.
It is sometimes difficult, no, it is often difficult to get the subject of the requirements to provide input. They have other things to do, and they don't really want your requirements in the first place. An approach that works well is to send them a set of incorrect requirements, and tell them, "Here are your requirements." You will find that you get a quick response, detailing where and how they are wrong.
Here are some strategies: 1. Active Listening 2. Relevant stakeholder Involvement 3. Use prototypes or mockups 4. Presenting with real-life scenarios or use cases 5. Take an iterative approach 6. Prioritize requirements based on their importance 7. Conduct facilitated workshops 8. Document the elicited requirements thoroughly & validate them 9. Be Flexible and Adaptive By employing these strategies, we can effectively elicit difficult requirements in software engineering projects, leading to a clearer understanding of stakeholder needs & ultimately a more successful outcome.
Write FAQs about a similar product or service and invite relevant stakeholders to help develop the assumptions within the FAQs, then validate the assumptions and refine the narratives within the FAQs to build the requirements traversing backwards from the FAQs.
The customer knows they have a need, but they rarely understand it completely. They have the baggage of unnecessary and incorrect assumptions taken as fact. Identify what must remain constant, and what may be discarded. Only include what is necessary in designs and requirements. Don’t overburden the project with overly complex and verbose design artifacts. Simplicity will help you, and will help project stakeholders better understand what they actually need.
Three small thoughts, perhaps obvious and well known: 1. If you write a requirement and cannot write the test step to verify it, then for sure no else can later on. 2. Don’t try to write requirements in anticipation of narrowing solutions to one your organisation has used or prefers (politics, prior experience, cost…) - it doesn’t work out well for anyone ?? 3. Don’t try to copy requirements from a similar prior programme blindly without very careful evaluation they are applicable to this one.