During yesterday's webinar on Essential Requirements Practices with Karl Wiegers, we were not able to answer all the questions during the Q&A time. So we did send the questions to Karl and got his answers.
Do you think that multiple THEN statements should be included within the one acceptance criteria statement rather than splitting out each THEN statement into separate acceptance criteria statements?
If a single test (that is, a single combination of GIVEN and WHEN) yields multiple outcomes, I would list them all as part of the THEN clause, because they all must be satisfied to say the test was passed.
What do you think about ‘obvious’ requirements?
For an example, users get annoyed because the new BI report does not allow them download the output data directly into Excel format. Instead, the tool outputs to CSV and then 90% of users end up having to open the files in Excel and then re-saving the file as a .xlsx
The developers respond ‘sorry – but you did not request that feature in requirements’. If you want to give us more money, you can get it in Release 3 (2 years from now if it ever comes..)’
The users reply, ‘Seriously, you built us 4 similar reports before this, already after the first report we asked for direct to .xlsx download, and you went ahead and built that in report 2 and 3. We all even agreed that it was best practice since most of the users are manipulating the file in Excel. Oh, and by the way, the CSV file is 100 MB, whereas the .xlsx version is 10 MB so it saves a lot of IT bandwidth by users downloading smaller files from the network. Why do we have to ask over again
My feeling is that if a requirement is not specified somewhere, no one should be surprised if that requirement doesn't appear in the product. This case is an example of assumed requirements, coupled with inadequate communication. What is obvious to one party may not be obvious to another, particularly if (a) the people have changed since the earlier requirement was implemented or the change was made and/or (b) that previous requirement or change request was not clearly documented somewhere.
In this case, the fact that there was a pattern of including this particular requirement previously might not have been known to the BA or development team, even if the users knew about it. If that information was available, then the BA perhaps did not do a good enough job of examining the records from the previous report implementations to see the pattern. The BA (or dev team) might have simply implemented what the users asked for, instead of properly eliciting and analyzing the new requirements. The BA could have asked questions like, "I see we added the capability for direct to .xlsx download to the previous reports. Do you want that here as well?"
This is the kind of problem that can arise when requirements are not properly elicited, documented, and referred to when changes or enhancements are made. Relying on human memories for these details is risky and imperfect. It would be worthwhile for the participants to talk together to understand why that unstated and assumed requirement was overlooked and adjust their process to make such oversights less likely in the future.
How to approach when the overall business processes are being refined based on the results of a project, given that users have negative past experience with the solution?
Here's what we say about that on page 93 of the book:
Some new information systems either impose or accompany changes in an organization’s business processes. It’s hard for users who are accustomed to doing their jobs in a certain way to envision a whole new mode of working; some of them will resist the change. Too often, new system implementations simply repave existing cow paths, updating the interface while retaining outdated and inefficient processes. Significant process and application changes can push users out of their comfort zone. Those changes sometimes require additional training and alter, or even threaten, employees’ jobs.
Influential user representatives who work with the software team to develop and
evaluate prototypes can ease that uncomfortable transition. A BA, a user experience
designer, and some users can explore ways that a system could support new business workflows. It’s better to address potential points of user resistance during prototyping than after the new system goes live. This engagement also builds trust and buy-in from the user participants regarding the new future state, so they can lead others in the organization through the transition.
Thank you for the answers Karl!