‫Welcome back.
‫In this lecture, we're going to continue our discussion
‫about systems requirements
‫and learn about a formal step by step method together
‫and visualize the functional requirements of our system.
‫So let's go ahead and learn about a step by step way
‫to capture all the functional requirements of our system.
‫In the previous lecture, we talked about the importance
‫of gathering all the requirements for our system
‫before starting designing our system architecture.
‫And we also talked about the challenges
‫in capturing those requirements
‫which involve ambiguity as well as the large scope.
‫So one native way we can go about it,
‫is to just ask the client to describe
‫everything they need our system to do
‫hoping that they do not forget any detail.
‫However, for complex systems with many features
‫and multiple actors involved,
‫this is not a good approach.
‫A more powerful and methodical way
‫of gathering requirements and capturing
‫the important features of the desired system,
‫is through use cases and user flows.
‫A use case is a particular situation or scenario
‫in which our system is used to achieve a user's goal.
‫A user flow is a more detailed step by step
‫or graphical representation of each such use case.
‫So the steps in capturing all the functional requirements
‫in a formal way are as follows:
‫first, we need to identify all the actors
‫or users in our system
‫otherwise we will likely not capture
‫all their relevant use cases.
‫The second step is to describe
‫all the possible use cases or scenarios
‫in which an actor or user can use our system.
‫And finally, the third step is to take each use case
‫and expand it through a flow of events
‫or interactions between the actor and our system
‫and in each event in this interaction
‫we capture the action and also take note of the data
‫that flows with it to, and from our system.
‫If we continue with the hitchhiking service example
‫we mentioned in the previous lecture,
‫that allows people to join drivers
‫that are already driving on a particular route
‫and are willing to take passengers on their way for a fee
‫in this case, we only have two actors,
‫the driver willing to take passengers and the rider.
‫Now, let's take the second step
‫and find all the use cases where a driver
‫or a rider interacts with our hitchhiking service.
‫For example, one use case is the registration
‫of a new rider to our system the first time.
‫Similarly, we have a registration of a new driver
‫to our service, it's another use case.
‫Another use case is logging in of an existing user
‫to our system to initiate a ride.
‫Similarly, we have the use case where a driver logs in
‫and is willing to pick up a rider.
‫Then we have a successful match
‫between a rider and a driver,
‫which starts and completes a ride
‫and finally, we have the use case
‫where we an unsuccessful match
‫where in other words,
‫a rider could not find a driver
‫that is willing to pick him up.
‫Of course, these are not all the use cases
‫but we get the idea.
‫Now let's walk through an example
‫of expanding the most interesting use case
‫of a successful match between a rider and a driver.
‫There are many ways we can represent the flow
‫of actions in a user flow,
‫the way we're going to represent it
‫is through what's called a sequence diagram.
‫Generally, a sequence diagram is a type of diagram
‫that represents the interactions between actors and objects.
‫This type of diagram is part of a Unified Modeling Language
‫which is a standard for visualizing system design.
‫It's important to point out that in practice,
‫UML diagrams are used mostly for software design
‫and there is no real standard
‫for representing software architecture in a high level.
‫Furthermore, UML as a language
‫is not strictly followed in the industry
‫but sequence diagrams are still frequently used
‫to represent interactions between different entities
‫in the system and not just objects.
‫In a sequence diagram,
‫the time goes from top to bottom
‫and each entity is represented as a vertical line.
‫The communication between the entities
‫is represented by arrows,
‫going from one entity to another entity
‫while responses are represented as broken lines
‫going from the destination entity to the caller entity.
‫So now let's walk through an example
‫of expanding the most interesting use case
‫from the hitchhiking service
‫the one that are represents a successful match and the ride
‫starting with the ride initiation
‫and define its entire user flow
‫in the sequence diagram.
‫We start with particular driver
‫that already logged into our service
‫and makes a call to our system
‫that they are on a particular route
‫and they're ready to pick up a rider.
‫Then a rider who's also already logged into our system
‫sends us a message telling us about his origin, destination
‫and also that they're looking for a driver to pick them up.
‫Please note that in this diagram,
‫we're not going to indicate the data
‫that is sent in each message
‫but we will take note of that data for the future.
‫Now at this point, our system tries
‫to match that rider to an existing driver
‫and if a match found,
‫both the rider and the driver are notified.
‫And finally when the driver makes his way
‫to the rider's location and picks him up,
‫they will start the ride
‫also at that point, the rider will be notified
‫that the ride has began as a form of confirmation.
‫Now let's fast forward to the point
‫where the driver arrives at the destination
‫and finishes the ride
‫and when that happens a message is sent to our system.
‫Once we get this message, our system charges the rider
‫from their bank account and sends the receipt to the rider.
‫After that our system takes a portion of that charge
‫as a service fee and credits the driver's account
‫with the rest of the money from the rider.
‫Finally, the driver is notified
‫about the new credit in their account.
‫Now a great side benefit of capturing all those interactions
‫between the actors in our system as part of our user flow
‫is that we can easily take this user flow
‫and identify the future API of our system
‫because essentially each interaction
‫is an API call between an actor and our system
‫and the data flowing between those actors and our system
‫is essentially the arguments in those API calls.
‫But we'll talk about designing APIs in a different lecture.
‫In this lecture, we learned about a formal way
‫to capture and document all the features
‫and functional requirements of our system.
‫This formal three step process involves
‫identifying all the users and actors,
‫gathering all the use cases
‫where the actors interact with our system,
‫and finally expanding upon each use case
‫by describing the entire flow of interactions
‫between the actors in our system.
‫Also, we learned a way to visualize those interactions
‫using a very common and useful diagram
‫called sequence diagram.
‫See you guys all in the next lecture.