Presented by Brenton Burchmore

Thanks for joining in early

The course starts at 7pm AEST (UTC +10)

Agenda:
• Analysing and Categorising Requirements
• Making Requirements Useful
• The Requirements Catalogue
• Use Case Modelling
• Requirements should be structured and organised
• Working from the general to the specific in hierarchy
• Categories help us to analyse by group and type
• Each requirement is tested for its role in its group

Requirements that cannot be found, are poorly or misunderstood, are ambiguous, 
or that do not help with a successful development are a major cause of failure
They are also the core responsibility of Business Analysis 
In your experience, how often have you seen 
solutions implemented that do not meet 
serious, fundamental needs or objectives?
 General  • The business goals, policy, compliance and 
requirements other strategic needs of the solution BUSINESS
Driven by business
Technical  • Specifics that come from a business perspective  concerns and
that are constraints or design imperatives strategic objectives
requirements

Functional  • The functionality that the solution must offer, 
requirements what it must do, the capability it must offer SOLUTION
Driven by the
Non‐functional  specifics of the need
• Description of how or in what way the 
that is being solved
requirements solution must function, the quality standard
 Scope Creep • Getting all the needs discussed early and recorded

Being too Rigid • Change is inevitable, and human – be ready for it

Ambiguity • Avoid tacit knowledge, use glossaries and visuals

Communication Failure • Know the stakeholders, keep them informed ‐ often

Too Much Information • If they cannot find it, then the information is useless

Isolated Requirements • Be aware of requirement relationships and dependencies
 Should  Want to 
Must Have Could Have
Have Have
Essential  Highly  Very valuable, 
If wishes were 
requirements  important, but  but not vital to 
fishes…
that must exist not immediate success
 Duplicates and overlap • Each requirement is only expressed once

Merged requirements • Separate the complex into clearer individual requirements

Relevance and contribution • Make sure the requirement will helps us actually build the solution

Feasibility and sensibility • Realistic, without defying logic, common sense or sanity

Conflicting and contrasting • Remove any contradictions or opposition between requirements

Pre‐determined solutions • The question is not the answer, the requirement is not the solution

Usefulness of the information • Is the quality of this requirement complete and effective enough?
Specific Measurable Achievable Relevant Timed
 • The contextual information needed in order to understand the 
Intro, background, summary value of the details, the purpose of the project

• The exhaustive list of analysed and refined requirements that can 
Requirements Catalogue be used to design and build the right solution

• Illustration of how the business processes are affected by the 
Business process models solution, or how the company will be operationally different

• Illustration of the detailed functionality that will be provided by, or 
Functional models contained within the solution – or how that will change from now
© Creately.com
 Which of these dynamic behavioural 
diagrams have you used or worked with 
before?
(Click all that apply)
© Grapholite.com
© gridgit.com
State Machine Diagram Communications Diagram
Activity Diagram Sequence Diagram
• Captures and illustrates dynamic system behaviour
• Consists of: Actors, Use Cases & Relationships
• Used to gather the requirements of a system & influences
• Provides an outside view of the system looking in
• Each use case is a functional event
• (Each event might then have its own activity diagram)
Create or  • Create a Use Case diagram of a system you know OR
• Constructively respond to another student’s Use Case 
discuss a  model, or subsequent discussion
• Use any well known system, or use this short course as 
an example system (course, topic or just the webinar)
Use Case  • Build it using any software you like, but post the image
• Feel free to debate, discuss or contribute everywhere as 
diagram much as you wish
Validating & Managing Requirements

Confirming &  Getting 
Requirements  Changes to 
sharing  stakeholders 
traceability requirements
requirements aligned