There have been many proposals for identifying objects, ranging from Coad's extraction of nouns from the SRS to Wirfs-Brocks extraction of roles from the problem space. In my experience the best way to define objects is through an object blitz. The basic object blitz process is described below. Any or all of the various methodologists' techniques can be employed in an object blitz for identifying object candidates.
The reason I prefer blitzes is because it is a team effort. I strongly feel that identifying problem space entities to abstract should be a team effort because it merges multiple views of the problem space and the exercise itself is a strong tool for creating a common consensus on problem space semantics among the team members. In fact, I regard the object blitz as more of a consensus-building exercise than a formal design activity.
However, to be effective the blitz must be a disciplined activity. It is precisely because different team members will have different perspectives that care must be taken to avoid pitfalls like lengthy digressions and personal views. Therefore it is imperative that the blitz be led by someone familiar with the process who can guide the discussions effectively. It is also important to time-box some of the activities. The process described below is based largely on well-established techniques for consensus building.
The ideal setting is a large conference room with a large whiteboard. Several pads of 3x5 Post-Its and a bunch of pencils will be necessary. A good eraser is also important. A side easel with a pad (aka the Parking Lot) to record deferred issues is handy but any recording medium will do. The basic steps are:
(1) Explain the ground rules. This is for the benefit of anyone who has not done a disciplined blitz before. The basic process and the rules are briefly described.
(2) Identify preliminary candidates. This is a free-form exercise and it is the core blitz activity. People offer stream-of-consciousness suggestions for entities to abstract. Each suggestion is recorded on the whiteboard. There should be no discussion and each suggestion should be accepted without prejudice. It is important that people not be inhibited when offering candidates so accept everything, no matter how silly or pointless. The entire exercise should take no longer than fifteen minutes and it will typically start to run out of steam after 6-8 minutes.
(3) Preliminary screening. The goal here is to eliminate duplicates or candidates that are clearly irrelevant, attributes of other objects, and whatnot. This is just a screening so if there is any doubt the candidate remains. It is also a free-form exercise in that anyone can suggest removing a candidate. Any discussion should be limited to no more than a minute per object; if there is no consensus to dump it, it remains. The survivors are each written on a Post It and tacked to the whiteboard.
(4) preliminary binning. Each of the remaining objects is evaluated one at a time. Whoever suggested it provides a sentence or two to describe the basic semantics of what the entity is and how they feel it is relevant to the problem in hand. The goal is to bin the object into one of four categories: Essential, Probable, Unlikely, and Removed. The categories represent how important the object is to the problem in hand. The goal is not to get the semantics right yet; this is just a prioritization process. Any discussion should be limited to a minute or so. If consensus can't be reached between two bins, put it in the higher importance bin. The whiteboard is divided into the three survivor bins and the Post Its are put in the appropriate section.
[A very viable alternative is for the team to do the binning. Each person takes a small pile of Post Its and bins them. The team then mills around the whiteboard to validate the binning. If someone wants to move a Post-It from one bin to another they should state aloud that they are doing so and why. If there is consensus, it is moved. The discussion should be time-boxed as above with the same tie-break.]
(5) Semantic definition. Whoever suggested each surviving candidate fills out 1-3 sentences on the Post-It to describe their view of object semantics. The Post Its are then returned to their bins. This is done in parallel and usually takes about 15 minutes. Do not describe what it does or what it knows except in the most general terms; in this exercise one describes what the underlying problem space entity is. This sort of description is often called a mission statement.
(6) Scrubbing. When all the Post Its are done they are reviewed one at a time, starting with the highest priority bin. The author's definition is read by the moderator and the team comments on possible changes. Time-box discussion to 5 minutes for highest, 3 minutes for Probably, and 1 minute for Unlikely. The Post-It is modified by the moderator as consensus is reached. If consensus cannot be reached, it is moved to the Parking Lot.
(7) Deal with deferrals. Issues may be raised about the actual requirements and the problem space during discussions. These go on the Parking Lot along with the objects for which consensus could not be reached. If time allows, some or all of them may be dealt with at the end of the blitz. Priority should be given to resolving object semantics. If all the deferred items cannot be dealt with, another meeting is scheduled. There may also be action items for the deferred items resolution before the meeting.
IMO, the most effective way to resolve lack of consensus on object semantics is to have a domain expert present during the blitz. When in doubt defer to the domain expert's view of what the entity is. If a domain expert can't be present, there should be a means for contacting one to review the contentious objects before the next meeting. In those very rare situations where a domain expert is not available, some other mechanism for conflict resolution will have to be defined before executing the blitz. That is, the blitz must be able to resolve all the issues somehow before proceeding further with the design. More important, that mechanism has to avoid acrimony.
Note that there was no mention of identifying knowledge and behavior responsibilities. Trust me on this that doing the object semantics is more than enough for one exercise. This is, at heart, a creative process and one does not want the team to be "stale" when defining the basic building blocks of the application. So leave defining object properties as a separate exercise.