How can you elicit difficult requirements effectively?

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.

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.

break the problem down by like scope elements. define each element and their interconnections. then, as Noah said, diagram the technical elevations and/or material (people and hardware) required. Lastly, capture total coat to produce and sustain, including residual value at end of life. In other words: Be good enough to know what you don't know and bring the team in early to fill your gaps.

First of all, go with more than just hearing. It would be best to listen to what people are trying to say, even nonverbally. Also, if you have any doubts, don't hesitate to ask clarifying questions, even if it's just for double-checking. Something very helpful is to imagine use cases and edge case scenarios to check how your clients/stakeholders describe what they want to get from the project from their point of view.

Pay close attention to what stakeholders are saying & ask probing questions to dig deeper into their needs & concerns. Make sure you understand not just the surface-level requirements but also the underlying reasons behind them.

To fully understand the why, a good immersion in the problem is very effective. I am talking about a physical immersion, in order to experiment the problem and challenge it.

Market environment is essential to determine ¿is real or desirable?. Analysis of who it impacts, who it should impact, when it impacts and in what way it impacts, allows the involvement of real actors to the REQ. Otoh, this will allow the creation of a more grounded project plan. In my experience, process flows and diagramming allow for a better landing of the validation path for compliance with requirements. Not skimping on details could allow you to be more assertive, but be careful, don't lose the initial horizon. The model I use the most is the Canvas Business Model; which allows me to raise and place the main requirements according to the actors to address them in a practical and visual way.

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.

Yes. Multiple methods may be needed. in my experience, this depends on the organization and the process of getting to the gathering requirements' stage. This reminds me of the issues I faced so many times... you think this is it. We got everything to start solutioning... wrong.. someone else has an opinion and so go back to the drawing board. This back and forth dialog is one approach. Stakeholder meetings are another. After listening to all these people, the simple solution in mind is not enough. My perspective is of someone who is capable of getting the requirements, analyze and be able to design a solution, test, implement and support it. Learn from the mistakes and be better next time. Also - collaborate with your team to re-use code

In case of safety relevant automotive development, international standard ISO 26262 recommends several methods and combination of it to derive requirements. Be aware to have a look.

I've learned, it is always better to use multiple methods. Understanding the context, asking open ended questions, and involving the right people, all make for good ways to elicit requirements. Once you poll all of these resources, and combine the things learned from each, almost ensures a good start to any project.

Correct, no one-size fits all. That is why when soliciting and consolidating product requirements... think MVP, minimal viable product first. MVP is what is within budget, attainable, meets the VoTC, Voice of the Customer, and can easily pivot to accommodate your larger revenue customers. Your wasting energy, time and money if you are trying to capture every detail. Put other features, thoughts, ideas and possible rabbit holes in MVP+1 or MVP+2 projects and timelines that align to your budget and roadmap.

Educating the team on the scope of work and technology in use when facing requirements challenges. People should see the operational impact to the project to gain a better understanding on how to address the requirements gathering process.

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.

Identifying the right stakeholders is often more difficult than we think. It is necessary to take this time. This identification is often done by interacting with one or the other. Then, identifying them is not enough, it is also necessary to evaluate which ones will be beneficial and which ones will be a hindrance to the project.

The "right people" list misses some folks I like to chat with: technicians who actually work with hardware; Quality Assurance people like inspectors; and operators who actually run similar gadgetry. They all know "stuff" that can be invaluable. One example might be "you have to taper this cylindrical section, make it like a cone, so that the part will slip out of the mold when we make it." The list is infinite.

En mi opinión, involucrar a las personas adecuadas es un arte que requiere una combinación de estrategia, intuición y empatía. No se trata solo de encontrar a las personas con las habilidades y la experiencia necesarias, sino también de crear un equipo con una dinámica positiva y un objetivo común. Aquí hay algunos puntos clave que considero importantes para lograr una participación efectiva: 1. Definición clara de roles y responsabilidades. 2. Búsqueda de diversidad. 3. Enfoque en la motivación y el compromiso 4. Comunicación abierta y transparente 5. Creación de un ambiente positivo 6. Reconocimiento y celebración del éxito Involucrar a las personas adecuadas es un proceso que requiere tiempo, esfuerzo y atención.

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.

Also I will say when doing interviews keep it simple but detailed. A lot of times the customer thinks they know they want but what they want may not always be simple or even possible. Also there may be things that they do need based on requirements that maybe they have not thought of. Ask them for usage scenarios. I also believe the interview process doesn't really end till the project is complete and then depending on the situation if you are providing O&M it doesn't even end at completion. You should be asking questions all the way through the process. No matter how much knowledge you think you have. Every customer, every environment is different.

I’m a big fan of ‘What else’ when working through a situation that requires multiple persons and a better and thorough understanding of the given situation. Followed by ‘and then what?’ and another round of ‘what else?!’ - simple and thought provoking everyday language that encourages brain dumps and leads to a better and more rounded and robust pathway to success. Always worked for me. Nothing fancy.

It is really important to ask open ended questions and ask why is this needed, how will it benefit , where it will be used, who is the end user and contexulize requirements using open ended questions

The open-ended question must end in closed, testable requirements, and must indicate what the problem is and what is the agreed best way of solving it, with expert input for feasibility and impact. You will need experience and expertise to be able to direct the conversation in this way: open statements in reply are not good enough, any customer/user comments of which you can't work out the impacts and risks will come back and bite you. Don't be afraid to come back to the customer and demand clarification or decision between alternatives. They have at least as much interest in getting the right solution as you do.

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 best visual aids tell stories. Your entire focus should be on polishing this up. Experts go off the reserve and create an analogous story, where at the end, it all makes sense what is needed (Bonus points if you're good at animation!)

En mi opinión, las ayudas visuales son herramientas increíblemente valiosas para comprender y comunicar información compleja. Considero que su uso aporta diversos beneficios que las convierten en un recurso indispensable en el trabajo. En mi experiencia, las ayudas visuales han sido fundamentales para explicar conceptos complejos, presentar ideas, facilitar la toma de decisiones, comprender mejor el contexto y comunicar ideas de forma efectiva. Ejemplos de cómo utilizo las ayudas visuales: Diagramas, mapas mentales, infografías, prototipos, imágenes y videos. Las ayudas visuales son una herramienta poderosa que puede ayudar a: - Comunicar ideas. - Comprender mejor el contexto. - Lograr un mayor impacto en tu trabajo.

Massive fan of this, other contributors have outlined the basic ideas. The automotive sector invented the "Geba-kai" method, which involved every supplier bringing along their products/prototypes and laying them out on the floor. This permitted everyone to see where the interfaces were and whether or not they were going to work. 3D CAD systems have replaced some of this, but I still recommend for more complex physical systems to build and try. 1) functional prototypes for basic performance and FFFIS 2) off-prototype-tooling so a full scale prototype can be built 3) first-off production tooling 4) series production ramp-up (or use at scale) Feedback on form, fit, function, interface and safety between steps is best done visually.

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.

Key step: define how this requirement will be verified (e.g., test, analysis, similarity) and what the success criteria will be. If you can write "put the item on the scale, record the reading, pass is less than 5 kilograms" you are good. If you can't define the success criterial that well, and TBDs are ok as in "TBD kilograms," then the requirement still needs work. Note that one TBD in a document requires having a proper "TBx" tracking list.

The validation and verification step is where the rubber meets the road. It’s a critical quality assurance measure that ensures the requirements accurately reflect the stakeholders' needs and are feasible within the project’s constraints. This process helps in identifying potential problems early on, saving time and resources by preventing costly revisions later in the development phase. It’s a testament to the adage, "measure twice, cut once," underscoring the importance of diligence and precision in the requirements elicitation process.

In my opinion this is where you bring in non-stakeholders. People that have no stake in the project. The best way to get valuable feedback and understand if the product speaks for itself is to bring in people that have not been involved whatsoever. An appropriate selection of people is somewhat necessary but keep an open mind on who you choose. Have them test the product. Listen carefully to their feedback and capture it for review outside the heat of the moment.

After deriving requirements, a review of the requirements done by an independent colleague may help to identify double ones. For safety relevant development, fault tree analysis is a very useful tool to check consistency and completeness of the requirements.

What about analysis "analyses provide repeatable evidence of correctness" DO-178 §6.3 Software Reviews and Analyses ? Using semi-formal (Controlled Natural Language like EARS) methods or formal methods (SPARK) can help reduce requirements validation effort by giving the possibility to use tools. Moreover, to me, inspections and walkthroughs are specific types of reviews so the sentence might be reworded as such: "You can use techniques such as reviews, analysis or testing"

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.

Although I am rarely devious in a work setting (those who know, please do not react) but, if pertinent details are not forthcoming or that which is revealed is insufficient for the program to move forward: Make a statement that is notably off target such as: “I believe, based upon what you have shared thus far, that you want us to make a silk purse out of a sow’s ear and you will be providing the ears….is that correct ??” Trust me, the detailed information you require will start to flow. And you can apologize at the project completion celebration.

Utilizing model-based systems engineering (MBSE), such as SysML, allows for a deeper understanding of requirements by creating visual representations of system architectures, behaviors, and interactions. Discussing requirements based on these models enables stakeholders to grasp complex concepts more easily, identify potential conflicts or ambiguities, and provide more specific feedback. By visualizing the system through MBSE, discussions become more focused, collaborative, and effective, ultimately leading to clearer and more precise requirements.

To achieve a validated set of system requirements, early and frequent discussion with the stakeholders is important. It’s much easier and cheaper to add/modify requirements in the earlier lifecycle stages of a product/program.

One key insight that often goes overlooked is the importance of adaptability and continuous learning throughout the requirements elicitation process. Each project brings its own set of challenges and learning opportunities, meaning what worked for one project may not work for another. Being open to feedback, willing to adjust tactics, and continuously refining your approach based on lessons learned can significantly enhance the effectiveness of eliciting difficult requirements. This adaptive mindset ensures that the process remains dynamic and responsive to the evolving needs of the project and its stakeholders.

Particularly with difficult parametric requirements, it's good to have upfront discussions with all stakeholders. The customer may have interdependent requirements and relieve a difficult requirement while tightening others. Or the designers may be able to reduce the risk of meeting the difficult requirement if they are given relief on others.