I have been tasked with automating some of the paper forms in HR. This might turn into "automate all forms" eventually, so I want to approach this in a way which will be best for the long term and will be a good framework as this project grows.
The first things that come to mind were:
-InfoPath/SharePoint (We currently don't use SharePoint now, and wouldn't be an option for the next two years.)
-Workflow Foundation (I've looked into this and does not seem too attractive or appropriate)
Option I'm considering at this point:
-Custom ASP.NET (VB.NET) & SQL Server, which is what my team mostly writes their apps with.
-Leverage Infopath for creating the forms electronically. Wondering if there is a good approach to integrating this with a custom built ASP.NET app.
-Considering creating the app as an MVC web app.
My question is this:
-Are there other options I might want to consider?
-Are there any starter kits or VB.NET based open source projects there which would be a starting point or could be used as a good reference. Here I'm mostly concerned with the workflow processing.
-Any comnments from those who have gone down this path?
This is going to sound really dumb, but in my many years of helping companies automate paper form-based processes is to understand the process first. You will most likely find that no single person understands the whole thing. You will need to role-play the many paths thru the process to get your head around it. And once you present your findings, everyone will be shocked because they had no idea it was that complex. Use that as an opportunity to streamline.
Automating a broken process only makes it screw up faster and tell a lot of people.
As far as tools, my experience dates me but try to go with something with these properties:
EASY to change. You WILL be changing it. So don't hard-code anything.
Possible revision control - changes to a process may or may not affect documents already in route?
Visual workflow editing. Everyone wants this but they'll all ask you to drive it. Still, nice tools.
Not sure if this helps or not - but 80% of success in automating processes is not technology.
This is slightly off topic, but related - defect tracking systems generally have workflow engines/state. (In fact, I think Joel or some other FC employee posted something about using FB for managing the initial emails and resume process)
I second the other advice about modeling the workflow before doing any coding or technology choices. You will also want this to be flexible.
as n8owl reminded us, automating a mess yields an automated mess - which is not an improvement. Many paper-forms systems have evolved over decades and can be quite redundant and unruly. Some may view "messing with the forms" as a violation of their personal fiefdoms, so watch your back ;-)
model the workflow in terms of the forms used by whom in what roles for what purposes; this documents the current process as a baseline. Get estimates of how long each step takes, both in terms of man-hours and calendar time
understand the workflow in terms of the information gathered, generated, and transmitted
consolidate the information on the forms into a new set of forms for minimal workflow
be prepared to be told "This is the way we've always done it and we're not going to change", and to gently (a) validate their feelings, (b) explain how less work is more efficient, and (c) show concrete benefits [vs.the baseline from step 1]
soft-code when possible; use processing rules when possible; web services and html forms (esp. w/jquery) will go a long way if you have an intranet
beware of canned packages (including sharepoint) unless you are absolutely certain they encompass your organization's current and future needs
good luck!
--S
I detect here a general tone of caution with regards to a workflow based approach and must agree. Be advised about the caveats of most workflow technologies which sacrifice usability for flexibility.
Related
I bet many of you were in such situations in the past.
I'm currently working on huge ASP.NET web project. Ad management system of some kind. My boss doesn't want to get more professionals to help me but gives me inexperienced staff that don't even know to program on ASP.NET and think it is an easy task. I deal with programming and design
What advices do you have to handle the boss ?
What tools can help me to ease with this task ( except usage of this very website )?
Thanks
I would hope good source control is something you already haev on your list but I think its always the best thing for any big project. Keeps your code safe and has the added advantage of allowing easy review of what your team are checking in if you feel the need for oversight.
Other than that just make sure you give your boss a realistic understanding of the time taken for various tasks and if he complains make it clear that your team needs more training if he wants stuff done faster.
P.S. [Edit: removed as no longer relevant]
You could ask him for a raise from getting rid of the people who are not helpful. that might actually save him money and make your time more worthwhile.
What advices do you have to handle the boss ?
First make sure you have a good analysis document and that you have for every dependency a spoc (single point of contact). Make sure the people who you're making this application for are integrated into the process. I suggest using something like scrum but certainly daily standup meetings.
Use a good system to follow up on everyone like for example TFS2010 which has also testing capabilities integrated so your testing team can be better integrated.
Have a bug tracking tool and source safe handy. Continuous integration is also an asset.
but gives me inexperienced staff that don't even know to program on ASP.NET
It's your boss intention to upgrade his people to a level where they are capable of programming ASP.NET applications in the end. What way to better learn it than hands on experience from a dedicated professional like you?
Be aware: you're dealing with people now, not just code. They get sick, have their strenghts and weaknesses just like you. And believe me, it can be a challenge sometimes to deal with the human part of a project. Especially when there's pressure due to release dates.
Perhaps you can convince him to distribute some (technical...) parts of the project to RentAcoder.com or getAfreelancer.com? It will be cheaper than getting more manpower..
Use a decent workitem/bugtracking system. This won't turn your 'inexperienced devs' into experts but at least you'll be able to see what progress they are making(or not making as the case may be)
I’ve been asked to look into how best to move forms into InfoPath and have a couple of basic questions about your experiences so I can get an insider’s lay of the land. Even some short, quick bullets would be really helpful -- thank you!
Are you starting from scratch in InfoPath, or are you converting from paper or a different e-format? (Jetform, PDF, etc.)
Are you trying to re-create the layout of a specific paper form, or is a regular online form OK? (trying to learn what the latest thinking is about this)
Do you need only simple fill and submit capabilities, or do you need programming for calculations, validation, database lookup/entry/reporting, etc. as well? (don’t know how much harder it is to do all this vs. not)
How long does each form take to finish? (I know it depends, but is there a rough guideline for planning purposes?)
Who’s doing the actual work? (by title or function)
What is especially straightforward or challenging about moving to InfoPath forms? (forewarned is forearmed!)
We are in the process of moving all our company forms to InfoPath. This is approximately 70 total encompassing things such as Vacation Requests, Time Card Adjustments, etc. I will answer your questions based on that.
The current forms are in Word format and people print them and fill them out. There is actually a function in InfoPath to import/convert Word documents so our "forms" department can create them fairly easily without developer support (and the forms have to identically match the Word versions - even if there are ways to improve, it is a political factor not a technical one). This process is very quick (the form can be created in an hour or so). At this time we are just using simple fill in and submit capabilities although we would like to add prepopulation of certain fields in the future.
The two most challenging aspects we faced (so far) are digital signatures and publishing the forms. The idea of digital signatures is great and we definitely wanted to use them but understanding how they work and making sure the form is designed correctly took a little training for the nontechnical people creating the forms. Publishing took a little explaining as well. Our users were creating a form locally and then just emailing it around or copying it to shares without ever publishing it - which just errors out for any user but the author. Teaching them the proper process (and explaining why it was setup that way) took a bit of time.
I've been working in ASP.NET for several years now (since the 1.0 days!), but I've never been formally instructed. I'm fully capable of doing pretty much anything I want and I've built several production-level, data-driven sites, including one that does over a million in sales a year (according to the owner). But I'm starting to get the feeling that the holes in my knowlege are dragging my productivity down. I read a lot and try to learn wherever I can to try to stay up with all the new technologies, but sometimes I just don't get it, and I think it's because of my lack of formal training.
Does anyone have any ideas on the best way to fill in these gaps without having to rehash the fundamentals?
Thanks
1) Read the Code of popular Open Source Projects. There are a few that have some really good practices in place.
I recommend checking out BlogEngine.NET. Also if you're more ambitious, I'd suggest looking at the code for ASP.NET MVC 1.0.
2) Sometimes you need to "get back to the basics" when you've been working with a particular framework since a much earlier version. In this case, it can be really useful to pick up a book that covers some of the newer features.
Here's a good book that shows of some of the new features in C# 3.0:
C# 3.0 Design Patterns
3) It may seem odd, but reading up on other languages/platforms (such as Ruby on Rails) will help you in the way you design your classes and code by taking tips of the good and bad of different platforms and combining them.
4) Read some books on general best practices and development methodologies.
Some of these books I recommend are:
The Pragmatic Programmer: From Journeyman to Master
Practices of an Agile Developer: Working in the Real World
Code Complete: A Practical Handbook of Software Construction
I'm in the same boat; been a .Net developer for 6 years. While I do have a CS degree, I don't have any formal training in ASP.Net; I learn it on the job as projects come up.
I found the best way to figure out what to learn is to keep your eye on .Net developer blogs. Some I follow:
David Hayden http://www.davidhayden.com/blog.aspx
CodingHorror.com (you might be familiar with it ;-)
Scott Hanselman http://www.hanselman.com/blog/
Usually from reading their blogs, I pick up on what the latest .Net solutions that are out there and point me in the direction of new tech I should look into further.
Overall though, I can only give you the advice I give junior devs at my company; realize you can't possibly be expected to know everything but always be eager to learn. Good luck!
I can absolutely identify. I've been programming since 1997 and really don't have any formal training to speak of. With regards to ASP.NET, everything I've learned has been through open code (Community Server, BlogEngine.NET, the other ASP.NET Starter Kits), books, LearnVisualStudio.net, and constantly being thrown in the fire.
I have a MASSIVE inferiority complex as I'm always wondering "did I do this the smart way or the inexperienced way". All I know is that my customers are happy, the errors that occur are few and are fixed quickly, and I keep getting work.
Luckily I have a passion for my work and that's what drives me to keep improving (slow though it may be).
If you're a "people person" then I think user group meetings are a great resource. I'm a bit of an introvert and unless someone who's smart reaches across and shakes my hand, I pretty much rely on the speaker's presentation to teach me something new. Probably not the best way to go and also probably why I don't go that much.
But again, I would stress the open projects, especially Community Server.
Seek out people better than you and learn from them.
Take some classes or join a user group.
If you are looking at conferences, consider finding a local Code Camp. These conferences are often very low key, but have excellent information content. They involve local presenters and attendees so you can build up your contacts and a set of people you can run things past when you need help. In addition, you might want to find (or start) a local .NET group where you can learn together. These can be hard to get off the ground, but when done well can be an excellent source of community learning.
Look for interesting ways to break your established patters - even at a loss of productivity.
Otherwise, it sounds like you are already in a pretty good spot. You can deliver on current requirements and sound like you can pick up new tricks when needed.
Really, the best way to learn new techniques is to work on a different project - even if that means changing jobs. If you have relevant and continuous experience since 2001, you should be able to pick your projects.
I've been coding PHP on a current project and it's been an interesting break from webforms. If anything, I'm getting good perspective on both models and really looking forward to doing some work in MVC.
I'll probably get some -1's for this, but as a fellow ASP.NET developer I don't think you really need to learn ALL that the framework has to offer. The reason I say that is that over the years my LACK of knowledge of all the cute little conveniences of ASP.NET has caused me to write better performing and more robust web apps for Windows. Balanced design patterns (separation of concerns) WITHOUT OVERDOING IT will make more of a "better" ASP.NET web app than using all of the controls and tools that come with the framework.
Case in point is the ajax stuff you get with ASP.NET, and also data binding. Since ASP.NET was late in the game with Ajax, I started off with my own ajax wrapper (based on an early ajax book) and then moving to jQuery. My co-workers all swear by the UpdatePanels and 3rd party controls, and quite often the user experience ends up worse and more confusing than a regular post back (and then we have to inject javascript to make it perform better and more seemlessly). As far as data binding, I've yet to find a canned control (from Microsoft or any 3rd party) that handles 2-way binding better than the framework Rick Strahl came up with back in the 1.1 days. We built a framework on top of a paper and some base classes he released, and I've yet to see something that I think handles data binding any better in ASP.NET (well...besides WPF/Silverlight...those frameworks really nailed it IMO).
So, to me, the path to upgrading your ASP.NET skills is to come up with some good ways to separate your business logic into logical components in the cleanest possible way, and learn the hell out of C# and JavaScript (and/or a JS wrapper library like jQuery). For me, coming from a LAMP background before learning ASP.NET, I absolutely love C# and Visual Studio, but I'm not such a huge fan of the high level ASP.NET controls.
This is a pretty broad question, and hard to address. I perceive myself in a similar space to you, so I guess I can elaborate on what I've been focusing on to improve as a developer which might be of some help.
I mostly write business and commerce related web apps, and my focus has been on a developing a solid understanding of separation of concerns, domain driven design, and enterprise design patterns.
Some books on general software design which I found revelatory were Code Complete by Steve McConnell and Head First Design Patterns by Freeman & Freeman.
I read SO, Code Better, DDD Step by Step, and a number of other blogs regularly.
Dissect well written code from others, and learn from them. Learn from your peers. If you're in a stifling work environment that doesn't give you the opportunity to grow as a developer, consider looking for a new job.
Learn a new language in a completely different framework - I've been teaching myself Ruby on Rails at home and it has given me an interesting perspective on the ASP.NET work that I do commercially.
Given that you're an ASP.NET web developer, learning MVC.NET will certainly help you to think about front-end development in a new, refreshing way.
If you can afford the money and time (or can get your company to pay for it), take a course at DevelopMentor. They have courses across the country and all year round. They are generally a week long and are in depth.
I was using a CASE called MAGIC for a system I'm developing, I've never used this kind of tool before and at first sight I liked, a month later I had a lot of the application generated, I felt very productive and ... I would say ... satisfied.
In some way a felt uncomfortable, cause, there is no code and everything I was used to, but in the other hand I could speed up my developing. The fact is that eventually I returned to use C# because I find it more flexible to develop, I can make unit testing, use CVS, I have access to more resources and basically I had "all the control". I felt that this tool didn't give me confidence and I thought that later in the project I could not manage it due to its forced established rules of development. And also a lot of things like sending emails, using my own controls, and other things had their complication, it seemed that at some point it was not going to be as easy as initially I thought and as initially the product claims. This reminds me a very nice article called "No Silver Bullet".
This CASE had its advantages but on the other hand it doesn't have resources you can consult and actually the license and certification are very expensive. For me another dissapointing thing is that because of its simplistic approach for development I felt scared on first hand cause of my unexperience on these kind of tools and second cause I thought that if I continued using it maybe it would have turned to be a complex monster that I could not manage later in the project.
I think it's good to use these kind of solutions to speed up things but I wonder, why aren't these programs as popular as VS.Net, J2EE, Ruby, Python, etc. if they claim to enhance productivity better than the tools I've pointed?
We use a CASE tool at my current company for code generation and we are trying to move away from it.
The benefits that it brings - a graphical representation of the code making components 'easier' to pick up for new developers - are outweighed by the disadvantges in my opinion.
Those main disadvantages are:
We cannot do automatic merges, making it close to impossible for parallel development on one component.
Developers get dependant on the tool and 'forget' how to handcode.
Just a couple questions for you:
How much productivity do you gain compared to the control that you use?
How testable and reliant is the code you create?
How well can you implement a new pattern into your design?
I can't imagine that there is a CASE out there that I could write a test first and then use a CASE to generate the code I need. I'd rather stick to resharper which can easily do my mundane tasks and retain full control of my code.
The project I'm on originally went w/ the Oracle Development Suite to put together a web application.
Over time (5+ years), customer requirements became more complex than originally anticipated, and the screens were not easily maintainable. So, the team informally decided to start doing custom (hand coded) screens in web PL/SQL, instead of generating them using the Oracle Development Suite CASE tools (Oracle Designer).
The Oracle Report Builder component of the Development Suite is still being used by the team, as it seems to "get the job done" in a timely fashion. In general, the developers using the Report Builder tool are not very comfortable coding.
In this case, it seems that the productivity aspect of such CASE tools is heavily dependent on customer requirements and developer skill sets/training/background.
Unfortunaly the Magic tool doesn't generates code and also it can't implement a design pattern. I don't have control over the code cause as i stated before it doesn't have code to modify. Te bottom line is that it can speed up productivity in some way but it has the impossibility to user CVS, patterns also and I can't control all the details.
I agree with gary when he says "it seems that the productivity aspect of such CASE tools is heavily dependent on customer requirements and developer skill sets/training/background" but also I can't agree more with Klelky;
Those main disadvantages are:
1. We cannot do automatic merges, making it close to impossible for parallel development on one component.
2.Developers get dependant on the tool and 'forget' how to handcode.
Thanks
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
How do you go about the requirements gathering phase? Does anyone have a good set of guidelines or tips to follow? What are some good questions to ask the stakeholders?
I am currently working on a new project and there are a lot of unknowns. I am in the process of coming up with a list of questions to ask the stakeholders. However I cant help but to feel that I am missing something or forgetting to ask a critical question.
You're almost certainly missing something. A lot of things, probably. Don't worry, it's ok. Even if you remembered everything and covered all the bases stakeholders aren't going to be able to give you very good, clear requirements without any point of reference. The best way to do this sort of thing is to get what you can from them now, then take that and give them something to react to. It can be a paper prototype, a mockup, version 0.1 of the software, whatever. Then they can start telling you what they really want.
See obligatory comic below...
In general, I try and get a feel for the business model my customer/client is trying to emulate with the application they want built. Are we building a glorified forms processor? Are we retrieving data from multiple sources in a single application to save time? Are we performing some kind of integration?
Once the general businesss model is established, I then move to the "must" and "must nots" for the application to dictate what data I can retrieve, who can perform what functions, etc.
Usually if you can get the customer to explain their model or workflow, you can move from there and find additional key questions.
The one question I always make sure to ask in some form or another is "What is the trickiest/most annoying thing you have to do when doing X. Typically the answer to that reveals the craziest business/data rule you'll have to implement.
Hope this helps!
Steve Yegge talks fun but there is money to be made in working out what other people's requirements are so i'd take his article with a pinch of salt.
Requirements gathering is incredibly tough because of the manner in which communication works. Its a four step process that is lossy in each step.
I have an idea in my head
I transform this into words and pictures
You interpret the pictures and words
You paint an image in your own mind of what my original idea was like
And humans fail miserably at this with worrying frequency through their adorable imperfections.
Agile does right in promoting iterative development. Getting early versions out to the client is important in identifying what features are most important (what ships in 0.1 - 0.5 ish), helps to keep you both on the right track in terms of how the application will work and quickly identifies the hidden features that you will miss.
The two main problem scenarios are the two ends of the scales:
Not having a freaking clue about what you are doing - get some domain experts
Having too many requirements - feature pit. - Question, cull (prioritise ;) ) features and use iterative development
Yegge does well in pointing out that domain experts are essential to produce good requirements because they know the business and have worked in it. They can help identify the core desire of the client and will help explain how their staff will use the system and what is important to the staff.
Alternatives and additions include trying to do the job yourself to get into the mindset or having a client staff member occasionally on-site, although the latter is unlikely to happen.
The feature pit is the other side, mostly full of failed government IT projects. Too much, too soon, not enough thought or application of realism (but what do you expect they have only about four years to make themselves feel important?). The aim here is to work out what the customer really wants.
As long as you work on getting the core components correct, efficient and bug-free clients usually remain tolerant of missing features that arrive in later shipments, as long as they eventually arrive. This is where iterative development really helps.
Remember to separate the client's ideas of what the program will be like and what they want the program to achieve.
Some clients can create confusion by communicating their requirements in the form of application features which may be poorly thought out or made redundant by much simpler functionality then they think they require. While I'm not advocating calling the client an idiot or not listening to them I feel that it is worth forever asking why they want a particular feature to get to its underlying purpose.
Remember that in either scenario it is of imperative importantance to root out the quickest path to fulfilling the customers core need and put you in a scenario where you are both profiting from the relationship.
Wow, where to start?
First, there is a set of knowledge someone should have to do analysis on some projects, but it really depends on what you are building for who. In other words, it makes a big difference if you are modifying an enterprise application for a Fortune 100 corporation, building an iPhone app, or adding functionality to a personal webpage.
Second, there are different kinds of requirements.
Objectives: What does the user want to accomplish?
Functional: What does the user need to do in order to reach their objective? (think steps to reach the objective/s)
Non-functional: What are the constraints your program needs to perform within? (think 10 vs 10k simultaneous users, growth, back-up, etc.)
Business rules: What dynamic constraints do you have to meet? (think calculations, definitions, legal concerns, etc.)
Third, the way to gather requirements most effectively, and then get feedback on them (which you will do, right?) is to use models. User cases and user stories are a model of what the user needs to do. Process models are another version of what needs to happen. System diagrams are just another model of how different parts of the program(s) interact. Good data modeling will define business concepts and show you the inputs, outputs, and changes that happen within your program. Models (and there are more than I listed) are really the key to the concern you list. A few good models will capture the needs and from models you can determine your requirements.
Fourth, get feedback. I know I mentioned this already, but you will not get everything right the first time, so get responses to what your customer wants.
As much as I appreciate requirements, and the models that drive them, users typically do not understand the ramifications of of all their requests. Constant communication with chances for review and feedback will give users a better understanding of what you are delivering. Further, they will refine their understanding based on what they see. Unless you're working for the government, iterations and / or prototypes are helpful.
First of all gather the requirements before you start coding. You can begin the design while you are gathering them depending on your project life cicle but you shouldn't ever start coding without them.
Requirements are a set of well written documents that protect both the client and yourself. Never forget that. If no requirement is present then it was not paid for (and thus it requires a formal change request), if it's present then it must be implemented and must work correctly.
Requirements must be testable. If a requirement cannot be tested then it isn't a requirement. That means something like, "The system "
Requirements must be concrete. That means stating "The system user interface shall be easy to use" is not a correct requirment.
In order to actually "gather" the requirements you need to first make sure you understand the businness model. The client will tell you what they want with its own words, it is your job to understand it and interpret it in the right context.
Make meetings with the client while you're developing the requirements. Describe them to the client with your own words and make sure you and the client have the same concept in the requirements.
Requirements require concise, testable example, but keep track of every other thing that comes up in the meetings, diagrams, doubts and try to mantain a record of every meeting.
If you can use an incremental life cycle, that will give you the ability to improve some bad gathered requirements.
You can never ask too many or "stupid" questions. The more questions you ask, the more answers you receive.
According to Steve Yegge that's the wrong question to ask. If you're gathering requirement it's already too late, your project is doomed.
High-level discussions about purpose, scope, limitations of operating environment, size, etc
Audition a single paragraph description of the system, hammer it out
Mock up UI
Formalize known requirements
Now iterate between 3 and 4 with more and more functional prototypes and more specs with more details. Write tests as you go. Do this until you have functional software and a complete, objective, testable requirements spec.
That's the dream. The reality is usually after a couple iterations everybody goes head-down and codes until there's a month left to test.
Gathering Business Requirements Are Bullshit - Steve Yegge
read the agile manifesto - working software is the only measurement for the success of a software project
get familiar with agile software practices - study Scrum , lean programming , xp etc - this will save you tremendous amount of time not only for the requirements gathering but also for the entire software development lifecycle
keep regular discussions with Customers and especially the future users and key-users
make sure you talk to the Persons understanding the problem domain - e.g. specialists in the field
Take small notes during the talks
After each CONVERSATION write an official requirement list and present it for approving. Later on it would be difficult to argue against all agreed documentation
make sure your Customers know approximately what are the approximate expenses in time and money for implementing "nice to have" requirements
make sure you label the requirements as "must have" , "should have" and "nice to have" from the very beginning, ensure Customers understand the differences between those types also
integrate all documents into the latest and final requirements analysis (or the current one for the iteration or whatever agile programming cycle you are using ... )
remember that requirements do change over the software life cycle , so gathering is one thing but managing and implementing another
KISS - keep it as simple as possible
study also the environment where the future system will reside - there are more and more technological restraints from legacy or surrounding systems , since the companies do not prefer to throw to the garbage the money they have invested for decades even if in our modern minds 20 years old code is garbage ...
Like most stages of the software development process its iteration works best.
First find out who your users are -- the XYZ dept,
Then find out where they fit into the organisation -- part of Z division,
Then find out what they do in general terms -- manage cash
Then in specific terms -- collect cash from tills, and check for till fraud.
Then you can start talking to them.
Ask what problem they want you want to solve -- you will get an answer like write a bamboozling system using OCR with shark technoligies.
Ignore that answer and ask some more questions to find out what the real problem is -- they cant read the till slips to reconcile the cash.
Agree a real solution with the users -- get a better ink ribbon supplier - or connect the electronic tills to the network and upload the logs to a central server.
Then agree in detail how they will measure the success of the project.
Then and only then propose and agree a detailed set of requirements.
I would suggest you to read Roger-Pressman's Software Engineering: A Practitioner's Approach
Before you go talking to the stakeholders/users/anyone be sure you will be able to put down the gathered information in a usefull and days-lasting way.
Use a sound-recorder if it is OK with the other person and the information is bulky.
If you heard something important and you need some reasonable time to write it down, you have two choices: ask the other person to wait a second, or say goodbye to that precious information. You wont remember it right, ask any neuro-scientist.
If you detect that a point need deeper review or that you need some document you just heard of, make sure you make a commitment with the other person to send that document or schedule another meeting with a more specific purpose. Never say "I'll remember to ask for that xls file" because in most cases you wont.
Not to long after the meeting, summarize all your notes, recordings and fresh thoughts. Just summarize it rigth. Create effective reminders for the commitments.
Again, just after the meeting, is the perfect time to understand why the gathering you just did was not as right as you thought at the end of the meeting. That's when you will be able to put down a lot of meaningful questions for another meeting.
I know the question was in the perspective of the pre-meeting, but please be aware that you can work on this matters before the meeting and end up with a much usefull, complete and quality gathering.
I've been using mind mapping (like a work breakdown structure) to help gather requirements and define the unknowns (the #1 project killer). Start at a high level and work your way down. You need to work with the sponsors, users and development team to ensure you get all the angles and don't miss anything. You can't be expected to know the entire scope of what they want without their involvement...you - as a project manager/BA - need to get them involved (most important part of the job).
There are some great ideas here already. Here are some requirements gathering principles that I always like to keep in mind:
Know the difference between the user and the customer.
The business owners that approve the shiny project are usually the customers. However, a devastating mistake is the tendency to confuse them as the user. The customer is usually the person that recognizes the need for your product, but the user is the person that will actually be using the solution (and will most likely complain later about a requirement your product did not meet).
Go to more than one person
Because we’re all human, and we tend to not remember every excruciating detail. You increase your likelihood of finding missed requirements as you talk to more people and cross-check.
Avoid specials
When a user asks for something very specific, be wary. Always question the biases and see if this will really make your product better.
Prototype
Don’t wait till launch to show what you have to the user. Do frequent prototypes (you can even call them beta versions) and get constant feedback throughout the development process. You’ll probably find more requirements as you do this.
I recently started using the concepts, standards and templates defined by the International Institute of Business Analysts organization (IIBA).
They have a pretty good BOK (Book of Knowledge) that can be downloaded from their website. They do also have a certificate.
Requirements Engineering is a bit of an art, there are lots of different ways to go about it, you really have to tailor it to your project and the stakeholders involved. A good place to start is with Requirements Engineering by Karl Wiegers:
http://www.amazon.com/Software-Requirements-Second-Pro-Best-Practices/dp/0735618798/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1234910330&sr=8-2
and a requirements engineering process which may consist of a number of steps e.g.:
Elicitation - for the basis for discussion with the business
Analysis and Description - a technical description for the purpose of the developers
Elaboration, Clarification, Verification and Negotiation - further refinement of the requirements
Also, there are a number of ways of documenting the requirements (Use Cases, Prototypes, Specifications, Modelling Languages). Each have their advantages and disadvantages. For example prototypes are very good for elicitation of ideas from the business and discussion of ideas.
I generally find that writing a set of use cases and including wireframe prototypes works well to identify an initial set of requirements. From that point it's a continual process of working with technical people and business people to further clarify and elaborate on the requirements. Keeping track of what was initially agreed and tracking additional requirements are essential to avoid scope creep. Negotiation plays a bit part here also between the various parties as per the Broken Iron Triangle (http://www.ambysoft.com/essays/brokenTriangle.html).
IMO the most important first step is to set up a dictornary of domain-specific words. When your client says "order", what does he mean? Something he receives from his customers or something he sends to his suppliers? Or maybe both?
Find the keywords in the stakeholders' business, and let them explain those words until you comprehend their meaning in the process. Without that, you will have a hard time trying to understand the requirements.
i wrote a blog article about the approach i use:
http://pm4web.blogspot.com/2008/10/needs-analysis-for-business-websites.html
basically: questions to ask your client before building their website.
i should add this questionnaire sheet is only geared towards basic website builds - like a business web presence. totally different story if you are talking about web-based software. although some of it is still relavant (e.g. questions relating to look and feel).
LM
I prefer to keep my requirements gathering process as simple, direct and thorough as possible. You can download a sample document that I use as a template for my projects at this blog posting: http://allthingscs.blogspot.com/2011/03/documenting-software-architectural.html