Menu
I need some advice on how to resolve ambiguities within application specifications. As one simple example,
When a user fails to authenticate after a number of times, send a notification to IT.
In the above example, it is not clear how many times "a number of times" is. It is not clear and I cannot simply set a random limit like 1000 times.
How would you go about to resolve unclear portions in any specifications? (not just the one I mentioned)
And also, what kind of topics should I search for on Google or for books for these kind of situations? Software engineering? Agile development? I am not sure where to start.
Any helpful know-hows and tips would be greatly appreciated.
253
Techniques to deal with ambiguous requirements. Use examples: For each requirement that is not clear to you, ask users to walk you through a real example. While doing so, add more details to your requirement. If you use User Stories, examples will help you confirm or write down the Acceptance Criteria.
Ambiguity is the main factor which affects the quality of the product. Ambiguity in requirement specification will affect the development of product. If ambiguity present in requirement specification then that will be considered as a bug. This will lead to poor design and performance of the final product.
If there is ambiguity in your requirement, showcase some options to your client to help them clarify their thoughts. Ask WHY it's important: I recommend asking WHY whether the requirement is ambiguous or not. The WHY will give you more context and meaning as to why this requirement is so important to your users.
We define a requirement as ambiguous if it has multiple interpretations despite the reader's knowledge of the RE context. It does not matter whether the author unintentionally introduced the ambiguity, but knows what was meant, or he or she intentionally introduced the ambiguity to include all possible interpretations.
If you're tracking your requirements in a formal way, you can make your assumptions and document them as derived requirements:
User Requirement:
Req 1: When a user fails to authenticate after a number of times, send a notification to IT.
Derived Requirements:
Req 1.1 When a user fails to authenticate after three (3) attempts, the system will suspend the account and send an email to the IT support desk.
Req 1.1.1 The account suspension email will specify the following:
Have the customer, or stakeholder if the customer is not available, review and approve the derived requirements.
For more info, Google "requirements management" or "requirements engineering". The defense industry sector is loaded with examples and templates, perhaps too many ;)
Some I have bookmarked:
80
Respond to the client with exact questions you might have. That's the best option, if available. If not, then make it configurable by end user (client).
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
