SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 28
  1. #1
    ********* Articles ArticleBot's Avatar
    Join Date
    Apr 2001
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Article Discussion

    This is an article discussion thread for discussing the SitePoint article, "Requirements Gathering Essentials"

  2. #2
    SitePoint Member
    Join Date
    Nov 2004
    Location
    Paris, KY
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    We've found it more productive and cost effective to just have the client sign off on each phase of a project...rather than spell out or try to predict up front all the specific requirements that will be needed for a site. Sure, we go into the project with the full understanding of the ultimate goal, but they aren't looking to us to teach them what is required to get what they are asking for. They hired us because we know what they don't.

    One book I would suggest for project planning: "Getting Things Done" - David Allen. His premise is simple...concentrate on the "next thing" that needs to be done.

    And keep clients informed through each step.

  3. #3
    SitePoint Addict
    Join Date
    Apr 2002
    Location
    Whitehorse, Yukon
    Posts
    226
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Stonecreek,

    While this process you've described works well for smaller projects such as websites, it fails when it comes to multi-departmental software/application work where there numerous teams involved and many types of business processes and impacts. You can't just know the ultimate goal, you need to record all of the needs (both known and hidden) plus be aware of all the risks and how to mitigate those risks.

    You have to do the research and requirements gathering up front or otherwise you end up with a failed project. Intense requirements gathering isn't static - you need to constantly go back and forth with new revisions - but it helps lay a solid groundwork on the really big stuff.

    geof

  4. #4
    SitePoint Member
    Join Date
    Dec 2004
    Location
    Melbourne, Australia
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There are many schools of thought on how best to gather requirements.

    On one hand, there are those that don't document anything and get straight into code, there are others that cover absolutely everything in detail at the start. Both have their problems. The smaller the project, the less risk there is in not capturing requirements. In larger projects, the risk is increases dramatically.

    However, develompent is not an exact science and often requirements, even if written well can change due to unknown or unforeseen circumstances which makes you wonder why you bother in the first place! This is where common sense has to prevail. The amount of detail put into the requirements will depend on the scale and nature of the project.

    martyb

  5. #5
    SitePoint Addict
    Join Date
    Apr 2002
    Location
    Whitehorse, Yukon
    Posts
    226
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I am definitely in the latter group for the big projects. The small stuff I make sure to at least get a bare bones BRD/URD together. Requirements evolve yes, but that's why you have change documents :)

    geof

  6. #6
    Dale Wilkins
    SitePoint Community Guest
    My experience in working with clients taught me that requirements need to be developed in collaboration with clients and builders.

    I learned to ask: 1) Can we build something that will meet this requirement? (Focus on the What, not the How, at this point.)

    2) Can we agree, clients and builders, on a test that demonstrates the requirement has been met, if the system passes the test?

    I have found that these two questions help define vague requirements such as "It needs to be faster!"

  7. #7
    Phil
    SitePoint Community Guest
    Publishing an article is also a project (or task if you prefer) in itself and as such needs QA too. eg. Spellchecker.

    :-)

  8. #8
    SitePoint Enthusiast HeshamAmiri's Avatar
    Join Date
    Oct 2003
    Location
    Dubai
    Posts
    75
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For small projects it might be expected that requirmnets define every little detail expected, but from experience working on a huge project that tackles new areas in the industry requirmnets become more or less a guidline for expecations and hence several intermediate steps are required from the date you finalize the requirments to the date you finalize your archetictire. These steps will help your clients (and yourself) understand what is needed in much more detail.
    Several other session of progress and alignement should be executed while implemenation and prior to initial relaese.

    Don't expect a big project to close nicely like small ones usually tend to do.

  9. #9
    SitePoint Wizard realestate's Avatar
    Join Date
    May 2004
    Posts
    1,092
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Worst case scenarios should be considered as well. What will happen if one of the parties quits or dies. Written contacts may not be enough to fix damages. Payments should be made gradually from the start date and continue after project is finished.

  10. #10
    SitePoint Member vandiike's Avatar
    Join Date
    Oct 2004
    Location
    Greece
    Posts
    19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Most of requirements gathering articles that I read are for when you have a client. To be honest, most of my projects are not client driven, more organisational driven, if that makes sense. I.e. improve former software etc.
    -Do you have any good ideas of how to make requirements gathering easier when no specific client exist.

    Mike

  11. #11
    SitePoint Member
    Join Date
    Dec 2004
    Location
    Melbourne, Australia
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi Mike,

    This is a really good point. I find that internal projects often get treated different than commercial projects where a client is paying for the work and wants to see tangible results for their money.

    The simply answer is to find a client. Or in your case, a project sponsor, ie. someone who will make the decisions for you. If there's no-one to do this, how can you assess if what you're doing is right or not? Ofcourse, finding that person might not be an easy task but there's often more than one way to get things done.

    So, what you might need to do is write the requirements yourself. Literally make up what you think the organisation needs and then find someone to read it and hopefully approve it. I suggest this because often people won't give you details up front but they will give you feedback if they see something wrong. I find that there are even cases where a prototype has to be built to get people to pay attention when they won't read requirements (happens all the time).

    Hope this helps.

    Cheers
    martyb

  12. #12
    SitePoint Addict
    Join Date
    Apr 2002
    Location
    Whitehorse, Yukon
    Posts
    226
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A project sponsor, or what in our enterprise we call a Business Prime, is exactly what you need in cases like this.

    Good suggestion also on writing your own requirements.

    Writing requirements helps you as a developer (and an information architect) get a better grasp on what the real world needs of an application are - often developers think too much about the code and not enough on the business functions, processes and issues surrounding how the application could benefit or detract from everyday usage.

    Start moving around the office, ask questions of appropriate personnel and gather feedback on how they do their work and what sorts of problems they encounter - this will help you realize and document opportunities. It also helps raise the profile of your work and your role in the company. This is especially important if you're looking to impress your superiors. Be polite and proactive - it can go a long way.

    geof

  13. #13
    SitePoint Member vandiike's Avatar
    Join Date
    Oct 2004
    Location
    Greece
    Posts
    19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for your comments. I have now 2 sponsors that are willing to act as test-users. (both from different departments, and "head of departmetns") I have also started to make and write UML use-cases together with the head developer. I hope that this will give me the tip of the sword in the quest for a more user friendly/focused application without having a real client.

    Thanks again

    Mike
    Visit my site: Site|Cosmos
    Build Your own website that you can be proud of!

  14. #14
    Rashid
    SitePoint Community Guest
    I am interested in finding samples or examples of what methodoligies are used for requirements gathering and how does the document or output looks like..

    Something that can help me in going ahead with a similar task at hand

    Thanks!

  15. #15
    Simon Wardlaw
    SitePoint Community Guest
    Your spelling could improve:
    sucess, analsying, preparess

  16. #16
    SitePoint Addict NetNerd85's Avatar
    Join Date
    Aug 2005
    Location
    Australia
    Posts
    298
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Good article. Objectives make sense to justify options :)

  17. #17
    SitePoint Member
    Join Date
    Jan 2006
    Posts
    0
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Client is usually not good (and not interested) at abstracting engineering details, so the communication is crucial. As Martin said, you want to accept the clients' terminology and use diagrams, pictures and such.

    Another extremely usefull technique is to use static prototypes ("mockups" or "wireframes") of your application. Use the screens to resolve the requirement ambiguities and populate them with controversial data to deliberately provoke clients' response.

    Check this:
    http://mockupscreens.com

  18. #18
    abc
    SitePoint Community Guest
    How would you approach gathering requirements with an identified subject matter expert whom is not forthcoming with providing information?

  19. #19
    Non-Member
    Join Date
    Jul 2006
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Smile Web Project

    Yes this web project job will need monitoring

    I suggest to use the requirements tracability chart, where each requirements is track by a start, complete dates, done by which developer, problems, modules related to, testplans completed (you can add in more)

    so that its easiler to track and trace to problems

  20. #20
    Sajesh J
    SitePoint Community Guest
    Thank you for such an informative article.It would be great if you can discuss how requirement changes during various phases of SDLC can be handled.

  21. #21
    susan white
    SitePoint Community Guest
    - good content but many misspellings and wrong case of word.
    - looses credibility for a requirements gathering website

  22. #22
    Matt
    SitePoint Community Guest
    If ewe are going to knock something for grammer, make sure yourse is OK first?

  23. #23
    Jackie
    SitePoint Community Guest
    Please take the time to read the entire document. I rate this author as a 10--notice the author is from Melbourne and grammar and spelling is quite different in other countries. Great information.

  24. #24
    SitePoint Member
    Join Date
    Dec 2007
    Location
    California
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Looks like an interesting article. I'll take a look at it a little later.
    ANGRY.illustration San Luis Obispo County Web Design

  25. #25
    nixsumi
    SitePoint Community Guest
    great info. was very useful


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •