hello everyone and welcome to the session on requirements elicitation and software engineering um I want you guys to think about one time where you used an application or software that was frustrating um maybe it didn't work the way you expected U maybe like the flow of the logic was kind of weird so why do you think that happened yes that is correct I mean most likely the developers didn't actually fully understand like the users needs when they were like uh making the application so that is where requirements elicitation comes in uh so the learning outcomes
of this session we're basically going to try to Define what requirement elicitation is and why it's important we're also going to look at different elicitation techniques and we're going to talk about like what are the common challenges that we would actually face when we're trying to gather requirements and how we can overcome those so what is r solicitation in the price place I mean yes the definition is that okay I want to gather and try to analyze requirements that I would need for creating a specific application so I would see what are the stakeholders for
this specific application who are the people that are going to be affected by this application who's using it what's the target audience and so on so those are my stakeholders and my Target in requirements elicitation is that I'm trying to gather and analyze different requirements for all those stakeholders before I TR try to develop my application and why is this really important because I need to make sure the software that I'm developing would actually align with like what the users are expecting what are the business goals uh that we're trying to achieve so that we
get end up with a successful project at the end so really try to think of it as like you're ordering food at a restaurant right if you don't tell the waiter exactly what you want you might end up with something completely different from what you're looking for right so in software engineering if we fail to capture like the precise requirements that we need for the specific app this would really lead to a lot of like coastally rework a lot of frustrated users and the project might eventually fail so it's a very very important part of
the entire software development life cycle uh okay so there are several ways to gather software uh requirements and the most commonly five use techniques are those that we have here so first one is straightforward interviews so this is just nothing other than having onetoone discussions with our stakeholders we want to have like a detailed Insight what are your needs so this would be really great if I'm trying to get some like deep personalized understanding but the disadvantage that it would be a little bit time consuming also similar to interviews we can have surveys we can
have questionnaires it's kind of helpful because I can distribute this to like multiple users at the same time right so it would kind of help me when I need a lot of like broad input and we can also have some workshops right so we can have like a group of stakeholders and have like some interactive group discussions with those people so that we can like do a collaborative session to just to do like refining of all of their Collective ideas and uh one other technique is observation um this is kind of nice because we're basically
trying to study how like the users would interact with like an existing system so sometimes the the stakeholders don't really know what they need in a requirement so uh you might go and talk with the client and tell them okay what are the requirements what do you need the system to do and they just say um I needed to just do this function and they wouldn't really know how to express it because um not everybody is really um technical uh like techsavvy or they they might not really know how to explain what they need so
this way is nice because you would actually just observe how they are working with their current system for example and when you see this you will okay you will be able to tell okay okay this is a hidden need this is an issue that they are facing we want to develop a system that would make this better and so on so it kind of helps find like the hidden needs of the stakeholders that they might not really be aware of or they're not really sure how to express and the last technique we'll talk about is
prototyping so that's just kind of like developing like a rough vers version of the software where you give people and just have some initial feedback so that we can always keep on refining it before we try like the full development okay uh imagine that you guys are developing like an application for course registration for University which elicitation technique would you actually think would be most effective for Gathering student needs okay uh now even with great techniques Gathering ACC accurate requirements is not really always easy we have a lot of like common um challenges first one
is having ambiguous requirements right uh people might just say I want the system to be user friendly but yeah what what does that mean um we can also have conflicting interests so maybe when we're talking to different depart like different departments or stakeholders maybe they will have competing priorities right so for example marketing might want more features it might want like Simplicity and so want and one more challenge is basically changing requirements um this is really uh very common uh so whenever you're working on a project and you have like an initial set of requirements
those requirements might shift over a time and that would like also affect the development so that's also one important challenge that we face so uh one big important example is the one that we talked about last time the uh Denver International airp for disaster that happened so they tried to implement a baggage handling system they paid so much the project actually ended up delayed by like 16 month and they lost uh like a 1.3 billion over budget before it was canceled and the main really caused for that because they when the whole uh like team
was trying to work on the requirements analysis even though the airlines were key stakeholders in the system they were really excluded from the discussion so it's like one major stakeholder that is going to be using this system was completely excluded so of course that would affect process of the requirements analysis and that really affected the entire development process so this is why having clear validated requirements is very essential because without those really even large scale projects with massive funding they can can fail spectacularly so it is really an important part of the sofware development life
cycle okay so now that we've seen common challenge uh let's look at some practices to how to address those so we can try to just make sure that we're engaging stakeholders right uh try to have frequent communication so that we avoid any misalignments uh also whenever we're talking with like non-technical stakeholders it's best to like avoid technical jargon right try to like talk in simple language so that they really get what we're talking about and we also want to make sure that we're having clear like differentiation between a musthave requirement and yeah this would be
nice to have so we have to like prioritize and another important thing is having proper documentation I know it's not our favorite people just want to go and Implement directly but if we don't have a proper documentation for all the requirements it's going to really be a very messy process especially since we said that uh during the duration of development changes might happen to those requirements we might change them we might modify find them so it's very very important to have detailed documentation okay so for the University course resoration system that we just talked about
earlier how would you balance like the needs of students professors and administrators all of those are like stakeholders of the system right so what would you prioritize okay uh so now let's just summarize what we've covered today uh we've seen that requirements elic elicitation is the process Where We Gather and validate all the needs of the stakeholders before we even start development and we've also seen that the common techniques that we use I can have interviews surveys workshops prototyping and we've seen that the couple we we can see a lot of challenges like um having
ambiguous requirements conflicting interests and requirements that keep on evolving over time right and the last thing we talked about was that in order to fix uh those issues we can have clear communication try to prioritize important requirements first and have continuous engagement between the stakeholders and the development team and really I want you guys to think about this imagine a doctor prescribing medicine without asking you about your symptoms would you really trust that prescription no right because software Engineers must also diagnose those stakeholder needs before they properly build the system okay so um just to
conclude we've seen that it's really important um that we understand that requirements elicitation is very crucial for successful uh software development and using the techniques that we've seen for elicitation we can really avoid a lot of like cly mistakes and just make sure that our software meets the user expectations which our which is basically our main target right okay so the next time you use an app think about how those developers actually gathered the requirements to build it so try to see that okay what do you okay I think they did this well I think
they could have improved this and so on okay that's it for now if you have any questions or thoughts just feel free to share them on the course Forum see you next time
