How to find requirements/use case

[ebeb]

Geert,

I begin to understand...The realization relationship means, that the use case "inject some life" into the more technical stripped down description of the requirements by introducing real-life cases. But does not mean that it must be designed after the requirements.
Is that what you mean?

[Geert Bellekens]

Yes, that is basically what I meant.
(I wouldn't have use "inject some life", but I guess that as good of a description then anything else  )

Geert

[Paolo F Cantoni]

[size=18]...[/size]
But does not mean that it must be designed after the requirements.
Is that what you mean?

Yes, Exactly...  The Use Case view of the model needs to consistently match ALL the other views of the model.

So as the relationship between certain elements changes, the relationships expressed in the Use Case view must also change.

Unfortunately most modelling tools don't provide the amount of support to make this "transparent" to the modeller and (to some extent) it may be dependent upon the specific modelling methodology that you are using.

The beauty of using a modelling approach is that it doesn't really matter WHERE or WHEN you start just so long as you keep what you have modelled self-consistent.

I've coined a phrase "Stop muddling through - start modelling through ^TM".  

Paolo

[Oliver F.]

the output artifacts of one process become the input artifacts of another...  They don't become requirements!

OK, then I give the use cases to an external subcontractor in India and order tested code based on those.
I am the customer delivering my requirements as a customer described by use cases which I then check back again in a system test against the use cases I delivered as requirements. So here we are again.

In a global and distributed development setup it is often not convenient to rigorously stick with terms which might lead to confusion. The term "requirement" has a different meaning if used in project workflow and analysis.

Oliver

[Paolo F Cantoni]

OK, then I give the use cases to an external subcontractor in India and order tested code based on those.
I am the customer delivering my requirements as a customer described by use cases which I then check back again in a system test against the use cases I delivered as requirements. So here we are again.

With respect, Oliver - no we don't.  When you send use cases to the external subcontractor, your requirement is "that they create and test the code in accordince with the specifed use cases".  The use cases are NOT the requirement - they are specifications.

In a global and distributed development setup it is often not convenient to rigorously stick with terms which might lead to confusion. The term "requirement" has a different meaning if used in project workflow and analysis.

Oliver

Again, in my experience, in global and distributed environments; NOT rigourously sticking to definitions and ensuring up-front that both sides understood the same thing by the terminology was specifically the cause of problems.  I told them this up-front but, as usual, they chose to ignore my recommendations - later it was TOO late (too much face to save).

A misunderstanding over a single term can cont millions of dollars.  It doesn''t take THAT much effort to start specifying your vocabulary - but that means you're THINKING and not DOING - a ciminal offence in most management's books (principally, because if they are light enough on their feet - they will be gone before the rest of us have to put up with the consequences of their failures).

Paolo

[Oliver F.]

With respect, Oliver - no we don't.  When you send use cases to the external subcontractor, your requirement is "that they create and test the code in accordince with the specifed use cases".  The use cases are NOT the requirement - they are specifications.

For the subcontractor the specification is the requirement. Not in terms of analysis but in terms of project management and work flow.

Oliver

Again, in my experience, in global and distributed environments; NOT rigourously sticking to definitions and ensuring up-front that both sides understood the same thing by the terminology was specifically the cause of problems. [/quote]

Of course we agree both that a common wording and terminology is crucial for project success.
I am not advocating to violate this rule. However I am advocating to take a closer look at the terms and the scope in which those terms are used. Otherwise surprising results can occur. "Everybody knows what is meant by requirements and what is meant by a UC?" will lead to a nodding of heads on all sides but the project manager will still have a different view than the analyst depending on the scope they are in.
Dialogs like

"What sort of input requirements do we have?"
"Use Cases"

are very likely to be heard in this scenario.

Oliver

[Dave.B]

My two penny worth is that I would align myself with Oliver. The word "requirement" can mean any type of requirement that the product under development must fulfil. The customer may state it, or the engineering team may deduce it or impose it.

We start with the user or customer view point and have user requirements as input. We do some form of requirements analysis to understand what we are being asked to do. We can use Use Case analysis methods for this purpose (although this is not the only technique available to us). Out of this analysis we arrive at the System Requirements (functional and non-functional).

The System Requirements are the input to the design teams (hardware, software, validation). The design teams make design and technology choices. This leads to new design requirements (that cannot be directly traced to the user requirements), and they make architectural and implementation choices that contribute directly or indirectly towards the realisation of the System and hence User Requirements.

The analogy here is client-server where the server can be a client to other systems and so on.

An engineering process step (IDEF0 style http://en.wikipedia.org/wiki/IDEF0) has inputs and outputs. The inputs can be requirements and the outputs (whilst also being considered to be engineering artefacts) can also be (derived) requirements.

This detailed view of the requirements tree is required by those of use working with engineering processes that have to demonstrate requirements traceability down to components on a board and lines of source code (and sometimes even the op codes). I don't doubt that agile and other customer centric methods can dispense with the need for rigorous requirements traceability and still be successful. The difference is that that sometimes the engineering rigour that has been applied has to be demonstrated retrospectively to an auditor and one of the many things that they require is good (to complete) requirements traceability.

Hope this helps
Dave B.

[paddler]

As Geert is in Belgium - which happens to have some of the world's finest beers - I suggest that we all convene in belgium to try and solve this

 As for me, I think it is MOST IMPORTANT to agree with your client and those on your immediate development team what the language of the project will be..As was suggested earlier, a Glossary is most helpful. If you cannot agree what is what on the team...all is lost.

 Once everyone agrees on terminology for requirements it's up to the analyst to get from the "high level wish list" of stated user and functional requirements ( which may be dated and need to be dusted off) down to a set of artifacts that can be handed off to design to implement.

 In my own experience of late I have worked with other BAs to take the high level client needs/ requirements,  document mockups and Use Cases that show how the system will meet their high-level needs and, finally ( and most interestingly) document and validate **NEW** requirements that are found in the course of domain or use case modelling.

 I am following Geert and others on this one that requirements ( whether handed down from on high or discovered during analysis) may change and that Use Cases are tremendously helpful at documenting behavioural requirements and also demonstrating how system behaviour will realize or implement the original requirements.

 Good articles I have referenced include:

 "practical Software Engineering" - Enricos Manassis
 "10 requirements Traps to Avoid" - Karl Wiegers
 The ICONIX SW website


Good bye from soon to be snowy Canada  

[KP]

"10 requirements Traps to Avoid" - Karl Wiegers

Article is here: http://www.processimpact.com/articles/reqtraps.html.

Also take a look at "Domain Driven Design" by Eric Evans for an understanding of how to get all stakeholders talking the same language.

[Paolo F Cantoni]

...Also take a look at "Domain Driven Design" by Eric Evans for an understanding of how to get all stakeholders talking the same language.

I heartily endorse Neil's suggestion.

In fact, I've gone so far as to attempt to include Ontological models to create Eric's "ubiquitous language".   Ontological models sit above the OMG CIM (Computationally Independent Model - AKA "Conceptual Model).

Paolo

[Geert Bellekens]

We can always trust on Paolo to extend our vocabulary and improve our understanding of the English language.

Word of the Day

Ontology(computer science) a rigorous and exhaustive organization of some knowledge domain that is usually hierarchical and contains all the relevant entities and their relations

In all the modelling methods I've worked with at different clients we define the Ontology as a part of the BIM (Business Information Model). The elements that make up this ontology are defined as Business Information Item (or Business Concept at another client) and define the terms and vocabulary of the business domain with special attention to synonyms and homonyms.
If you want to go even further you can make a distinction between Business Information Items and Business Objects.

Business Objects are derived from the Business Information Items are
are typed to their nature (not how they are used).
In the Business Objects the synonyms are not allowed anymore and every Business Object should be formally distinct from other Business Objects. This means that you cannot have two Objects that represent the same thing but used in a different way. (e.g. you are not allowed to have different objects for "Local Train" "InterCity Train" because they all represent the same "Train" object that just uses a diffeent type of route)
In other words, a Business Object should not be able to change type in the course of its lifetime.
Business Objects (or Business Information Objects if you don't have Business Objects) are CRUD-ed by the Business Processes, to which usecases can then be related.

I don't really see why Paolo puts this above the CIM, for me that is just part of the Business Model and the CIM.

But Business Objects or Information Items model elements from whithin the business domain described, they do not contain entities related to domain of "Modelling" such as a "requirement".

For me things like "Requirement" and "Use Case" are part of the Meta Model.

The Meta Model describes the different types of elements used in modelling (so Business Information Item and Business Object are defined in the Meta Model) as well as the (development) process that allows us to create the model (and ultimately the system).

Whenever I start at a new client, the first thing I do is look for the Meta Model to get an understanding of the way they work.
In most cases however I wasn't very successfull in finding it, and started creating it myself. :-/

So, to summarize for those who are too lazy to read the whole essay, Requirement and UseCase should be formally defined in the Meta Model which is agreed and understood by all stakeholders.

Geert

PS.

Belgium - which happens to have some of the world's finest beers -

FTFY  

[Paolo F Cantoni]

[size=18]...[/size]
I don't really see why Paolo puts this above the CIM, for me that is just part of the Business Model and the CIM.
[size=18]...[/size]

Because, I'm just defining terms in the OM.

Everything Geert says in the rest of the posting is correct and there is a very great correlation between the OM and the CIM, but the relationships in the OM are not the same as those in the CIM.   They're about (what you'd find in dictionaries and thesauri) the general relationships between the terms (synonym, antonym, alias, acronym, related etc).

Literally, I'm trying to define a ubiquitous language.

In general, the definition of an element in the CIM is identical (or an extension to) to that of the eponymous (not exactly the right word, but Geert likes to look words up  ) term in the OM.  We use the OM to generate glossaries with linkages between the terms.

HTH,
Paolo

BTW: House uses "Ontology" - I think in series 4, in one of the later episodes.

[Geert Bellekens]

[size=18]...[/size]
I don't really see why Paolo puts this above the CIM, for me that is just part of the Business Model and the CIM.
[size=18]...[/size]

Because, I'm just defining terms in the OM.

Ah, I see.
That is exaclty the difference between the "Business Information Items" (glossary) and the "Business Objects" (real entity model) in my explanation.
We just put those next to each other in the CIM
in general Business Objects will be derived from (one or more) Business Information Items.

OK, I'll bite  

ubiquitous

existing or being everywhere, esp. at the same time; omnipresent

eponym/eponymous

An eponym is the name of a person, whether real or fictitious, after which a particular place, tribe, era, discovery, or other item is named or thought to be named. One who is referred to as eponymous is someone who gives his or her name to something

Geert

[Paolo F Cantoni]

Ah, I see.
That is exactly the difference between the "Business Information Items" (glossary) and the "Business Objects" (real entity model) in my explanation.

I'm not so sure...  (But we don't seem to be too far apart)

In your example, are you saying that Local Train and InterCity Train are NOT Business Objects?  In my modelling of the CIM, I would have two such object, both deriving from Train (allowing for the usual requirement that according to the "duck" principle - they aren't both the same duck - that is they either have different attributes or relationships in one state or the other).  

Certainly, by using Generalization, they are both Trains.  But whether or not the distinction between them need exist depends on the Domain of Discourse.  For some domains (applications) you only have one object: Train, for others you may need all three.

In the OM, we'd always have all three.  Since they are terms in the General domain and (presumably) we came across them in some document or discussion of the domain.  In the OM, we'd make the point that we either needed the term or not in the domain of discourse.  If we don't need the term we'd put a link in to the appropriate term to use in its stead.

We just put those next to each other in the CIM
in general Business Objects will be derived from (one or more) Business Information Items.

Business Terms might be a better name for the second concept.  Since, I believe, if you provided any more information (other than a definition and ontological links) you're creating objects of some kind.

Thanks for helping me clarify some thinking in this area!

Paolo

[Geert Bellekens]

Domain of Discourse[/i].  For some domains (applications) you only have one object: Train, for others you may need all three.

Yes, Local Train and Intercity Train are not allowed as business objects, only the Object train.
I'll explain. Here in Belgium the local and intercity trains are actually the same vehicle. The train may be used today on an intercity route/schedule, and tomorrow on a local route/schedule.
They are, as you state it, the same duck. (today the we call it a "Long Distance Duck" because if flies from Perth to Sydney, and tomorow we call it a "Local Duck" because it doesn't want to leave Sydney anymore).
In the OM the terms Intercity Train, Local Train and Train all exists and get a nice definition.

Geert