What steps do you take to gather end-user requirements before you start programming? (Or do you program first and gather requirements later :-p).What challenges have you encountered in your previous projects and how do you intend to minimize them in your next projects (requirement gathering perspective)?
hmmm, if you are designing this program for a target user group with specific needs or if you know what you want your program to do, then before you start coding your program you should know exactly what it is you want to achieve. What you are going to input to your program, what operations you want your program to perform, and what the output should be.
Usually before you start programming you should have a very solid idea about that.
In technical terms, you should have the program specifications and library header/prototype files designed infront of you before you plunge into the coding.
Designing the program architecture and implementing is then the programmer's job.
End user requirements: challenges:
Sometimes when total non-techies give these requirements (which happens most of the time), they are too vague and fuzzy in explaining what they want and to bridge the gap between what they want and what techically the output should be and to make sure these are the same can be a challenge.
Once your program shapes up and you demo it to the client (end user), they might look at the actual thing and change their mind or realise that they had actually misunderstood something initially, and then they want you to change the thing or add a small thing. They want a small change but for the programmer it could even mean redesigning the actual basic architecture and reimplementing a major portion of the code. This is not fun and its hard to explain to the client why such a seemingly small change can lead to so much extra effort.
This can only be minimised by going through clear communication with the client before hand about the requirements, making clear what they exactly want, and a prototype of the use interfaces, input and output both, must be prepared by the programmer [This is like just the output and input interfaces without any work being done in the background, no coding is done yet]. This really helps.
Hope this helps and that it answers what you asked in your question.
Good :)
*Sometimes when total non-techies give these requirements (which happens most of the time), they are too vague and fuzzy in explaining what they want and to bridge the gap between what they want and what techically the output should be and to make sure these are the same can be a challenge. *
The idea is to minimize this challenge.
1) What methodology would you use to make sure you have gathered ALL the requirements in detail?
2) How would you ensure that the information is complete and thorough?
bonus question:
3) How would you document your fact-finding.. layout?
*Once your program shapes up and you demo it to the client (end user), they might look at the actual thing and change their mind or realise that they had actually misunderstood something initially, and then they want you to change the thing or add a small thing. They want a small change but for the programmer it could even mean redesigning the actual basic architecture and reimplementing a major portion of the code. This is not fun and its hard to explain to the client why such a seemingly small change can lead to so much extra effort. *
1) Who pays for the change. You or the client? Who decides?
2) I like the prototype idea but that requires time and effort from the programmer. Small companies usually don’t have resources to allocate. What would you do then?
3) How do you manage change in requirements half way during the project?
This from the MIS course I teach: “Architecture… then Infrastructure”.
In my past projects, its been iterative process where my role as the project lead has been to get one or two expert developers and the business process owners together to brainstorm ideas about the desired system. Usually we start with process flow diagrams and validate that with other sub-process owners, and then start populating the mental map with system requirements in terms of input and output. Once that’s done, then the map gets broadened to include the specific hardware and software platforms to be used in the project. These multiple cycles have taken anywhere between 1 – 2 months for different projects that I’ve worked on.
The deliverables from such an undertaking usually include a Terms of Reference, a Project Initiation Document and a Visual Model (perhaps in UML). I tend to bundle up the PID and the Visual Model to have a sign-off from the business owners and the project sponsor.
I see you added more specific questions re: Change.
eeks... I hate Scope Creep in projects... it tends to stall the project a lot. I'd much rather do a dry-run using low fidelity prototypes using clipboards, flipcharts and groupware simulations. Lo-fi prototypes are really good for testing general concepts early on in the design process.
When there is an actual need for change, there has to be a change management and escalation process in your Terms of Reference document.
I can go on and on about PM experiences and scope creep and changeme management but more on this later... I gotta jet for now.
JAD sessions are helpful to gather business requirements but in my opinion they could be a disaster if you begin your fact-finding with one. If you are technically sound then programmers should be kept out of the requirements gathering stage…therefore I wanted to hear from the application developers and their approach/modeling technique/comfort level with gathering requirements.
Project initiation document and UML are a part of the requirement gathering but are they precise enough to get a sign off? Ideally, there should be no assumptions…UML, although helpful visual guide, lend themselves to different interpretation unless supported by a clear-cut, defined document. There isn’t a lot of importance given to user-requirement document by developers because it is not ‘exciting’. Developers want to get on to the keyboard and start typing away… leads to a lot of horror stories.
From Project management perspective how to do you estimate a timeline for an iterative process such as above? As this thread is about documentation, how would you document an iterative process in your project plan. A task has a start and a finish…but how often do we go back to the design board :)