I have found from several resources on OOAD that analysis and design typically start with requirements expressed in use cases.If i am to sesign an application with the Functional Specifications in hand what would be the best way to go about it.My functional specification is very UI centric and expresses functionality using statements like "on pressing botton 'add' the system adds a person to the Organisation".I am not able to decide which artifact i should use to express my analysis to start of with. Please let me know if you have any suggestions Thanks in advance
If you want use cases, you have to translate the functional requirements into use cases. Simple as that. The problem with this kind of "foo happens when user clicks bar" requirements is that the requirements document(s) hide the what behind how. Thus, you need to do some extra work to get yourself familiarized with what the system is supposed to be (what the use cases are).
I have the same problem. I think taking an iterative approach helps: Analyse requirements - (What should the system do?) | Analyse Data - ( Is the data sufficient or create more data) | Analyse Functions - (how best to work on the data to requirements) | Analyse the User Interface - ( how best to present data and functionality) | (iterate to next set of requirements) If your specification is UI centric that suggests that there is a lot of analysis to be done in the other areas. The spec needs fleshing out.
Artifacts: ================= Use Cases are for digging out requirements CRC Cards for defining a Class's purpose Class Diagrams Sequence and/or Interaction Diagrams Package Diagrams Robert Martin Agile Software Development has a section on reducing coupling by segregating UI interfaces I think that's what you should be aiming for re: UI design , a set of interface constructs independent of the actual User Interface, if you see what I mean . I can't think of an artifact specifically for UI Analysis and Design. My 2 pennies worth. regards
I would get myself a stack of index cards and start writing User Stories. That is, on every card write a short description of a task a user needs to do with the system and - is end-to-end (has business value in itself) - can be estimated as being an effort of not more than a week of development You don't need to write much on the card - your example could simply state "add person to organization". The purpose of doing this is to get the functionality split into small chunks, so that they can be estimated and prioritized.
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
Joined: Nov 21, 2000
Originally posted by Lasse Koskela : If you want use cases, you have to translate the functional requirements into use cases
Originally posted by Ilja Preuss: I would get myself a stack of index cards and start writing User Stories. That is, on every card write a short description of a task a user needs to do with the system and - is end-to-end (has business value in itself) - can be estimated as being an effort of not more than a week of development
Can i use a system use case.For ex. My use case can contain things like 1.User opts to add person using screen "ADD PERSON001" 2.System reads person data from XML file. 3.System validates data using business rule"Verify person xxx". 4.System adds person database. Alternate Use case 1(In valid data) A.4 System prompts alerts user with "Invalid person dialog" A.5 User chooses skip person addition using "ADD PERSON001" A.6 use case ends I find this approach good enough to group my requirements.What prevents me from going ahead using this approach is Scott Ambler stating in Object Primer that use cases should not be used for stating functionalities. I am not clear whether i am stating functionalities or requirements in the above use case. Please let me know your opinion
Joined: May 15, 2002
Martin Fowler tries to focus on User Goals first then derives the use cases for them. On deciding which user goals he intends to support, he then elaborates the use cases with at least one set of system interaction use cases for each user goal. Use Cases are useful for requirements planning and estimation. I think Illja's (sorry, the man from U.N.C.L.E. keeps popping up) I mean Ilja's approach combines requirements planning with delivery of critical functions as is done with XP. I'm sure Ilja will correct me if I've misinterpreted this. If you already have a functional specification then I imagine your project is past the requirements planning stage. In which case, Ilja's approach is better. Use Cases is about [b] externally required functionality [\b]. The actors play different roles in the system.So I think a Use Case will generally cover several screens in an Actors area of responsibility which do not need to be mentioned individually in a Use Case.
To me your Use Case looks more like what should be on a CRC card. Someone, please correct if I am wrong. regards [ October 16, 2003: Message edited by: HS Thomas ]
Use case analysis is generally a step on the way to understanding the system well enough to write the functional specs you have in hand. So it may not be necessary to do them at all. But if you were given functional specs out of the blue with no background on the business purpose and goal of the system, you might want to go back and interview the customer to get a feel for why we're building this thing, and make use cases out of your notes. For example, a given screen might have a zillion bits of functionality that make no sense together until you see the various goal-driven flows a user might follow. Think of the difference between all the functional specs for MS Word and a flow called "How to write a letter." If you're comfortable there, Ilja's (not Illya as in Kuryakin ) suggestions about finding reasonable sized chunks of the system to tackle is mainstream agile stuff today, and I'm all for it. I think you were maybe originally asking about how to transition into class analysis & design. The point to take from the agile movement is to do this for one function, build it, test it and call it done, rather than trying to do it for the entire system before touching any code.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi