• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Functional Specification and analysis

 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic