Where to start?
-
I would start by extracting out in as few words as possible, in point format, all the TASKS that the users want to accomplish, then look for parallels between them and try to compact it into as few tasks as possible. The game is to find ways to accomplish all the needs of the users in as few tasks as possible. Once that point was reached I would mock up a UI on paper considering different ways to fulfil the uers needs to accomplish those tasks in as few steps as possible. I.E. "How can I get the user from starting the program to accomplishing the task in as few steps as possible?" Rework that over and over until you have the smallest possible user interface that accomplishes the tasks the users need to as simply as possible. Make that into a mock up of some kind you can present back to the users so they can see the flow of the different tasks being accomplished and get their approval on it. Then sit down and extract out all the business objects you will need to accomplish those tasks. Do not touch a database at this point or think at all about the data itself, only in the sense of abstract business objects required. When you've whittled it down to as few business objects as possible, only then think about the data required and at that point you're pretty much ready to start coding. The worst possible mistake is to take an initial set of requirements and start making a database for them, this is why a code generation tool that works off a database schema makes such crappy software and why it should be avoided at all costs. Users don't think in terms of data, they think in terms of tasks, jobs they need to get done as quickly and easily as possible. Programmers often think of data first and that will limit them to writing software usable only by other programmers. What you get when you design by user task is a program that the user finds easy to use, intuitive and you will find much easier to maintain. It breaks you away from thinking like a programmer and producing a bloated hard to use program that has a UI tied way too tightly to the technical underpinnings of the system and instead an elegant UI tied to the way the user is already thinking.
:applause: (what? no applause emoticon?) Sometimes it is easy to forget that users will actually use your software. You have to take their point of view every step of development. Great post, my 5! :cool:
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Jeremy Falcon wrote:
I have to admit I'm surprised you say this. Not that I disagree, but I thought you were a Visio buff. Seeing that I've never used Visio (I'd rather put my money in a diff dev tool), this does leave me wondering if it's really good for anything outside of code generation.
Visio tends to suck the enjoyment out of the early design phase. A pencil and paper are still the best tool for thrashing out thoughts and ideas. Visio is very useful when you want to start formalising the design.
Michael CP Blog [^] Development Blog [^]
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
I'd disappear down to the pub and wait for the reorganisation:-D It sounds like you're living the Dilbert life.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world." Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that." Deja View - the feeling that you've seen this post before.
-
Jeremy Falcon wrote:
I have to admit I'm surprised you say this. Not that I disagree, but I thought you were a Visio buff. Seeing that I've never used Visio (I'd rather put my money in a diff dev tool), this does leave me wondering if it's really good for anything outside of code generation.
Visio tends to suck the enjoyment out of the early design phase. A pencil and paper are still the best tool for thrashing out thoughts and ideas. Visio is very useful when you want to start formalising the design.
Michael CP Blog [^] Development Blog [^]
Michael P Butler wrote:
Visio tends to suck the enjoyment out of the early design phase.
I'll have to keep that in mind. :laugh:
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
Write the user manual first, with screenshots (mockups). This can be shown to the end user to confirm what he asked for, and it can be understood by management.
-
To hell with documentation - write the code and then create a document that describes it.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
To hell with documentation - write the code and then create a document that describes it.
Yeah! Spoken (written) like a true outlaw programmer. It's called run-n-gun programming around here! Saves all thos documentation re-writes. Mark
-
:applause: (what? no applause emoticon?) Sometimes it is easy to forget that users will actually use your software. You have to take their point of view every step of development. Great post, my 5! :cool:
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
Luis Alonso Ramos wrote:
Sometimes it is easy to forget that users will actually use your software.
Grow up. Users are the sales departments problem. Programmers would never get anything done if they had to worry about users! ;)
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
Get a dictaphone, and talk through the requirements. Seriously, verbalising the requirements is a good way to get a feel for things and to identify possible problems early on. You don't have anybody to bounce ideas off, so the dictaphone is going to be your best friend. Whatever you do, don't jump in at the deep end and start database or object modelling. As Marc has suggested, get your ideas into some semblance of order (storyboarding) and go from there. Make sure that you understand the problem before you even think about the design. Once you think you have your ideas in place, I would do a walkthrough with the users to see that you have thought of everything, and check that the user requirements are accurate. You'd be surprised how often the requirements are incomplete/wrong/full of assumptions. Talking the users through it, and getting them on board from the start is the best way to keep them on your side. If possible, at some stage, you will want to mock up some screens that the users can play with. Here's a piece of advice that you don't get at Uni, make some deliberate screen mistakes or put something on the screen in a really awful position. Get the users to "suggest" areas for improvement and act surprised/grateful for them. Believe me, that buy in gets you some serious brownie points from your users, and makes them feel part of the process. This has never failed us.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world." Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that." Deja View - the feeling that you've seen this post before.
-
:-D:-D:-D I'm really tempted to do so. However, the customer is requiring full documentation of everything :( and so my bosses.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
:) Start by itemizing the requirements. After that, describe how you plan on implementing each requirement as if that was the only requirement in the program. As you go, you'll see holes in your approach, and making notes about how to tie it altogether. Finally detail how you plan to tie it all together. The more detailed you get, the more likely it is that you'll be able to spot problems in your design before you start writing code.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
Well, thank you everybody for your suggestions, you've been very kind. I took note of all your comments, and I think it is clearer now. :)
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
-
Marc Clifton wrote:
On paper.
I have to admit I'm surprised you say this. Not that I disagree, but I thought you were a Visio buff. Seeing that I've never used Visio (I'd rather put my money in a diff dev tool), this does leave me wondering if it's really good for anything outside of code generation.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
Which tools do you use for modelling?
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
You have competition. Look at what your competitor has done. Talk with their existing users if you can. Solve problems that your competitor has not solved. Prepare a sales speech for your device. Sell it to your potential customers. You may not be the one to give the speech, but preparing the speech will help you put the various components in order. Rework the sales speech into a software design review. (But NOT the all too common “we are all done so let’s have a design review” review.) Your team can now start detail design and you can put the sales speech / design review preparation into whatever kind of spec your bosses desire. Write as much of the user docs as you can before the applicable code is written. Or better, have your software team write user docs before they are allowed to write the corresponding code.
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
At first i recommend perfectly read what users want i.e. List of requirements. Then start analysis i.e. think about gui,user's input and basic classes. at the same time think about database. with it i mean you should do them in parallel.With database design you should consider operation environment entities such as customer,food,orders etc. With this approach you would have a good perspective of both your final application and users' needs. The classes should reflect two aspects of the programs i.e. you should now know a bit about classes that hold responsibilities and classes that hold data. Now start design.you should use iteration approach.Iterate through user's requirements,Database and classes.complete class you had built and redesign them if necessary. I emphasize on iteration.each time refer to your requirement list and check if your on the right way and your design fulfill user's requirement. Of course there are some other considerations such as performance,user friendly forms,security etc. I also recommend you reading some good references for uml: 1. UML explained by Kendall Scott 2. Applying Use Cases: A Practical Guide by Geri Schneider, Jason P. Winters 3. Robert Martin 's articles on UML.they are free.Google them. and design and analysis: 1.Software reuse by Jacobson 2.object-oriented analysis and design using uml by Bennett et al. BTW,Programming is Thinking.You should always see,read,listen and Think.That's all. Best Regards Behzad behzad
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
Looking at the answers given, it's the definitive answer to problems like this, there's no written solution, everyone starts with the more interested domain (DB detailed design, UML use cases, requirements documentation). Well, in a theoretical world where everything goes right, if you have no problems concerning time, team and budget (I don't think this case is ever possible even in big firms), well start with RUP or start with XP. My advice (PERSONAL) is to start with analyzing requirements, dividing them into smaller one, start to think to possible solutions, and produce some paper and ink concepts about your idea. After that start to analyze one by one those smaller requirements and write detailed use case, defining as well as possible actors, those will be your domain, keep in mind, modeling well your domain is a first step to the success. Good luck with your job ! :-D Grava
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
great discussion topic. the general path is requirements=>use cases=>input/output=>general design of data/objects. then specific module design according to requirements. in other words, a big "ditto" on what everyone said, but put together. p.s. does that mean there are cartesian bears roaming around somewhere?
sincerely Guy Shefer, IL
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
I start by analyzing the requitements and writing out all the entities I come across. Then I draw the diagrams that represents the relationships between those entities. After that I'm looking on what to simplify and what to generalize; trying to find patterns that can be made external. After that work is done, I'm diving back into requirements and prove that my concept solves the problems decribed. That concept than gets a status of "buzzy-design-document-level-one" and used as a big picture for the development stage.
-
A competitor for this[^] software. It's a system for managing restaurants. :)
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
Fernando A. Gomez F. wrote:
It's a system for managing restaurants.
Do you have sufficient domain knowledge? i.e., do you know how to run a restaurant, or is that what you do now? If not, I suggest getting your hands dirty in the restaurant first and learning how they do things. Take notes and pay close attention to the logistics, i.e. how the server takes an order, how that order is processed, inventory management, prep work, etc. Once you identify the inefficiencies in the current system, then address those with your software. On a personal note, the last thing I would want is someone coming in with a software suite that doesn't have a clue how I work. Story boards and use cases will flow from this, then you can start designing. IMO, the last thing you want to be doing is coding the final system; make some prototypes and subsystems first.
~Nitron.
ññòòïðïðB A
start -
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
First off - How much time do you think you have for the project? that is a loaded question, but true. To me, it sounds like you have time. Also, this is the first time your superiors gave you free reign, so get them a document they can read and feel like they were 'right' in letting you go on your own. Just because they like what they read doesn't mean it helps you code. Make a second document that fits your brain perfectly. this second document can be considered "for your eyes only." Other people of course can read it, but this second document does not have to make sense to them. Send them to the first document if they complain. Spend an hour a week updating both as you go, at least.
Learn to Fly
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
First off - How much time do you think you have for the project? that is a loaded question, but true. To me, it sounds like you have time. Also, this is the first time your superiors gave you free reign, so get them a document they can read and feel like they were 'right' in letting you go on your own. Just because they like what they read doesn't mean it helps you code. Make a second document that fits your brain perfectly. this second document can be considered "for your eyes only." Other people of course can read it, but this second document does not have to make sense to them. Send them to the first document if they complain. Spend an hour a week updating both as you go, at least. ~D
Learn to Fly
-
I'm doing something similar... and it can be quite complex. I would recommend for you to: 1. fully understand the user requirements 2. design the input-output part (know what you're expecting from your users and what are they expecting from you) 3. sit down and draw, sketch a couple of designs with others... until you refine it to your needs. I would say that the database part would be the most important because if you design it the wrong way you have to make structural changes later... which could prove to be one of the hardest things. Also seek for help from others that did something similar or check out similar software's. It's pretty hard to design something if you haven't done that before.
company, work and everything else www.netis.ro
Strongly agree with the importance of the database design. Perhaps even more important would be exchange formats (e.g., XML export/import). Once you put them out there, people use them. And those data files live forever, so you'll be stuck supporting those data formats forever. But you should start at a much higher level. For a large/scalable/complex system, I think you should start with what I call a host-process architecture. How many concurrent threads of execution are required by the system, and where do they run? Figure out the general responsibilities of each host and process, and try to assign responsibilities in such a way that the interfaces are as small as possible. This might be pretty simple, but there are still a lot of important questions to answer. How many system tiers are required? Are app servers required? Is some kind of system management/monitoring service required? How thick/thin will the clients be? Are intermediate data caches necessary or desirable? Then work on the more detailed design of each of the interoperating pieces. For large or complex systems, agile processes need to extend beyond code. Requirements analysis and design can also be done iteratively. I'm not saying that an exhaustive requirements analysis must be complete prior to starting design or that a detailed design must be completed prior to starting implementation, but requirements analysis should be more advanced than the design, and the design should be more advanced than the code, but all can be going on concurrently. The rationale is that it's much easier to refactor requirements than design and to refactor design than code. This also allows what you learn in implementation to feed back into the ongoing design, etc. Targeted prototypes can be used to mitigate risks.
