*
The moose likes OO, Patterns, UML and Refactoring and the fly likes  easy and effective way of identifying classes from Requirement Document. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark " easy and effective way of identifying classes from Requirement Document." Watch " easy and effective way of identifying classes from Requirement Document." New topic
Author

easy and effective way of identifying classes from Requirement Document.

jacob deiter
Ranch Hand

Joined: Apr 02, 2008
Posts: 576
I want to know easy and effective way of identifying classes from Requirement Document.
I do not believe UML diagrams are really helpful and do not want to invest much in UML diagrams .
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Write use cases from requirements, and do use case realization.
You can select nouns from use case to be Class candidates.


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
There is no "easy" way to do that. The translation from the problem domain (the requirements) to the solution domain (the software design) is a highly creative act that needs a lot of expertise. That's the main reason programmers/designers are paid so well.

The requirements simply aren't the only forces on a software design. Other's include extensibility, maintainability, testability, scalability, to just name a few. For that reason, simply using nouns from use cases, while deceptively simple and straightforward, is also naive and will typically lead to much less than optimal designs.

See http://www.objectmentor.com/resources/articles/CoffeeMaker.pdf for an example of the difference between a "naive" and a solid design; and http://www.informit.com/articles/article.aspx?p=30664 for a more elaborate example of a solid design approach.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Nouns from use cases are just Class "candidates", we shouldn't create classes from all nouns in use cases.

There are many ways to identify classes but the question of this topic to how to identify from requirements.
And just plain use cases may be not enough, we may need to do Use-Case Analysis task like supplement use case description (add information to use case for finding classes). We can also identify classes from "behaviors" in use cases.

Actually, we can define classes not only from requirements, we can define from the "nature" of the domain we're working on (Domain-Driven Design). I prefer DDD rather than Requirement-Driven Design.

I don't design from requirements because requirements will change, but I design from domain, and domain is hardly to change. Anyway, this is off topic.
jacob deiter
Ranch Hand

Joined: Apr 02, 2008
Posts: 576
Kengkaj Sathianpantarit wrote:Nouns from use cases are just Class "candidates", we shouldn't create classes from all nouns in use cases.

There are many ways to identify classes but the question of this topic to how to identify from requirements.
And just plain use cases may be not enough, we may need to do Use-Case Analysis task like supplement use case description (add information to use case for finding classes). We can also identify classes from "behaviors" in use cases.

Actually, we can define classes not only from requirements, we can define from the "nature" of the domain we're working on (Domain-Driven Design). I prefer DDD rather than Requirement-Driven Design.

I don't design from requirements because requirements will change, but I design from domain, and domain is hardly to change. Anyway, this is off topic.


How the domain is differ from requirement?

As per my understanding, domain is the business for which software to be build?

Requirement is, what the user of the application expect from the application
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
jacob deiter wrote:
How the domain is differ from requirement?

As per my understanding, domain is the business for which software to be build?

Requirement is, what the user of the application expect from the application

You're right. A problem of requirements driven is who give the requirements might not be a domain expert. The requirements might not be really correct (it is only correct from requirements teller's point of view).

Analysis and Design based heavily on requirements are fragile, because of the followings:
1. Requirements *might* be incorrect (All stakeholders may think it's correct, but actually it's not).
2. Requirements will be changes/extended/added.
3. Requirements may capture only some parts of domain, and it's possible that requirements doesn't capture the most important concepts of the domain.

In order to apply DDD, we need domain experts, but in the case that domain experts are not available we can still study domain concepts from other resources like books, articles, people who have some expertise in the domain (but might not be experts yet).

Actually I believe experienced designer will not design software based only on requirements, because it's a fact of life that things will change, but it's impractical to change design every single time that the requirements have changed.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Software designs should be based on business requirements and non-functional requirements. Ideally, designs should be agile (strong) enough to easily handle minor and medium changes in requirements. The goal then is to get the "right" requirements from the beginning and hold off on starting any design/programming until this point.

However, programmers are eager beavers and typically don't have the patience or dicipline to wait. When left alone, they create brittle, unmaintainable and unextensible software.

Designs based on anything other than business and non-functional requirements typically produce buggy or unusable software, and result in failed projects.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
James Clark wrote:
Designs based on anything other than business and non-functional requirements typically produce buggy or unusable software, and result in failed projects.

I might not be clear enough. Doing DDD doesn't mean we will completely ignore requirements, we are still interested in requirements, but we focus more on domain concepts. How can we tell that we have "right" requirements, if we don't know (or don't care) about domain concepts?

And even if everybody agrees on the requirements, it doesn't mean that the requirements are "right", it just means everybody agrees on something which can be wrong. And requirements will be changed, even if today the requirements are right, tomorrow it mightn't.

I recommend everybody who is interested in software design to read Domain-Driven Design. From my experience in applying DDD, several times when requirements have changed/added I don't need to change any design, it's not because I know the future, but it's because the design driven by domain can cover unknown requirements.
jacob deiter
Ranch Hand

Joined: Apr 02, 2008
Posts: 576
Kengkaj Sathianpantarit wrote:
James Clark wrote:
Designs based on anything other than business and non-functional requirements typically produce buggy or unusable software, and result in failed projects.

I might not be clear enough. Doing DDD doesn't mean we will completely ignore requirements, we are still interested in requirements, but we focus more on domain concepts. How can we tell that we have "right" requirements, if we don't know (or don't care) about domain concepts?

And even if everybody agrees on the requirements, it doesn't mean that the requirements are "right", it just means everybody agrees on something which can be wrong. And requirements will be changed, even if today the requirements are right, tomorrow it mightn't.

I recommend everybody who is interested in software design to read Domain-Driven Design. From my experience in applying DDD, several times when requirements have changed/added I don't need to change any design, it's not because I know the future, but it's because the design driven by domain can cover unknown requirements.



i am really confused

a application should fulfill the requirement only,If the some part of the domain may not be wanted in the application by "Business Group",then that should be implemented by Domain Driven Design?,

"several times when requirements have changed/added I don't need to change any design, it's not because I know the future, "


this point again confuse me ,how you do not change the design if the requirement change,then how your application satisfy the "Business Group" expectation ?

but it's because the design driven by domain can cover unknown requirement


this mean to say that Domain Driven design implement all the thing which are not needed by "Business Group"??

then is it kind waste of resources???

i am really confused ,please tell with real time example ,what is the difference between requirement and domain,
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
In short, design is not the same as implementation. If requirements have changed, we have to change *implementation*, but we may not need to change design.

We "implement" only in scope (requirements are input of scope), but our design can be requirements-change-tolerance.

It's difficult to explain all concepts of DDD in this topic, the book written by the DDD expert, Eric Evans has more than 500 pages. If you're interested you should read DDD.

If you don't want to buy the book yet, I suggest to go to Google Books Search, search Domain-Driven Design, and read Chapter 8: Breakthrough.
You cannot read every page, but you should get some idea.
 
jQuery in Action, 2nd edition
 
subject: easy and effective way of identifying classes from Requirement Document.
 
Similar Threads
UML tools?
Reverse Engineering from code
Domain Model First or Use Case
Generating Sequence Diagrams for all methods?
Need answers!!