I am wondering if you or the authors of the book could possibly provide me with some feedback:
By the beginning of November, I have to give a short presentation concerning the PROBLEM STATEMENT. Reference is hereto made to your sample chapter 3 on use case modelling, which is very good.
Now, on Saturday, I searched for several hours on the internet for research papers as well as on the ACM where I am a member on this topic. Interestingly, there is little information in this field that would address questions like:
- why is a problem statement critical?
- what are its benefits?
- what are drawbacks?
- how to make / write a problem statement?
- who should make a problem statement?
- do bullet points suffice? or should it encompass whole sentences?
I came across some information in the field of SSM. However, I see drawbacks there because from an engineering standpoint, it is critical to avoid vague and open requirements. The only interesting approach may regard the CATWOE approach.
Now, going on to a deeper level, I think that we may even argue that a PROBLEM STATEMENT does not only cover a use model but covers use case models. Working in a large project with a complex (legacy) system, requirements by business cover different areas. One may counter argue that these areas may refer to (use case) packages. However, as soon as subject domains change, I think it would they are rather use case models that can consist of packages.
This thought leads us to hierarchies within subject domains now. Do we subgroup problem statements? Moreover, can we also argue that a use case description is by itself its own problem statement?
If, of course, we merely regard simple ATM system as problem domain, it suffices to only have one problem statement from where we can derive use cases. However, as soon as we change the focus onto large systems, we meet a different angle and reach an enormous level of complexity.
So, I am wondering if you possibly dispose of some more information? Also, although the field of problem statements/textual analysis were hot in the 70’s when even programming languages were developed, it seems to me, that this field leaves space for research.
Any input and maybe even articles or copies of statements with sources would deeply be appreciated.
Anyway, the features that VP UML provide are great and I feel that there should be great potential in this sub domain.