In software developers, the most important phase is the determining the level of mutual understanding

between the customer (stockholder) and project developer.

In this paper it is proposed an approach towards establishing a shared understanding between customer
and developer[1] centered on a process- model whose iterative series of actions – elicit, generate,
validate, refine – ultimately transform (often) vague initial problem statements into system models (Use
Case and Sequence Diagrams) from which acceptable user requirements can be subsequently extracted
In this paper we propose an approach towards establishing a shared understanding between customer
and developer centered on a process- model whose iterative series of actions – elicit, generate, validate,
refine – ultimately transform (often) vague initial problem statements into system models (Use Case and
Sequence Diagrams) from which acceptable user requirements can be subsequently extracted

Since qualitative research is mainly focus on understanding of underlying reasons, opinions, and
motivations, and provides insights into the problem or helps to develop ideas or hypotheses for
potential quantitative research, although we can see this paper used a case study method as data
collection we observe this type of research is qualitative[2] research.

This article the author tries to achieve to ensure customers and users remain within the loop throughout
for validation and refinement purposes. The requirements generation action is achieved by means of a
rule-based approach that yields ‘first cut’, interim iterations and ultimately final (approved) they used
Case and Sequence Diagrams respectively. To validate their work, they used an airline reservation
system case study.

This gives research clear and understandable result to the readers.

In this research its also proposed what so called requirement engineering model to aid both the analyst
and customers in discovering the precise problem to be solved (leading to a shared vision of the final
product); and, to produce system models that accurately reflect this problem from which Following this
restructuring, its manually apply a natural language processing technique, known as Part Of Speech
tagging - the practice of adding interpretative linguistic information to a piece of text categorizing each
word by labeling it as a noun, verb, adjective preposition, etc.2 Next its applied novel rules that are
intended to help classifying sentences into parts and extracting the contents of the diagram from the
sentences towards later generating their visualization as Use Case and Sequence Diagrams.

Finally the generated requirements models are documented, before a prototype (or prototypes) is
developed to confirm that all stakeholders have indeed a shared understanding of the proposed system

About the contribution the author displayed three main activities namely; stakeholder meetings,
generate users’ requirements models, and prototyping. After identifying user problem statements, the
first step is generating Use Case and Sequence Diagrams. In their approach they captured high level
functional requirements for the system, they also established system boundaries and identify which
stakeholders interact with which parts of the target system. Naturally the entire process is iterative;
once the processed requirements meet the customer’s needs, they will be considered as fully
documented user requirements, otherwise the problem statement will be manually refined, re-
approved by the customer and filtered once again to extract further requirements, find missing
requirements and remove inconsistencies.

To realize this process (i.e. generating the two types of diagram, Use Case and Sequence), they applied a
natural language processing technique known as Part of Speech tagging, in conjunction with their novel
rules. That is once the user problem statements (NL text) have been manually re- structured by system
analyst/engineer, the next step is to Perform to determine the morphological structure using PoST to
categorize sentences into parts such as; subject and predicate when generating Use Case diagrams, or
differentiating into subject, predicate, and indirect object when generating sequence diagrams.

Finally, the contribution of their proposed approach is to addresses misunderstandings among

stakeholders by developing a basis for automating and extracting Use Case and Sequence Diagram
requirements models from user problem statements.

Conclusion:

About the intended future work of the research, the author Noted that the approach described is
theoretic and technology independent and so leaves open the possibility of being automated using
whatever combination of tool/languages are familiar to the stakeholders involved. As such it provides a
basis towards addressing many factors that may derail a new system development, such as identifying
missing requirements early, resolving stakeholder conflicts through stepwise refinement, identifying
inconsistencies in problem statements and of course, greater customer involvement in the requirements
process.

References:

`
[1] Paul Mason, Salah Ali Towards Shared Stakeholder Understanding of Requirements
Models: A Rule Based Approach to Text Processing of Problem

[2 ]Boehm, B. W. (1981). Software Engineering Economics.

Englewood Cliffs, N.J., Prentice-Hall.
[3]Van Lamsweerde, Axel, and Emmanuel Letier. "Handling obstacles in goal-oriented requirements
engineering." Software Engineering, IEEE Transactions on Software Engineering, 26.10 (2000): 978-1005.
[4] Peters, L. (2003). Educating software engineering managers. CSEET’03