• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

difference between business req and functional req

 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello ,
I have some amount of experience getting to the keyboard and churning out code.
Now I reaslise that this is not enough .
Lots of the management team seems to dishing out terms like "functional requirements" and "business requirements"

Not sure if they are just passing the buck or is there really any diff ?

Till today - business calls us up / emails what is needed
and team churns out code . ( I understand the need of req docs ! )

Please point me where I could start

Also in a software project - which is a the first document that is created by whom and what ultimately lands up in the developers lap ? !!

Thanks ,
-anagha
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let's start from the end of your post. A typical stream of documents where I work is

  • Project Charter. A high level overveiw of the business opportunity, current state, proposed system. Later fleshed out with team makeup, budget, schedule, return on investment, etc.
  • Architecture. The first cut is high level, like "It's a web app, running on the existing Unix server farm, interfacing with partner systems X and Y." Over time it fills in detail to a high-level application design.
  • Use Case Catalog. Sometimes published separately, sometimes as part of the charter. Lists major areas of functionality. We've been pushing this to higher levels of detail over the years to support better estimates.
  • Use Case Document. Describes each use case in terms of user / system interaction without referencing specific widgets, menus, buttons, pages. The writing process is a collaboration between business folks who know what they want and tech folks who help get it down clearly.
  • Prototypes and detailed UI doc.
  • Test cases

  • The developers focus on the use cases and UI designs. Note that one requirement may be stated and restated in every one of these. That's a bad violation of Once and Only Once or Single Source.

    This is pretty "heavy" for the group here at the Ranch. I'll let them chime in with more agile alternatives.
     
    Ranch Hand
    Posts: 62
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi

    A business requirement defines something that must be realised to achieve a business goal.Business requirements do not and should not always be realised in a system.

    Functional requirements define the behaviour in a system, used to realise a business requirement.

    Ramen
    [ June 06, 2007: Message edited by: Ramen Chatterjee ]
     
    reply
      Bookmark Topic Watch Topic
    • New Topic