Use of active voice for better requirements
Description:
Does it really matter if I write a passive voice requirement? I understand it and everyone else should as well. Besides, it’s a short high-level system requirement and we will get back to the verification details later. These details will come when I start to specify the subordinate level of requirements derived from this one or when I prepare a design solution that will take care of the requirement. Does this sound familiar to you?
According to the INCOSE Guide to Writing Requirements (GtWR), passiv voice should be avoided, in fact Rule R2 of the INCOSE GtWR says – Use active voice. But the author of the requirement in the example above is much likely not aware of that guide or quality rule in the first place…
Ok, fine. But what does this really mean and why is it so dangerous to allow passive voice requirements?
This short webinar will explain what a requirement written in passive voice means, what problems it might create, and how to make sure it never happens.
- Introduction to what passive voice means in a requirement
- What problems might be caused when you have them
- Demo: How to check for passive voice with RQA-QUALITY Studio and how the use of patterns will help you to avoid them
- Q&A
Date:
Tuesday, September 27, 2022, 5:00 PM CET (Madrid)/ 8:00 AM PDT (Los Angeles)/11:00 AM EDT (Detroit)
Thursday, September 29, 2022, 9:00 AM CET (Madrid)/ 4:00 PM JST (Tokyo)/ 5:00 PM AEST (Sydney)