|
Projects fail for many reasons, but lacking or inadequate requirements are always among the top reasons that are given. Also, since requirements are among the first deliverables in any project, getting them right the first time will have a big positive impact on the project's total cost. And finally, by improving the distinction between requirements ("What your system needs to do") and design ("How your system does what it needs to do"), you leave room for developing systems more creatively. The purpose of this course, therefore, is to become better at defining and interpreting requirements. Often, courses are deliverd in a very generic way. This is easy for the presenter, since (s)he doesn't have to adapt the contents for the intended audience. However, the learning impact for the audience is less effective, since most of us don't develop coffee machines or cash registers. We take a different approach, and adapt our course to the specific audience. So whether you are an engineering firm specialized in assembly equipment, or a public office responsible for inner city development, our examples will be based on your kind of business. Besides the fact that this gives you a better learning experience, it also provides you with good examples of requirements that can be reused later on. In addition, we can become part of your project team by facilitating the requirements process, helping you develop your vision faster and clearer. This allows us to teach requirement principles as you go and when you need them. By immediately putting your learning into practice, the learning becomes even more effective. Typically, we would distinguish our teaching between requirements writers (learn them "How to do") and requirements users (teach them "How to use". Intended audience |  |
- Organization members: the course would use organization-specific content, and in several sessions, the principles and practices of requirements specification are taught
- Project teams: the course would be applied during the project's lifecycle, teaching relevant practices along the way, and immediately applying them to the project
Course OutlineCourses can be given in Dutch or English (other languages on request). As explained above, every course is different, and will be tailored to your organization's or project's needs. The red line, however, consists of the following subjects. - Introduction
Outline of the course, explain the importance of requirements engineering. - Setting the stage
Identify stakeholders, define your vision and context (what belongs to your system, and what not). Specify common useage scenarios (use cases). - Requirement types
Learn to distinguish between functional requirements ("What it does"), quality requirements ("How well it does"), cost requirements ("How much costs an improvement"), and constraints ("To do or not to do"). - From user requirements to system requirements
Translate (vague, ambiguous, often not realistic) user requirements to crisp and clear (SMART) system requirements. - Quantify your requirements
Get rid of bad requirements like 'The system should be user friendly': poor quantification is better than none, since you can improve it systematically. - Benchmark your requirements
Comparing to the competition, is your new system truly good enough to beat them (it's better to quit early than late). - Adding value
All requirements are important, but some are more important than others. Weigh your requirements in order to develop better solutions. - Reviewing requirements
Learn how to recognize bad requirements, and how you can improve them. - A bit about process
Learn how to integrate requirements development into your project's (systems engineering) development process. To learn more about this subject, see our systems engineering course. - Validation and Verification
Validate your requirements: "Did you build the right house for your stakeholders, so they are happy with it?"; and verify them: "Did you build the house right?" - Summary
For more information, please contact us.
|
