Welcome to the Requirement Writing MOOC. As the title indicates, over the next five weeks we'll be looking at the important task of writing text-based requirement statements. It might not always be obvious why requirements are necessary. Particularly, since we don't use formal methodologies in much of our decision making in our personal and business lives. However, for projects, or as we currently run them at least, an agreed set of requirements is essential from a number of different perspectives. First and foremost we need to take the view of business management, the people who are paying for and are legally responsible for the project. For them, the set of requirements provides a mechanism whereby the organization's resources can be allocated knowingly to the project. Unless the requirement set is well defined, the project has no firm base and will have an inadequate resources set allocated to it. From the project manager's perspective, the set of requirements is an essential part of the definition of the scope of the project. And it's from this scope that pseudo-estimates have to be developed for schedule and for budget. It's not surprising then that scope management is one of the major functions of a project manager. A well-defined scope, that is a well-defined set of requirements, is necessary to be able to justify any expenditure of funds or effort within the project. To be able to adequately report on progress of work within the project. And eventually to be able to determine when the project's complete. Inadequate requirements is at the top of any list of courses of project failure. Clearly then, if the project manager doesn't begin with a well-defined set of requirements that's understood by all parties, the project is going to fail. And then from the system engineer's perspective, the formal set of system requirements represents the transition from the business world into the system's engineering and the engineering worlds. Once the set's been established, it's not possible to rectify a full set of requirements with good design, good engineering or even good production processes. Consequently, a project can rarely recover from poor definition, regardless of how much good work is preformed subsequently. Which again is why poor requirements are at the top of any list of the causes of project failure. Now, in addition to all of those issues, requirement statements at any level of design are the basis of a contract, a contract between whoever is asking for something and whoever is providing it. We give those parties various names. We call them acquirer, supplier, customer, contractor, tasking activity, performing activity. And to perform the basis of a contract, the requirements must be contractually binding. To be the basis of a fair contract the requirements must therefore at the least be feasible and able to be verified. But most of all, they must be clear, they must be unambiguous, and that is, both parties must have the same understanding of the requirement. Now, when it comes to writing formal contractually binding statements, natural language doesn't serve us very well because it can be very hard work, particularly using common English words to be clear, and to be precise, and to avoid the ambiguity. However, if we are careful to avoid that ambiguity, textual requirements are very powerful because there's no limitation on the concepts that can be expressed. Now, that's a rather long-winded way of simply saying that we have to be careful when we write requirement statements. We need to be able to avoid the ambiguity. To do that we need some rules. We need those rules to guide us so that we can talk about unambiguous requirements. And it's those rules and their application that are the focus of this course. The courses run over five weeks. During the first four weeks you'll complete four modules, one for each week. The modules progressively move through the rules for writing requirements. Each week you'll have the opportunity to undertake a module quiz, as many times as you wish, to ensure that you have a grasp on the material covered in that module. The quizzes are drawn from a large set of questions, so each time you do the quiz, you'll see new questions to test your knowledge. In week five there'll not be any presentations, but you'll have time to review the four modules and practice the module quizzes again so that you're prepared for the course test. The test questions are drawn from the same large pool of questions as the quizzes. So you should not be surprised by those questions since you will have seen something very familiar if you've been preparing by completing the quizzes at a sufficient number of times. Please also note that in addition to the video presentations, quizzes and tests, we've provided you with a number of useful resources. You have a bibliography containing the major books covering requirements engineering and requirements writing. In particular, we provide a link for a text which has been purposely designed for this MOOC. It's not mandatory, you can complete the course with out it, but I believe that you'll find it useful both during the course and subsequently. So with all let by way of introduction, when you're ready, see you in module one.
