Requirements Specification

After you have worked with the customer to gather their requirements, what are some ways you can communicate those requirements to the development team?
Depending on whether you are more agile or more plan-driven, you may choose to use a technique that is more documentation-heavy versus one that is more conversation-focused. In this video, we discuss use cases and software requirements specification (SRS) documents for more plan-driven environments and user stories for more agile projects.
* cs3240.cs.virginia.edu/materia...
* www.uml-diagrams.org/use-case...
* www.extremeprogramming.org/rul...
* www.mountaingoatsoftware.com/...

Пікірлер: 12

  • @DepresSion271
    @DepresSion271Ай бұрын

    damnn, the way you teach is inspiring me, thank you

  • @onlyupformhere
    @onlyupformhere10 ай бұрын

    Love the way you teach. You clearly have passion for what you do, and it helps us students too

  • @the_gift_of_Allah
    @the_gift_of_Allah2 жыл бұрын

    Amazing!

  • @MrKirkCaptain
    @MrKirkCaptain2 жыл бұрын

    Thanks!! I have to write an SRS for my class 😭

  • @kalyug2011
    @kalyug2011 Жыл бұрын

    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.

  • @MarkSherriff

    @MarkSherriff

    Жыл бұрын

    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.

  • @bsnbhasith5666
    @bsnbhasith56666 ай бұрын

    isnt drawing use case diagrams in designing phase of SDLC?

  • @btk9639
    @btk96393 жыл бұрын

    How about user specific requirements (for an auricular wearable medical device for example)? Do they follow the same structure?

  • @MarkSherriff

    @MarkSherriff

    3 жыл бұрын

    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.

  • @safinurozbek2025
    @safinurozbek20252 жыл бұрын

    Can we say, with this method (use case) we can define the main functions? Does this method work for the non-functionals?

  • @MarkSherriff

    @MarkSherriff

    2 жыл бұрын

    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.

  • @safinurozbek2025

    @safinurozbek2025

    2 жыл бұрын

    @@MarkSherriff Thank you for your quite clear explanation.