Matching the Process to the Project

Gathering the Right Requirements
(Julie Blake, Business Analyst, Object Training)

Since returning I have been happily telling all and sundry that with this presentation, Julie was awarded the best Industry Track Paper for the conference - she's a BA and her presentation nailed the requirements process. Julie delivered case studies about two projects, contrasting the approaches taken and identifying lessons learned.

Project 1:

• 300 use cases.
• 6 experienced BAs.
• 4-5 months.
• Success - happy client.

Project 2:

• 100 use cases. (different level of detail; about same size ~300 under more analysis)
• 40 new BAs.
• 8 months+.
• Still going - trying Agile.

Both projects were mentored.
Project 1:

• BAs experienced.
• Customised templates and tasks.
• Fixed time frames.
• Clear, succinct high-level requirements.
• Clearly defined boundaries.
• Clearly defined interactions with external systems.

Project 2:

• Inexperienced BAs (from business or SW developers) - little or no training or coaching.
• 'Project office' customised roadmap and templates.
• Ongoing activity.
• High-level requirements too detailed.
• Cloudy project boundaries.
• New external systems were constantly discovered: 50-70 kinda involved.

Lessons learned:

• Don't spend too much time on detailed requirements up front.
• Team responsible for customising templates.
• Time spent on requirements eats into development time.
• Requirements and development should be done in parallel -> Agile.
• Avoid analysis paralysis.

When do you stop?

• Requires thought.
• Do developers have enough to go on with?
• Can business sign off?
• Have the complex parts of the solution [problem?] been captured adequately.

Essential requirements iterations:

1. Scope; Context; Capability.
2. Detail; Quantifiable Risk; Buildability.
3. Resolution; Completion; Testability.

Deadlines slipping - why?

• Too much detail up front?
• Problems getting signoff?
• Don't know what to do next?

Process may help - what to do next.

Customise the process:

• Every project should customise for project needs.
• Process chosen should be flexible enough for customisation.
• Agile is not always the answer.

Forces:

• Agile for high rate of change. <--
• and risk. <--
• --> Plan driven for depth of business user knowledge.
• --> and project complexity.

How do I customise?

• Key - experienced practitioners, not third party.
• Activities to touch lightly and in detail.
• Experience and coaching are required.
• Process does not turn bad BAs into good BAs.
• Need support for coaching to customise process and activities for BAs, developers and testers.

Experience makes the difference.

Q. Methodology?
A. UML, use cases, activity diagrams, sometimes sequence diagrams. Not casual. Any consistent methodology. Same methodology for each phase - more detail and elaboration.
Q. What size?
A. Is anybody going to need what I am writing? Break into small, bite-size chunks - subject areas.

Requirements engineering is important - vital.
Business needs to have, to state key project requirements that are clear [objectives!].
Detail of dozens/hundreds of use cases can change - in detail - does not affect key outcomes of project.