• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

easy and effective way of identifying classes from Requirement Document.

 
Ranch Hand
Posts: 594
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 .
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Write use cases from requirements, and do use case realization.
You can select nouns from use case to be Class candidates.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 594
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 594
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic