We probably all heard the story of the product that didn't quite meet the customer's expectations. In our new language, this would mean that the product didn't meet the customer's requirements. We're going to talk today about writing good requirements so that you can develop a software product that ultimately meets your customer's or your business' needs. After this video, you'll be able to describe the purpose of writing requirements as well as list the qualities of a well-formed requirement. Future videos will go into greater depth on the language that we use to write requirements so that they're unambiguous and easy to implement. In our overall process, we've been trying to understand the as-is system. With this video we're starting our focus on requirements, which is one of the primary roles of the business analysts. Whether you're writing traditional requirements like you might do in a mature software organization or whether you're writing Agile user stories, like you might do at a smaller IT organization or a startup company. The principles of writing clear, unambiguous requirements are the same. So most of what we talk about can apply equally to traditional requirements versus Agile user stories. Future videos will go into the rest of the process such as resolving priority and developing test cases. But let's start our discussion about requirements. The purpose of writing requirements is actually communication. Whether it's to gain approval from top down, so this might be users or stakeholders or upper management. Or to tell developers down the line what to build. Or to tell a committee what type of software they should select if they're buying commercial off-the-shelf software. We also write requirements so the testers know what the software should do, as well as letting the marketers know what the software will do so that they can prepare a marketing material. All in all, the overall purpose of writing requirements is communication. Perhaps the number one rule, whether you're writing a requirement or an Agile user story, is that the requirements should not state how the system will meet the requirement, only what the system should do. Requirements are so important that they're actually covered by the International Standards Organization, otherwise known as ISO. In a document you see here 29148:2011. This document represents many years of thinking on writing the best requirements possible. And so I am going to use this document to guide us in our discussion about what makes a good requirement. According to this document, good requirements can be verified. That means once the system is complete we have a way of knowing whether or not the system meets the requirement. In my head I have the story of a requirement in a project that I worked on where the requirement stated that the software should have a beautiful user interface. When the tester came back to me and said I have no way to verify that this interface is beautiful, he ended up printing out a copy of the user interface, posting it on the outside of his cubicle, and asking people to vote on whether or not it was beautiful. The requirement has to be met or possessed by a system to solve a stakeholder problem or to achieve an objective. So in other words, it can't be a quality of the user or the business environment. Good requirements are also measurable. You may have heard the acronym SMART in your performance calls. Specific, measurable, achievable, relevant, and time bound. We can often use this acronym when writing good requirements as a way to test whether or not the requirement is good as well. Good requirements define the performance of the system. Again not the performance of the user operator or other stakeholder. So it tells what the system will be able to do or what the system allows and not necessarily specific capabilities of a user. Other important aspects, we should uniquely identify our requirements. We usually achieve this by giving each requirement a number. In some organizations the numbering system can be quite sophisticated and other organizations there might be something as simple as an Excel spreadsheet that starts with one and numbers two, three, four and so on. We should give our requirements a priority. It's inevitable that projects will come under time and budget constraints. When these time and budget constraints come down, one way to decide what we can do with the time or the money we have left is simply to organize your requirements by priority. It's most useful if this is done in advance, when you writing the requirements and not as a fire drill when the budget constraints or the time constraints come in. We should also work to identify dependencies. Some requirements are only relevant if a previous requirement is implemented. And so having a column or a field in your requirements document to indicate dependencies is a good practice. We'll talk a little bit later in the course about the concept of traceability. But good requirement should be traceable to the source. So in other words, when looking at requirements, in requirements document or requirement management system, we're going to actually use our story database, we should know where that came from. We'll discuss in future modules, techniques for gathering requirements in user stories. It include things like interviews and document analysis. This is the point where we would identify where this particular requirement came from. It might be helpful sometimes to include some rationale about why the requirement is part of the system. This way, when new management comes in or new team members come in, they don't always question the source of the requirement or whether we should be doing what we're doing. It's often helpful to indicate the difficulty. So and this could be just a high, medium, low in terms of the amount of effort required to implement a requirement. In a lot of cases easier requirements can be done in a matter of hours or implemented in a matter of hours and kind of moved off the list while more difficult requirements can take weeks or even months. And finally, we should categorize the requirements. Future video, we'll talk about the difference between functional and non-functional requirements.
