Requirements Analysis

• Users are challenged in clearly stating their requirements.
• Analysts fall into "gathering" requirements not eliciting them.
• Confusion between goals, business needs, requirements,
  business rules, environment constraints and specifications.
• Common “standard” information on business
  environment needs to be re-generated for each project.

• Real requirements not identified until
  late in the systems development process.
• Similar requirements independently developed on multiple projects.
• Requirements developed on project basis without
  reference to overall needs or framework.
• Different users of requirements document have different
  needs in terms of format, content and level of detail.

Target REAL requirements

• Elicit not gather
• Dialog with all groups: users; product managers; developers; testers
• Probe and assess business objectives, needs, environment, actual use

Be practical and pragmatic

• Not limited to single format or approach
• As appropriate we use different formats in a coordinated way: declarative requirement statements, narrative, use cases, data models, process models, and business rules
• Use visual tools, prototypes other techniques where effort warrants

Present Information as required

• Charter / feasibility requirements structured for management and assess fundamental fit – overview detail
• Business requirements / scoping structured for users to assess goals / features / needs – moderate level of detail
• Specifications for developers and testers designed to communicate and reduce ambiguity – highly detailed