aspose file tools*
The moose likes Agile and Other Processes and the fly likes Requirements for mobile apps. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Requirements for mobile apps." Watch "Requirements for mobile apps." New topic
Author

Requirements for mobile apps.

Tonny Tssagovic
Ranch Hand

Joined: Dec 30, 2003
Posts: 226
Hi everyone,
I wanted to ask you guys about the requirements for a mobile application;
I know I can make some use cases, but the problem I can not see how usefull these are. The application consists of some menues, and to be user firendly and not confuse the user, there are no 100 ways to do one thing.. the app takes the user step by step untill he gets the required functionality.
Now, imagine this scenario: There is a main menu, that contains few categories like News, Sports, Games, blah blah, and then there are sub menues, for example (under sports) Tenis, Football, Basketball, Formula 1 and so on. This looks very much like browsing.
I beleive that drawing the GUI (menus) and arrows showing the flow of the different steps will make much more sense then writing a lot of verbose Use cases. What do you think?

An other question is (assuming I have to write use cases) how many of them should there be? Shall I have a use case to view Tenis results and an other to view Football results and yet an other for Formula 1 or just one "view today's sports results" use case, and then where is the football/tenis going to be in the use case diagram?
- Now I have been told) (a long time ago) that use cases show the interaction beetween the actor and the system in question, Kind of user input and system response table. In this case, I have a use case with the user (actor) choosing to viw some info from his mobile (system). This is quite simple and the real big thing actually happens in the server side, and there are many components (just simple servlets +EJBs or simple objects) on the server side. Should I write a use case for these "sub-systems" (components) or they just appear in the sequence diagrams?
In this case some other component might be actors using other systems part, and one has to describe the requirements provided by this later component hmm it seems I have a headache
Please help :roll:
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
What are you trying to get out of writing use cases? Use cases are best used for fleshing out requirements.
Here's my approach: First come up with the names for all the uses of the system. A use is an end goal of a user: what does the user need to accomplish in a given interaction with the system? Often but not always these uses correspond to what clicking on a menu option accomplishes in a system. Think in terms of start-to-finish: logging in is almost never an end goal of a user, but viewing high scores (which may require logging in) might be.
Once you have a list of all the uses you can think of (and actors, but often it's only one for an app like yours), begin scripting the use case narratives. The give & take nature of use cases (user does this, system responds thus) is where you'll find the "missing requirements" in your system.
People are good at trying to turn use cases into legal artifacts. It's a great way to waste a lot of time. Use them as tools for understanding and as tools for problem solving. If they don't help anyone in these respects, they're use-less. (sorry!)
-Jeff-


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tonny Tssagovic:
I beleive that drawing the GUI (menus) and arrows showing the flow of the different steps will make much more sense then writing a lot of verbose Use cases. What do you think?

I'd think that this already would be much too detailed to begin with. At the beginning of a project, you probably should concentrate more on *what* the user wants to do (view tenis results) and less on the how (via a menu).

An other question is (assuming I have to write use cases) how many of them should there be? Shall I have a use case to view Tenis results and an other to view Football results and yet an other for Formula 1 or just one "view today's sports results" use case, and then where is the football/tenis going to be in the use case diagram?

First, a bubble in a use case diagram is *not* a use case! A use case is a *textual* description of a requirement. The diagram is only secondary and might well be near to useless.
Second, the granularity of the use cases again depends on what you want to use them for. For example, if you want to use them for scheduling, splitting the different types of results might become handy when they have different priorities or are of differening complexity.
Now I have been told) (a long time ago) that use cases show the interaction beetween the actor and the system in question, Kind of user input and system response table. In this case, I have a use case with the user (actor) choosing to viw some info from his mobile (system). This is quite simple and the real big thing actually happens in the server side, and there are many components (just simple servlets +EJBs or simple objects) on the server side. Should I write a use case for these "sub-systems" (components) or they just appear in the sequence diagrams?

Again, it depends on the purpose of the use cases. If you want to make sure wether you understood the requirements, you certainly don't need to know what happends on the server?
In this case some other component might be actors using other systems part, and one has to describe the requirements provided by this later component hmm it seems I have a headache
Please help :roll:

To me it seems as if you actually don't know why you are doing use cases. Perhaps reading a little bit at http://agilemodeling.com/ would help...?


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
Tonny Tssagovic
Ranch Hand

Joined: Dec 30, 2003
Posts: 226
Thanks for your replies Jeff and Ilja
Well What I want from my use cases is to please my teacher(ok maybe not).
I would like to send these use cases to a team on a far-away country for outsourcing, and really don't want to loose too much time on communication overhead.. I have once used more time to explain to a guy via chatting/e-mails what to do then I would probably have used to do it myself (and much better solution and performing code of course).
I also want my use case diagram to look cool, for a school report. So what do you guys think, should there be a see sports result bubble or see tennis/football one? and how would they be connected.

I have another similar case, Search nearest restaurant/cafe/station, should there only be one bubble for search nearest, and where would the different categories (resto, cafe..)
Any thoughts will be helpful.
PS: I have already visited the link.
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Tonny Tssagovic:
Well What I want from my use cases is to please my teacher(ok maybe not).
I would like to send these use cases to a team on a far-away country for outsourcing, and really don't want to loose too much time on communication overhead.. I have once used more time to explain to a guy via chatting/e-mails what to do then I would probably have used to do it myself (and much better solution and performing code of course).
I also want my use case diagram to look cool, for a school report.

I think you pointed out the problem yourself. If you're unable to explain to a remote colleague via extensive chatting and/or email, I'm not sure how a use case is going to improve things much. The main benefit doing the use case would have in this situation is to force you to think through the sequence flow; it might trigger something that was otherwise missing from your more casual communication.
Personally I think use case diagrams are embarrassing. I'm not sure having stick figures pointing to bubbles aids in understanding something that could more easily be represented in tabular format. But, I guess it could look cool. Check out http://www.stickdeath.com for really cool "uses" of stick figures.
With respect to your other question, an "includes" (or possibly an "extends") relationship might provide an means of representing the commonality between the various search types. Remember that use cases are text descriptions, so uses and extends should be viewed in that vein--they are text-substitution aids.
With respect to your outsourcing needs: Successful software development involves a lot of good communication and collaboration. Use cases are an adequate tool at best, but are not a bad place to start. Expect to continue to spend additional time on chat, emails, and the telephone. Supplement the use cases with screen flows (and design diagrams, if you want to dictate to that level). Expect there to still be misinterpretations. The only way to produce "perfect" use cases is to study how to write legalese. At some point, the law of diminishing returns dominates.
I recommend the book Writing Effective Use Cases, by Alistair Cockburn, if you're that interested in use cases.
Jeff
[ February 17, 2004: Message edited by: Jeff Langr ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tonny Tssagovic:
Thanks for your replies Jeff and Ilja
Well What I want from my use cases is to please my teacher(ok maybe not).

Well, if it is, it's hard to tell what you should do without knowing more about your teacher. But if he likes complex diagrams, using "extends" or something might actually please him...
I would like to send these use cases to a team on a far-away country for outsourcing, and really don't want to loose too much time on communication overhead.. I have once used more time to explain to a guy via chatting/e-mails what to do then I would probably have used to do it myself (and much better solution and performing code of course).

And you really think that use cases would have helped? My experience suggests otherwise...
Personally, I think the best way to communicate requirements is by defining automated acceptance tests. But even those can't replace face to face commmunication - the latter actually *is* the most effective form of communication and paying for telephone conferences or even some plane tickets can well pay back. (If you are interested, Cockburn's "Agile Software Development" has some very good chapters on this topic.)
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Requirements for mobile apps.