Absolutely great video ! appreciate the effort in putting this together. Do you have any info on how to write a business requirement document and what should be the key focus. Especially when your are dealing with a customers who want every little detail from the workshop sessions we run.
This is really going to vary based on the type of product and who the stakeholders are. If the customers are extremely detail focused, that will be difficult to do in a formal requirements document on the first pass without a lot of going back and forth. Trying to do some early mockups / prototypes to get as much as possible ironed out early can help with later phases.
There are definitely software systems that have a "generic" version that can then be tailored by an agency (sometimes the original developers, sometimes not) for a particular client. In that case, you effectively end up with two sets of requirements - the general requirements and then the ones for the client, potentially handled by two different teams. In the example you give (where there is a device that is configured, I'm assuming), then the base requirements tend to include the ability to do that level of customization.
Typically, use cases are more often used to understand the basic ways that users will interface with the system (or how parts of the system interact with each other). This *can* be related to what the main functions are, but not necessarily. Think of use cases as being a bit more high level - something you could theoretically show to a stakeholder to discuss how the system will work. Use cases, however, are not good at specifying non-functional requirements because NFRs tend to be cross-cutting across multiple features (e.g. performance, accessibility, etc.). Use cases don't really have an effective way of expressing "all pages must be displayed withing 100 ms" or something like that.
Love the way you teach. You clearly have passion for what you do, and it helps us students too
damnn, the way you teach is inspiring me, thank you
Thanks!! I have to write an SRS for my class 😭
Absolutely great video ! appreciate the effort in putting this together. Do you have any info on how to write a business requirement document and what should be the key focus. Especially when your are dealing with a customers who want every little detail from the workshop sessions we run.
This is really going to vary based on the type of product and who the stakeholders are. If the customers are extremely detail focused, that will be difficult to do in a formal requirements document on the first pass without a lot of going back and forth. Trying to do some early mockups / prototypes to get as much as possible ironed out early can help with later phases.
Amazing!
isnt drawing use case diagrams in designing phase of SDLC?
How about user specific requirements (for an auricular wearable medical device for example)? Do they follow the same structure?
There are definitely software systems that have a "generic" version that can then be tailored by an agency (sometimes the original developers, sometimes not) for a particular client. In that case, you effectively end up with two sets of requirements - the general requirements and then the ones for the client, potentially handled by two different teams. In the example you give (where there is a device that is configured, I'm assuming), then the base requirements tend to include the ability to do that level of customization.
Can we say, with this method (use case) we can define the main functions? Does this method work for the non-functionals?
Typically, use cases are more often used to understand the basic ways that users will interface with the system (or how parts of the system interact with each other). This *can* be related to what the main functions are, but not necessarily. Think of use cases as being a bit more high level - something you could theoretically show to a stakeholder to discuss how the system will work. Use cases, however, are not good at specifying non-functional requirements because NFRs tend to be cross-cutting across multiple features (e.g. performance, accessibility, etc.). Use cases don't really have an effective way of expressing "all pages must be displayed withing 100 ms" or something like that.
@@MarkSherriff Thank you for your quite clear explanation.