How do you resolve ambiguities in specification?

Question

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.

Answer 1

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).

Answer 2

Communicate with (preferably in that order):

• Business Analysts
• Client (person(s) paying for the end product)
• End Users

Answer 3

Build or prototype it, then show it to the people who wrote the spec.

ambiguities are much easier to clear up by talking about at the actual thing, instead of a piece of paper which says how the thing is going to work.

Answer 4

From that example, I would go back to the client and ask if they want the "number of times" to be configurable. It may also lead to questions such as:

1) Who will maintain the configured number of times. 2) Will they need a UI to view these settings and change them.

Adopting a more agile development process will also help. For example, showing them an example that allows three chances to log in will demonstrate the functionality and perhaps prompt them to tell you the number.

The importance of clarifying the requirement changes where the answer to the question will affect the time, complexity and cost of the project.

Answer 5

You're overthinking this.

1. The 'number of times' value can easily be put it into the web.config
2. Set it to your assumed appropriate value. (don't worry about being wrong)
3. Send an email to your manager with your assumption, and how they can change it if your assumption is incorrect.

The notification part of the spec can be assumed if every other app notification is an email (which isn't unrealistic). Otherwise ask before you do anything.

I'm not against asking for clarification of course. But, I have found if an assumption can be made with little or no downside, it's best to do so. After all they hired you to resolve problems not bring them more. ;-)

And oddly enough; You'll probably find that most of your assumptions will be correct anyway.

Answer 6

If you're tracking your requirements in a formal way, you can make your assumptions and document them as derived requirements:

Example:

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:

• The account name of the user.
• The IP address of the computer from which the authentication attempts were made.

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:

• Guide to Specification Writing
• Writing Effective Requirements Specifications
• Writing Software Requirements Specifications

Answer 7

There are a few different routes I'd take on the ambiguities depending on who is available:

1) Project Manager/Business Analyst -> These are likely the closest to the project that may be able to help resolve issues with the specifications quickly. This may involve asking others and getting back to you later but that should be acceptable.

2) Specialist Analyst/Officer -> For example, in the case you mention where there are security implications, if there is a security officer that may have a policy to enforce on that and should be in the discussion. Another example could be having a network analyst to look at the architecture from a hardware perspective that may be useful in some cases.

3) Product Owner -> Who is responsible for defining the application. Note that this isn't a technical person, so being specific and having recommendations may be useful if you hit upon a "You know, I didn't think of that..." response.

4) Group Manager/Team Lead -> If all else fails, go to the boss and ask for clarification.

"Requirements Gathering" or "Requirements Analysis" are common terms for this part of the "Software Development Life Cycle" or "Systems Development Life Cycle" to throw out a few more terms you could search and finds lots of articles.

Answer 8

The best way is to write up brief alternative User Stories (Use Cases) that describe how the different options would affect the user, and ask the customer to choose which one(s) need to be supported.

Often an ambiguity in the spec reflects ambiguity in the mind of the customer - they simply haven't figured it out themselves yet, so this approach helps both of you. (Use written notes - nothing technical - to describe things in their terms.)

Answer 9

If the spec is not exact, maybe it just doesn’t matter? Not crucial for anything else to work? Make a call, let it be 1000. Make sure it’s not hard-coded. A good idea is to put it in some configuration file (but not expose to end-user interface, because user usually has even less idea than you).

If it’s a question of interoperability, then what do other guys do? Is it 200 in Windows? Than make it 200. Now you match both Windows and spec — not bad :-)

In case you find out your call was bad and it should have been 1500, at least you can tell your users how to fix it without reinstalling you software.

Answer 10

Well in Corporate Enterprise this does mean it follows the General Corporate Policies.

In fact when I write spec myself, I don't bother with these general specs, I just say refer to policies and go straight to the core of Specific Business Requirements.