Hello and welcome to Module One. In this module, I will discuss system requirements and user stories and how software tester utilize these documents. So, what are system requirements? Well system requirements are also known as system requirements specification. It is a document that provides a description of a software that is to be developed or enhance it establish the basis for an agreement between the customers and the contractor service suppliers. It lays out in details the functionality, the non functionality that is that is required for the customers as well as its users.

It also defines at a high level the main business processes that are that are to be supported. So who writes these system requirements, when in many cases, there might be a business elements that might create the system requirements. In some organizations, there might be a project manager or product owner, or maybe some other member of the project team. But again, in most cases, it is a business analyst that creates the system requirements. So who uses these requirements, what every member on the team will read the system requirements. However it is software, tester and the developer really analyze and review these requirements in order to perform their jobs.

So for example, a software tester will read and analyze the system requirements to aid them in creating test scenarios and test cases, which we will see later in the course. Here I have an example of a system requirement. In this requirements it is the login functionality requirement. And it details exactly how the login feature should function. So when a customer puts in or when a user puts in their login name in their password here in the requirements, it details exactly how the system should function. So for example, in requirement one dot one dot one on a successful member login on the homepage, it should be available with the welcome message to say welcome welcome to psychos version with the version number and requirements one dot one dot two when the wrong user ID and our password is provided.

The user should receive an error message and the message should state invalid login. Please try again. In requirements one dot one dot three, when the user ID and or the password feel it's not provided, the user should receive an error message that states login name is required in the password name is required. Also in this example, we have some attributes for each field. So take for example, the login name field. It states in this requirement that the minimum value that should be entered for this field, it's for the maximum value is 16.

It is a mandatory field in and also states that this field should only accept alpha and numeric characters. Let's move forward with the password field. Similar to the login field, the minimum field value is four. However, the maximum field value is 25. It is also a mandatory field, and it accepts alpha and numeric characters. Now that we've completed system requirements, let's take a look at user stories.

User Stories are a short, simple description of a feature told from the perspective of the person who desires the new capabilities, usually a customer or users of the system. It describes the type of users and what they want and why. So who writes to user stories? Well, any member on the project team can write a user story A software tester and a developer. Much like the system requirements, that software tester will analyze the user stories to help them generate test scenarios and write test cases. Here's an example of a user story.

And as you can see here, it is quite different than the system requirements. As I stated earlier, there's a very short brief description of the user stories. So let's review this sample here. The short narrative stays that is a pin orders to homepage. So as a customer of the buy too much website, I want to be able to pin orders on my customer's home screen so that I can track the status that the orders that I have that I have Please, you can see here on the back of the user stories, there is a few acceptance criteria. And this is an example of a manual user stories.

So in the case, if a company, a company is creating user stories on an index card versus a tool, they would have this information as it appears here in this example. And again, on the back, you would have acceptance criterias, as well as some failures. And the test analyst or the tester would take this user story to assist them with coming up with test scenarios and test cases, test scenarios and test cases. As I mentioned earlier,