How do you solve the ambiguities in the specification?

Question

I need advice on how to eliminate ambiguities in application specifications. As a simple example,

When a user cannot authenticate several times, send a notification to IT.

In the above example, it is not clear how many times "several times". This is incomprehensible, and I can’t just set a random limit like 1000 times.

How are you going to solve obscure portions in any specifications? (not just the one I mentioned)

Also, what topics should I look for on Google or for books for such situations? Software development? Agile development? I'm not sure where to start.

Any useful know-how and tips are welcome.

Answer 1

If you track your requirements formally, you can make your assumptions and document them as derived requirements:

Example:

User requirements:

Req 1: When a user cannot authenticate several times, send a notification to IT.

Derived Requirements:

Req 1.1 When a user cannot authenticate after three (3) attempts, the system suspends the account and sends an email to IT support.

Req 1.1.1 The notification of account suspension will indicate the following:

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

Ask the customer or interested party if the customer is unavailable, review and approve the derived requirements.

For more information, “Requirements Management” or “Requirements Development”. In the defense sector, loaded with examples and templates, perhaps too much;)

Some bookmarks are marked:

• Specification Guide
• Software Specification Requirements

Answer 2

Answer the customer with the exact questions you may have. This is the best option if available. If not, make it a custom end user (client).

Answer 3

Communicate with (preferably in this order):

• Business intelligence
• Client (person paying for the final product)
• End users

Answer 4

Create or prototype it, then show it to those who wrote the specification.

ambiguities are much easier to clarify when talking about a true fact, instead of a piece of paper that says how this thing will work.

Answer 5

You think too much about it.

• The number of times value can easily be placed in web.config
• Set it to your intended appropriate value. (don't worry about being wrong)
• Send an email to your manager with your assumption and how they can change it if your assumption is wrong.

The notification part of the specification may be accepted if each other application notification is an email (which is unrealistic). Otherwise, ask before you do anything.

I do not mind asking for clarification, of course. But I found that the assumption can be made with little or no flaw, it is best to do so. In the end, they hired you to solve problems, not bring them more. ;-)

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

Answer 6

In this example, I will return to the client and ask if they want to configure the "number of times". It may also lead to issues such as:

1) Who will maintain the configured number of times. 2) They need a user interface to view these settings and change them.

Adopting a more flexible development process will also help. For example, showing them an example that allows three login options, demonstrates functionality and, perhaps, prompts them to specify a number.

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

Answer 7

There are several different routes that I would use for ambiguity depending on who is available:

1) Project Manager / Business Analyst → Most likely, they are closest to the project, which can help quickly solve problems with specifications. This may be due to a request for others and subsequent return to you, but this should be acceptable.

2) Analyst / employee → For example, in the case where you indicate where there are security implications, if there is a security officer who may have a policy to enforce this right and should be in the discussion. Another example would be a network analyst to look at the architecture in terms of hardware, which may be useful in some cases.

3) Product Owner → Who is responsible for defining the application. Please note that this is not a technical person, so being specific and having recommendations can be useful if you click on the answer "You know, I did not think about it ...".

4) Team Leader / Team Leader → If all else fails, contact the team leader and ask for clarification.

“Requirement collection” or “Requirement analysis” are the general terms for this part of the “Software Development Life Cycle” or “System Development Life Cycle” in order to elicit a few more terms that you could search for and find many articles.

Answer 8

The best way is to write short alternative User Stories (Use Cases) that describe how various parameters will affect the user, and ask the client to choose which one to support.

Often, the ambiguity in the specification reflects the ambiguity in the client’s mind - they just haven’t understood it yet, so this approach helps both of you. (Use written notes - nothing technical - to describe things in their terms.)

Answer 9

If the specification is not accurate, maybe it just doesn't matter? Doesn't it matter if anything else works? Make a call, let it be 1000. Make sure it is not hardcoded. A good idea is to put it in some kind of configuration file (but not put it on the end user interface, because the user usually has fewer ideas than you).

When it comes to interoperability, what are the other guys doing? Is it 200 on windows? Then make 200. Now you are comparing both Windows and spec - not bad :-)

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

Answer 10

Well in a corporate enterprise, this means that it complies with the General Corporate Policy.

In fact, when I write a specification myself, I don’t worry about these general specifications, I just say that I refer to policies and go directly to the core of specific business requirements.

Answer 11

To do this, you can make a focus group, or you can communicate with the client / relevant participant.