Reflections on Requirements Engineering course

Working as a Business Analyst you soon discover that requirements are a tricky thing to get right.

1. Requirements change through the lifespan of a project
2. Requirements have a habit of meaning different things to different people
3. When gathering requirements it is easy to take a statement as fact and later find it to be merely an assertion
4. When recording requirements it is easy to say something which is not as unambiguous as you think it might be
5. and finally, when the system is delivered, your customer may turn around and say this is not what they asked for, or that certain things they had assumed would be there are not, and have been taken for granted

Just to add pressure to this difficult mix a mistake in requirements is the most costly time to make a mistake!

So I spend 3 days at a training facility in Brindley Place, Birmingham, learning about Requirements Engineering from Malcolm Eva, the man who wrote the section in the BCS Business Analysis book.

+ focus on basic disciplines and techniques
+ focus on overcoming challenges and barriers (front story vs. back story, getting sign off)
+ good trainer / facilitator – knowledge and extended knowledge
- some of the content was a bit blue-sky – the real world means BA's perform multiple roles
- there were no specific tools, templates or automated systems recommended to help with requirements management

A big list of some of the things I took away from the course, some of which are a refresher rather than a revelation:

• Business Analyst's role encompasses
• Elicitation
• Analysis
• Management; and
• Validation stages
• Requirements fall into the following broad categories
• General (affecting whole system)
• Technical (e.g. the platform)
• Functional (activities, actions, processes)
• Non Functional (roles, interface, performance, usability, etc)
• Requirements must be accurate, factual and validated
• check the facts – without evidence a statement is an assertion, not a fact!
• Requirements need to be in a hierarchy, each smaller requirement working to achieve a higher level business goal
• All lower level requirements should be testable
• eg 'must be usable' is not testable, whereas 'user must be able to use the system with 1 hour training' provides some level of measurement
• if the requirement is written to be testable you don't need to invest time later on creating customer acceptance test plans
• Requirements should be granular – a statement containing “and” or “or” is an indication that 2 requirements are being merged in to one
• Requirements need to be visualised to help stakeholders understand the final product
• if the use cases, data diagrams, prototypes.
• creation of a requirements catalogue with a number of sub products -
• Terms of Reference – the Business Analyst's version of a PID – primarily covering Background, Objectives, Scope, Constraints
• Requirements catalogue entries – fully categorised with ID, Title, Description, Owner, Priority, Acceptance Criteria etc
• Use case diagram – visualise the scope by mapping out the actors and the functions they perform
• Data / Class model – visualise and describe the data structure and business rules at an abstract level
• Use a variety of quantitative and qualitative techniques for gathering requirements
• Qualitative: interview, observation, shadowing, self discovery
• Quantative: time and motion, records and databases, random sampling
• Each requirement should deliver a discreet piece of functionality, but should also contribute to a higher level goal, leading to a hierarchy of requirements
• Use the 6 filters to analyse your requirements
• can any be merged?
• are they ambiguous?
• do they conflict with others?
• are they feasible?
• aligned with objectives and scope?
• testable?
• give each requirement a recommendation – accept, reword, return, reject.
• There is a conflict of interests between BA and PM so ideally the people in these roles would be different – BA focuses on quality – PM – time & cost

So, I have a number of areas to focus on in order to make use of the course:

• spending more time on requirements and getting them right
• improve own & others ability to write and record requirements
• find ways to engage the business in understanding what their requirements will mean with the final solution
• find ways to work with our IT suppliers better.