Dear Unnati,

which ambiguities are you referring to, do you have any examples to illustrate your question?

Best regards

Thank u sir for your concern actually i am interested in requirement specification and specially for resolving ambiguities in SRS as per literature survey what i understand that not all kind of coordination ambiguity resolve.like some author says it can not be resolve it can be prevent by constrain or some restriction on input text and some have resolve only noun compound and verb compound so the question is in which direction i start to work for (and,or and but with all possible sentence construction)or vagueness and generality.i want guidance regarding this thank you

Wow! that's a good question and would solve sooo many problems!

As long as we use natural language to write requirements, avoiding ambiguity will be almost impossible.

If you use a tool that forces the user to comply with certain "structural language", you have a good chance.

For instance: I know that Rational Rose (from IBM) has a tool called RequisitePro to capture requirements in the form of use cases. You get to document your requirements but following UML and limits the natural language.

http://www-01.ibm.com/software/awdtools/reqpro/

Using extra sets of eyes to validate and cross-check requirements is a good practice, too.

thanks for your reply Telma Frege-Issa .as u mention that you people are using natural language for RS then how you ppl deal with such ambiguities in SRS???what kind of difficulties you are facing ?how you manage all bulky requirements?except rational rose what other tool know to deal with ?

Dear Unnati, at best of my knowledge, dr Kamsties suggests two possible ways. 1) one is to use a constrained natural language to write specifications; it is a subset of the natural language ruled by an underlying ontology. 2) the second way is to use a linguistic-driven inspection of the requirements. Maybe all these approaches could be supported by tools. Anyway, human role is still fundamental.

I think a third solution is to visualize requirements. For instance, users could present "movies" that illustrate some typical work-flows (if necessary in a dummy GUI). By expanding written language with visual elements, ambiguity can be reduced.

@Luca Sabatucci thanks sir

·

The concept you are planning to work on is really great. Based on my understanding it is true that as long as we are using Natural Language to write requirements, avoiding ambiguity will be mudane. But we can perform some checks to minimize the quantum of ambiguity, like if words like "Obvious", "Always" are given we can check for the ambiguity. Like in case of Obvious the fact should be mentioned based on what Obvious has been used. Similarly when a statement includes always it whould mention the rules and regulations based on what always has been mentioned.

Similarly we can perform check for some more keywords like "maybe", "Should".

But this is not the complete solution for removing the ambuiguity, rather it is just TIP of the Iceberg.

Hope this will give you a platform to think about what can be done next, please do keep informed about the developments.

thank you sir @ Mudasir Kirmani

In a recent publication we have investigated the management of

knowledge in collaborative environments from a semiotic angle.

Besides the non-technical challenges related to the sourcing and

use of knowledge in collaborative software engineering, the need to codify

knowledge for the purpose of making it available to and

transferable between collaborators raises the problem of its

formal and machine-interpretable representation. Our

considerations on the role of semantic technologies brought

about a number of technical challenges that are still to be

resolved. One of these is ontology alignment and semantic

synchronization. Promising approaches in this

respect will have to be further engineered by applying

“knowledge testing” – an interaction with selected individuals to

determine the effectiveness of a selected encoding.

The paper is accessible on the web:

Norbert Jastroch, Thomas Marlowe: Knowledge Transfer in Collaborative Knowledge Management: A Semiotic View. Journal of Systemics, Cybernetics and Informatics, JSCI, Vol. 8/6, pp. 6-11, 2010

This is a million dollar question -- I would like to solve it and so would many researchers in requirements engineering and software engineering. The whole field of using formal model driven design is motivated by this question. The current state of the research is that it is possible to use formal languages to write requirements specifications for most functional requirements, but for non-functional requirements it is much harder to do that -- and I do not know a solution that can do it.

Such a tool had to fully understant natural language ... so you have the answer.

Obviously it is not that simple, Luisa. That's why we were looking, in our work mentioned above, into the subject of codes. Linguists like Eco have pointed out that natural languages are codes; and it should be added that 'artificial', or 'formal' languages - just take the example of process models - are codes, too. This raises the issue of how inherent ambiguities (and other shortfalls) of codes can be reduced. In addressing this issue, over the past centuries a manifold of domain specific codes somehow 'narrowing' the natural languages (obvious examples are natural sciences and their disciplines) have developed. And since decades now we observe the advent of codes, on various levels, in the field of computer technology. One of the questions then is if (and how) software requirements specification can be formalized far enough to overcome ambiguities. That's what I understood is behind Unnati's question, and what Sandeep is touching upon with his comment.

I found so interesting the "knowledge testing"... so if you are able to perform a utopic "software testing" (what is impossible in the present) you are able to automatize assessment of sw requirements...

Moreover, i think so you are forgetting the client participation, in order to attend quality assurance requirements... in use of a natural language it is possible to understand the client requirements, at all? Greetings. Thank you for an interesting topic.

As an aside, it seems reasonable to separate end users (i.e., clients -humans/machines/programs), business, system and at last software requirements, and only then look into how to resolve ambiguities at each level either fully or semi-automatically.

This way the software engineer need only cater for how to specify the software requirements and then somehow certify/validate that the software developed accordingly satisfies the specified specifications.

Business requirements may be specified by business experts themselves and attested by themselves; software engineers may provide them with technical tools and technologies though.

In summary, the separation of concerns simplifies the daunting task of requirements engineering.

This discussion touches upon a number of important aspects to be addressed in software development.

Well-known approaches like the Unified Process suggest a development-focused structure with two fundamental dimensions: the technical (workflow or discipline) dimension, focused on development activities, and the business dimension on staging, timeline and progress.

When it comes to the inter-organizational collaborative aspect of software development and management, this process soon gets multi-dimensional - in particuluar in projects with some or all of the following characteristics: substantial dependences and interactions between partners and between partner components, integration of knowledge management and risk analysis and management is critical, high innovation affecting interfaces or multiple components. It does make sense therefore to explore the extension of the Unified Process from the traditional 2-dimensional model to a multi-dimensional model.

To complement the argument, system and software architects and professionals have favored N-Tier architectures for a long time. Frameworks are good examples. It is wise to consider Organization, Business, and Technology as separate tiers with their own specific issues and concerns and only ensure these tiers integrate all right. Software engineers will then confine their efforts in the Technology part in support of the other two tiers. Each tier may be n-dimensional too. Looking at an IT solution in this way, software engineers become more engaged in how to engineer the software requirements rather than getting stuck in business or organizational issues. Software engineers can work out their solutions say using RSA while business experts require other tools and technologies to model or specify their concerns by themselves (using BMP say). In summary, separation of concerns as opposed to the traditional monolithic way of developing IT solutions, relieves software engineers from complex business and organizational issues allowing them to focus on their own way of developing software in support of businesses and organizations.

Wow! Thanks a lot to both (Norbert and Mohsen) for a great explanation. I am surprised about your summarization capabilitties.

By your explanation I understand that there are a lot of "ambiguities" (like expressed in the initial question), this way I see more and more hardness in underpin software requirements with an "totally" automatic tool. Maybe it will be time to think about a "semi-automatic" organizational memory process in order to recovery experiences from the "experience factory" like suggested by BASILI, V.; CALDIERA, G. Improve Software Quality by Reusing Knowledge and Experience. Sloan Management Review, p. 55-64, 1995. Their model is theoric but i think so they consider (at least in part) your research problem.

Hi,

I am impressed by the comments made so far. I have also found requirements to be a tough area because it touches upon multiple area. Building an automated tool to handle something we have not mastered manually is even harder. Things that are well defined or even semi-defined has a better chance of automation. Requirements usually contain and describe the following elements:

1) functions and features

2) data and information

3) business flow

4) users and User Interfaces

5) other systems and systems interfaces

6) non-functional constraints such as performance, security, quality, etc.

Loook at this list and consider which ones are easy to define and thus easy to automate. You can see that item 6 is extremely difficult to "define".So is item 3, and item 3 is usually defined by a subject matter expert who may speak their own industry specific language while item 2 may be defined more clearly with computer languages, thus more automatable.

Multi-culture, muti-language, multi-organization, etc. makes it hard to automate. But we are trying, and it is hoped that we will make more progress.

Hopefully, this makes sense,

I am also looking for collaborations in researching requirements complexity.

Frank

The following article (Requirements and the Beast of Complexity) may be useful:

http://www.modernanalyst.com/Resources/Articles/tabid/115/Default.aspx?ArticleType=ArticleView&ArticleID=1354

automated support is helping to lessen human intervention but do not resolve the ambiguities issue 100%. We still need human to decide on the ambiguities. A good paper by Bashar Nuseibah et al."Automatic detection of nocuous coordination ambiguities in natural language requirements" is possible to be refered.

This is a great discussion. There have been a few papers around that deal with detecting ambiguity. At one point, Leonid Kof claimed that his tool can detect all types of ambiguities defined by Dan Berry and Eric Kamsties in their "Handbook of Ambiguity".

I also would like to highlight the paper from Gervasi and Zowghi "On the Role of Ambiguity in RE". The authors argue that human language has evolved over thousands of years to include features like ambiguity for a reason. Removing ambiguity is not always good. Some ambiguos phrases are easy to spot by humans and important indicators. Removing them can lessen the quality of a requirements document.

Personally, I did research in tools helping requirements analysts to capture and explicitly document their knowledge on how a good requirements document should look like. The advantage is that tool support focusses on issues their users find important - in a domain specific way. During my research, I never encountered two organizations in industry that would benefit from similar support. Of course they would benefit from some general requirements writing rules. But the domain specific concepts seem to be more valuable.

exactly the domain specific concepts are more important. thanks to all authors that they are giving such a valuable information and share their experience. as per my talk to some of technical person who are currently working as a SRS they still not using such kind of tool.mostly organizations are using UML semi formal representation.they do their work manually and resolve conflict by customer meeting,even more what they mention that their company product is structured such a way that when they are asking or meeting their customer each and every requirements are predefined and the possibility of occurring ambiguity in that is minimize like check lists are maintain for web based applications (that requirements are so specific so there are less scop of ambiguity)if some thing ambiguous then it will be handled through meetings or experts. so is this area is only for study oriented i mean what the core application to apply such thing like in robotics its necessary that it will understand all the commands unambiguously so it will work correctly. it must be completely automated to disambiguate all instructions/commands given to what other core applications where we need completely automated disambiguation tool. what tools are freely available.

Eric, I agree with you. There is people from the User-Centered Design community, who explots ambiguity as an instrument to facilitate creativity and to create a common space of mediation with stakeholders. In my short experience with requirements, I am convinced that natural language IS the laguage to collect and specify requirements, and ambiguity is sometimes a value in them.

Well, it all sort of depends. For many organizations, managing requirements and tracing them is the major concern. Such organizations are afraid to use models, because they seem to be harder to maintain than natural language fragments.

Unnati, I agree that tools helping to reduce ambiguity are easier to be found in science than in practice. This sort of lead me to the conclusion that their perceived value is not too high in industry. During interviews in one organization, I got the impression that this is due to the domain indifference of many tools. Other tools are simply too hard to setup. Other dimensions of this problem are:

- people don't want to be checked by tools and they are allergic against automatic reports on their ability to write requirements send to their managers.

- organizations don't see the value in high quality requirements.

- organizations don't see that automatic checkers could improve the quality with only marginal effort.

Ambiguity as a source of creativity is an intriguing thought. Having visited this years workshop on Creativity and Requirements Engineering at REFSQ in Essen, Germany, it is still not completely clear how creativity and requirements engineering connect.

Very interesting topic. I have worked in the same topic some years ago when I was at the CNR of Pisa. Exists a tool called QUARS that helps to analyze natural language requirements. Following I list some interesting links:

http://ercim-news.ercim.eu/evaluation-of-natural-language-requirements-in-the-modcontrol-project

http://www.computer.org/portal/web/csdl/doi/10.1109/RE.2005.53

http://quars.isti.cnr.it/index.html

http://quars.isti.cnr.it/QuARSreferences.html

Interesting thoughts to be sure, however the need to constrain the vocabulary used to express the stakeholder's needs and goals and the system constraints and requirements is also a critical piece of the pie. In the absence of a structured business vocabulary (SBV) the level of confusion, ambiguity, and incorrect assumptions will rapidly get out of control.

If the statements are not well formed, consistent in their 'pattern', and constrained to a structured business vocabulary it still becomes a case of GIGO.

A good reference to gain a deeper understanding of specifying requirements, the use of taxonomies, and approaches to requirement validation is 'Requirements Engineering' by Axel van Lamsweerde, 2009

Link to the Semantic Notation model for SBV and Rules: : http://www.omg.org/spec/SBVR/1.0/

Further to the literature David recommends above, a worthwhile book touching also on the subjects in question here is:

M. Rebstock, J. Fengel, H. Paulheim: Ontologies-Based Business Integration. Springer, Berlin/Heidelberg, 2008

The short answer is yes it is possible: do not use natural language and only formal one!

Is it achievable? no, usually it cost too much.

What can be achievable? Use simple template like the EARS one (Easy Approach to Requirement Syntax), mix it with simple semantic system like in [1], add assistant, etc.

Concerning the research direction, you should first look at dedicated place like INCOSE, AFIS, IREB, SPECIEF, professional forums on LinkedIn [2], etc.

Look also at the Incose vision 2020 document.

[1] http://www.favaro.net/john/NextGenRE.pdf

[2] http://www.linkedin.com/e/aqdzgd-h6p2s2zh-47/vaq/63839456/2308567/93777543/view_disc/?hs=false&tok=2Q4Rx_OM0Ow5o1

Forward and Reverse Semantic Traceability Tree approach or formal specifications of the requirements can solve the ambiguity

No it is not possibile. In many cases ambiguities are functional to the system. There are tools that helps you to detect ambiguities.Thake a look at: http://www.springerlink.com/content/d141771hn5057h03/?MUD=MP

Some time ago I wrote a paper on ambiguity in software design specifications, based on an approach that was developed for requirements specifications. The approach is based on "organizational semiotics" -- its not about detecting but about specifying in manners that reduce ambiguity. Perhaps this is of interest ...

Gross, D., & Yu, E. (2010). Resolving artifact description ambiguities during software design using semiotic agent modeling. Paper presented at the 12th International Conference on Informatics and Semiotics in Organisations.

Research direction in my view: Any tool will have its own limitations and the requirements to develop a tool is also having lot of subjectivity with respective to the domain and the process followed in differant organisations. By stating the problem tool should have an option with drag and drop options of functionalities to build the ETVX process in a tool based on what to track and how to track. the toll should be in a position to genarate reports dynamically with the dragged fields which is assosiated to the defined process with arthamatic operations and logical filters.

Software Requirement Specifications are those with the client requirements, market requirements & business requirements. These set of information's are manual holding may be existing with mistakes leads to the defect at the time of deployment. This scenario can be revised not by the automation toll meant for functionality & performance testing only.

If interested Software Test Manager tools viz Test Director can be added, but 97% of this stage can be repaired only by manual entry.

Not today or in the near future. Automated tools are far from powerful enough or understanding enough to deal with the complexities of poorly expressed requirements. The requirements should be expressed in the vocabulary of the business and each business, even each company, has different context associated with some of the terms they use.

Yea it is not possible yet but at least we can research for that and that is what I aim to resolve somehow basic ambiguity before generating the formal representation of an informal requirements. so at some level some trust built on such tools and that will reduce some human efforts. As per my knowledge coordination, anaphora are the main issue to deal with can anybody tell me which type of ambiguity in general more occur in requirement specification? Please.....

no - far too much of the meaning of a specification is defined externally in human subject-area expertise

part of the issue is that many technical terms exist in different areas of expertise, and mean somewhat different things - these are not language ambiguities, but expert knowledge ambiguities

of course, if you write a formal model, then it will have no ambiguities (this is part of my preferred approach) - however, it may have other problems (bridging the formal / real gap, for example, or exercizing it agains various scenarios of use, misuse, and partial failures)

i have recently conducted a very small internal research project to determine whether an english language requirements document of the usual sort (even a pretty good one) can be disambiguated without serious expertise and knowledgeable human intervention, and the answer is NO - it needed many experts and much interaction to determine exactly what they meant (and i can't tell you how many times the experts told me ``they know what i mean'')

my advice is to build not only a formal model, but an executable formal model, so that stakeholder scenarios can be examined to reduce ambiguities and incompleteness

I think the question comes in many parts: a) is it possible to resolve ambiguities in requirements specificaations --- I believe the answer is almost yes. There are always paradoxes that can not be resolved. b) using an automated tool --- the answer is --- not quite there, yet.

If we can do this completely with an automated tool, then we can probably generate code from requirements specification. (By the way, you may be interested in looking at the Verified Software Initiative that is going on --- See paper "Behavioral Interface Specification Language" by Hatcliff, Leavens, Rustan Leino, Muller and Parkinson in ACM Computing Survey, June 2012.)

Among others, two major issues here are: (1) The formal representation of the set of specified requirements needs to be isomorph to the structure of the real processes that are subject to the engineering task. This is very much a formal, say, mathematical issue, and far from being trivial in particular in the case of complex systems. (2) The descriptive instruments applied for the presentation and communication of the objects, relations, concepts, processes etc. used for both purposes - the formal representation, and the real system description - each need to be semantically clear and distinct, and there must be a bijective transformation between both. Again, pretty much not a trivial issue.

Software requirements are not manna from heaven but (1) are set in business contexts with identified objects and processes and (2) are meant to be supported by systems with existing applications.

The first step should be to map business backbone (identified objects and processes) to functional architecture before resolving possible ambiguities about features.

http://caminao.wordpress.com/2012/03/01/requirements-strokes/

Let me add my "NO" to the others for several reasons:

ONE: there /intrinsic/ ambiguities where one part of the requirements document (in text or other forms) contradicts another part. This can be relieved by better format management, application of certain logical contracts, and cross-checking tools. It is possible that this form of ambiguity could be removed entirely, but only within the context of the format of the specification not its content.

TWO: there are /extrinsic/ ambiguities where the content of the specification contradicts some fact or situation external to the document. There is no way to removed this ambiguity automatically since any check must necessarily use another source of knowledge and there is no way to check that source of knowledge for the same reason. This is a subset of a well-discussed issue in epistemology

THREE: The external world itself can be and is ambiguous and contradictory. One only has to have two customers to obtain requirements which conflict.

FOUR: All native language is ambiguous. The dictionary definition of the indefinite article "a" defines it as meaning "one and only one" and also "an example of." So if a specification states "This system shall have a function key" is that one or more than one? While more specific descriptions (such as specifying "one and only one" instead of "a" or including a graphic) which show which solution is required will help, the specific description itself is subject to ambiguous interpretation (by "one" does it mean a /specific/ one, or simply the integer 1?)

First, we start from an ambiguos text. So no tool can interpret an ambiguous text. Before using an automated tool, we have to discuss first with users, customer, stakeholders in order to understand requirements in deep and after that we can see how to integrate a tool in our process.

No such tool exist today. Becaus of the complexity of the problem. The problem depends on the complexity of natural languages and the complexity of communication among people.

Solving such a problem formalizing communication is one possible way. But reading and understanding of specification will become much harder. To avoid this, using domain specific languages to define an allowed syntax and grammar is required. The readability of the specification will increase and you have the possiblity to "understand" parse most of the requirements. With the underlying model it should be possible to define constrains to detect ambigous requirements. In case you cant decide those requirements should be marked to dusicuss with your stakeholders.

By using the described technics its today possible a semiautomaic processing of requirements.

Hi,

In the extreme situation, we know from theoretical computer science that we can NOT resolve if "two programs are equivalent (Rice's Theorem)." Thus the general case --- "can we resolve ambiguities in software requirement" --- is NO.

But , in many practical situations we can get close to it. That does not mean we are already close. In fact, we still have a ways to go. As for automated tools --- that only comes after we have the manual methodology and process worked out.

Hope this helps. Frank T.

Having been on both the 'builder' side and the customer side of software requirement specification development process, I can honestly state that even the most clearly written software specifications that map to business/system requirements very well will still be ambiguous because all human languages (especially English) leave elements that can be interpreted in multiple ways. Even the automated language translators (Like Babelfish) have a (small) percentage of expressions that cannot be fully expressed or translated into the target language.

Software requirement specification is a human activity that requires continual negotiation between the developer and the customer to ensure that the requirements map to the operational performance required by the system. There are layers of understanding that the customer must convey to the developer, while the developer must convey the capability of the software with respect to the problem domain. There are even issues that are not-well understood by eother side that must be discussed and agreed upon jointly. No software tool can 'guess' that the phrase, "the system must provide output in human-readable format ..." simultaneously means that the user wants to have the output available: on the computer display screen; in a *.pdf file stored in a directory, and; in hardcopy format (by printing the screen capture or the *.pdf file). Only a human can elicit those details from the customer, as this cannot be determined by an automated software tool.

We have been working on related subjects - integration of (semi-)automatic tools in the software engineering process for the capture and use of artifactual knowledge - and will present some findings in a paper "Integrated Infrastructures for Knowledge-Guided Software Evolution and Adaptation" at the forthcoming SEDE 2013 conference in September.

Unnati:

Interesting question.

"Is it possible to resolve the ambiguities in software requirement specification completely using an automated tool?

If yes what tools are available ? If no, what can be the research direction?"

The answer depends on an number of factors.

One issue is the type of ambiguities. In many cases software specifications are legal contracts, which makes them a bit different than most technical documents. When these types of system issues are addressed the differences between three types of truth become apparent. One type of truth is formal truth based on logic. Another type of truth is factual truth based on facts. And a third type of truth is value based on judgement.

If the automated tool allowed the inclusion of specific empirical data and/or human reasoning to be combined with non-human intelligence then some progress could be made toward reaching these types of goals.

At this time, it may be productive to look at an automated tool that focuses on analysis and evaluation of specifications and highlights issues to be addressed by human based decision makers.

Take care, be good to yourself and have fun,

Joe

Completely? I doubt that could ever be accomplished. However can we make improvements, yes very easily.

I previously was a software developer who was asked to reverse engineer the requirements for a fast tracked application. The first effort someone else performed resulting in a design specification rather than a requirements specification.

I have since been working in the requirements engineering fields for several years now. One of several significant events in my experience was learning to use the concept of Structured Business Vocabulary (http://www.omg.org/spec/SBVR/) as a way to constrain the vocabulary used within requirement statements. Additionally I ensure that my analysis models are also constrained by the SBV (of course this is an interative process).

Another important concept to understanding how to resolve the ambiguity is clearing understanding the intersection of the business world view with the solution world view (see Lamsweerde's book on Requirements Engineering - http://books.google.com/books/about/Requirements_Engineering.html?id=AYk_AQAAIAAJ) This also helps understand the difference between software requirements and system requirements very clearly.

I have for several years been using UML modeling tools (specifically Enterprise Architect by SparxSystems), along with the high-level concepts from the SBVR work and concepts of requirement patterns and requirement statement templateds to develop a model-driven approach to the generation of requirement specifications.

These types of approaches have dramatically reduced ambiguity and also has radically changed the amount of time between gathering information from stakeholders and turning around both visual and textual representions of the requirements from these sessions.

I have started a project on RG to share some of this information and work through a fragment to get feedback on my approach. Feel free to join in :)

David

Garbage in, garbage out ...

Ambiguities in software requirements are rooted in "real life" contexts and concerns, as expressed by the semantics of users.

Hence, if tools are to be useful, raw inputs must be translated into models that can be checked for external (how contexts and concerns are represented) and internal (modeling language used correctly) consistency.

http://caminao.wordpress.com/how-to-represent-objects-and-activities/quality/languages-models/

http://caminao.wordpress.com/how-to-represent-objects-and-activities/quality/external-consistency/

thanks to all  for the information "What could be factors for comparing different approaches/tools that resolve ambiguity ? is recall and precision are good measures? or anything else"

Software Requirement specifications are those to be analysed in relation to the user needs. Here all to be noted according to that scenario in which the user is currently existing. Here we cannot use any tool that may give an accurate result, than the Human study. As requirements are dynamic till the end we cannot use any tool for this event.

It is very interesting topic, to deal with validation of SRS I would like to suggest:

- Survey the all techniques of modeling SRS;

- Provide an example of ambiguity in each technique and how people tried to solve it (from literature).

- Then choose one technique, with justification, and start working in it.

You can not solve the ambiguity in all models of SRS just by one solution. Put in mind, diffrent companies are using diffrent SRS modeling techniques.

Not at all, some tasks cannot be fully automated

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.Oct 4, 2019

https://danikahil.com › 2019/10 › d...

Dealing with ambiguous requirements - Dani Kahil

https://www.researchgate.net/publication/281854022_Resolving_Ambiguities_in_Natural_Language_Software_Requirements_A_Comprehensive_Survey,kindly follow this link.

https://ijicis.journals.ekb.eg/article_15909_f00056431303fe37b49c06290f0095eb.pdf,this link may be useful.

https://www.academia.edu/17563136/Resolving_Ambiguities_in_Natural_Language_Software_Requirements_A_Comprehensive_Survey,moreover this link.