Requirements: Choosing Your Words Carefully

three people sitting around a table in a meeting


Requirements are the baseline for any project,

as without requirements we don’t have a definitive list of set functions that the business requires the system/software to do.

 

Sometimes we come across projects that will have requirements documentation or the requirements will need to be drawn from other available documentation such as the test plan or test strategy. We may also come across some instances where by the project has very little documentation and we will need to define the requirements with the business by discussing what they want to accomplish with the software/system.

 

Whatever the situation might be for you to obtain the requirements, all of them can be open to ambiguity and this can have major effects on what a project tests and accomplishes.

 

Ambiguity can be caused by a number of different factors:

  • Language barriers
  • Functions not defined correctly
  • Difference of opinions from different parts of the business
  • Miscommunication

 

If a requirement is ambiguous then this can cause a number of different issues to occur over the course of a projects lifetime:

  • Unwanted functions development
  • Functions developed incorrectly
  • Wastes time
  • Wastes money
  • Push back the projects deadline

 

All of the above issues can cause finance efficiency issues and determine if a project will go live. It is for this reason that we need to ensure that any documents we produce are unambiguous and that we receive clarification from the business on possible ambiguous requirements.

 

I believe a simple solution to stop ambiguity occurring is to have a meeting with the key stakeholders, project managers and business analysts to ensure everyone agrees on what functions the software/system will have and that none of the requirements are ambiguous to them.

 

For more Consultant expertise on the importance of Requirements see Ken’s process series, in particular ‘The Impacts of Lack of Business Requirements Process’.

 

 

By James McStravick, QA Consultant – Olenick Global, Belfast


Related Content: Business Requirements Authoring, Requirements Management