- First things first; learn the skill: Understand how to structure and write requirements before you start using requirements management tools.
- Asking questions and getting answers: Learn how to ask questions to get answers to the important issues.
- Why you need good requirements: Some quick facts on project success and requirements. Presentation available.
Requirements:
- What are requirements?: A quick definition.
- Correctness: There are some things you just can not do.
- Completeness: Make sure that all of the, "what," questions are answered.
- Clarity: Requirements should be succinctly stated; using as few words as possible. Otherwise, ambiguity may occur. Excessive rambling, jargon & wishful thinking confuse readers -- avoid it. So it's still not clear?! Here's a short presentation deck recapping all of these items (the presentation is simply called Clarity.)
- Consistency: I hate it when people say, "Turn right. Your other right!"
- Testability: Prove to your client that the solution meets their needs. When a statement contains multiple requirements it's testability can be compromised.
- Traceability: What requirement led us to do this? How much work do we have left?
- Modularity: Update in one place and only in one place. Makes change management a lot less painful.
- Feasibility: Do you really think with enough time and money you can solve any problem?
- Design Independence: It starts with what and why. How comes later.
- Requirements vs. requirements management: Gathering requirements and managing them.
- Assessing requirement quality: How do you know if you have decent requirements?
The why of business analysis:
- The business analyst & the business systems analyst: What's the difference?
- The why of business analysis: What purpose and role do business analysts serve?
Running a business analysis engagement:
- Prepare thyself - make sure it's not you: Make sure you're mentally and psychologically ready and able to work. Eliminate any preconceived judgments and notions.
- Know the situation: Before you start an engagement take some time to grasp the nature of the project, it's urgency and the resources you'll need.
- Choose your tools: Decide what approach you will use. Will you prototype, interview, brainstorm or observe behavior?
- Set expectations: Ensure your role on the project is clearly defined and that you understand the roles of others as well.
- Time estimation: Estimate how long it will take you to complete your tasks. As you run through more projects your estimation skills will increase.
- It's the little things... Words that should make your ears perk up: Little words that your clients say that create headaches for you unless you clear them up now!
- New! How are your business analysts doing? Understand how to assess them.
- New! Understanding the goal: Knowing the objectives of your requirements gathering sessions helps you determine whether the requirements you are getting will actual help to solve the problem.
Project Bits & Bites
- How do you know you're done?: Use requirements management practices and traceability to see how much work you've done and how much you have left to do.
- Well-done or done well?: Use cost-benefit to determining where to invest your energy.
- System development life cycles & requirements: A very high-level overview of different system development life cycles and how this impacts requirements gathering.
- The project and the business analyst: Understand your role in a project and the activities you'll perform to support the initiative. Slides available!
- The sweet smell of success: Measuring success on a project ultimately boils down to meeting or exceeding targets established earlier in the project.
- Choose a methodology that suits your project: No one methodology will fit all projects.
- Testing & Validation: What are the different types of testing that occur as a project moves forth? Slides available!
- New! Requirements in an agile world: Understand that impact a different project methodology will have on requirements.
- New! Setting expectations: It's important that people know what you are delivering and why.
- New! How a "bad" requirement can stifle innovation: A lack of design independence in requirements can lead to a sub-optimal solution.
I really like this index, Marcus. Lots of good, useful material.
ReplyDeleteNice work!
WOW - as a new BA, I really appreciate you taking the type to post these different topics.
ReplyDelete