A number of folks have been asking for examples of requirements as well examples of the type of questions that the IT Business Analyst might ask of stakeholders in order to arrive at those requirements.

To make this learning even more relevant I'm offering to run, in this thread, through an example of gathering requirements.  Basically, I will act as the stakeholder: I have a need and requirements in mind but I will let the more junior analysts on this forum ask questions and being to document the requirements.

The goal at the end of this exercise would be to arrive at a fairly simple list of requirements (outline/bullet form).  If this goes well we might expand this into turning the bulleted requirements list into a use case diagram and, perhaps, use case specifications.

Rules of the game:

• Any participant in this thread should identify if they are a Junior BA (want to become a BA, just getting started, etc.) or a Senior BA (experienced practitioner).
• Junior BAs participate in the game by acting in the role of the BA to elicit and document the requirements.
• Senior BAs should not act as BAs but more as coaches to the junior BAs in this process.

If any of you Junior BAs are interested in playing this game just respond to this thread and let me know.  I'm hoping that we'll have at least 2-3 junior BA.

- Adrian (Role: Stakeholder)

Adrian,

Cool, I'm in.

Community,

I am senior BA with almost 10-years of experience. I am a project management professional (PMP), a private consultant and I'm also working on my CBAP (as soon as it comes back to Toronto) and my OCUP (OMG certified UML professional).

As the requirements elicitation phase of the game begins I have this to offer:

• Keep Enterprise Analysis in mind - remember to think about the big picture, the current infrastructure and how this solution must fit into it.
• Remember Business rules - more and more systems are becoming rules engines. Don't forget the rules.
• Also Process steps - first you have to know the as-is before you can focus on the to-be.
• Remember ... "what" do you need it to do? Don't think about "how" it will do it.:

think about the requirement as types:

• Regulatory Requirements
  • both inside and outside the company
• Business Requirements
  • Strategic - mostly qualitative, these are big words like "superior service" and "lightning speed". Get your stakeholder to quantify him /herself.
  • Tactical - these focus on integration with other systems.
  • Operational - these focus on management's needs.
• User Requirements
  • The black box experience for the user. Not how it will do what it needs to do ... just what does it need to do for the user.
  • What are the results of value that are visible to the user?
  • Functional - This is a discrete requirement that focuses on a function as it relates to a business result or deliverable.
  • Non-functional - I'm not a fan of this word but it is an industry standard. Consider them as any requirement not related to the functionality. All of the "ilities".
• Specifications
  • functional specs and non-functional specs

above all remember - each requirement must be visible (if not written does not exist), accountable (someone must agree to it) specific (how far, how fast, how soon?), measurable (how will we know when the requirement is met?) and rated (how important is this requirement ... really?)

that's my 2-cents worth.

Great!

Looks like we have a couple of Junior BAs interested in the role-play.  I'll wait another day or so to see if we can get a couple of more and then we'll get this game started.

Best regards,

- Adrian